[uf-dev] Microformats parsing, in general (was: hAudio final draft)

[David Janes]

On 6/18/07, Dan Connolly <connolly at w3.org> wrote:

> I don't like #1. I don't have much tangible argument against it, but
> it puts a burden on me (as a parser implementor) that I'm not convinced
> to take on. If other implementors take on that burden and work out
> all the details, I'll perhaps reluctantly comply.
>
> On the other hand, I find #2 appealing and I'm inclined to put
> effort into it. I think that authors are willing to jump thru
> a certain number of hoops if that's what it takes to get the
> tools to do what they want, and they'll likely find the mfo
> burden acceptable.

I've been mulling through the various options and I have to say #2 is
the most appealing to me also.

Consider, for example, a parser that understands hListing [1] and in
particular the field "summary". Now let's say we invent a new
microformat hNew that also uses "summary" as a field.

Now, an author can embed hNew in hListing, but obviously there's no
clear way for the pre-hNew parser to know "summary" associated with
hNew and not hListing

hListing
* hNew
** summary <- confusion

I think MFO -- which says microformats _above_ the mfo-node shouldn't
look for fields _under_ the node -- handles it quite clearly:

hListing
* hNew mfo
** summary <- hListing does not see summary (assuming it understands mfo)

I have other related suggestions -- BLOCKQUOTE and Q are always "mfo",
hCard and hCalendar are always mfo -- but they can wait.

Regards, etc...
David

[1] http://mail.google.com/mail/


-- 
David Janes
Founder, BlogMatrix
http://www.blogmatrix.com
http://blogmatrix.blogmatrix.com