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

[Scott Reynen]

On Jun 17, 2007, at 12:55 PM, David Janes wrote:

>> David, I was under the same false assumption. Microformats are
>> scope-less. There is no such thing as scope and binding... the only
>> thing that matters is the order that the Microformat elements are  
>> listed
>> on the page.
>
> Has this been articulated anywhere on the Wiki?

Yes, the lack of a generic scoping mechanism is the problem discussed  
here:

http://microformats.org/wiki/mfo

However, individual microformats do define scoping within their own  
limited context.  For example, while hCalendar doesn't have very  
detailed parsing rules defined, it's clear that parsers must  
distinguish between the url of an attendee and the url of a vevent to  
avoid problems.  Which is fine when the internal microformat (in this  
case hCard) is defined at the time the external microformat (in this  
case hCalendar) is created, but that doesn't work when we're  
developing a new microformat (e.g. hAudio) intended to be embedded in  
existing microformats (e.g. hReview, hAtom).  We can't retroactively  
require parsers of these microformats to understand hAudio as  
hCalendar parsers understand hCard.

> Note that this causes a conflict with the microformats naming
> principles [2]. That is, let's assume for argument's sake that "fn" is
> the best thing to use for Audio Title. Under the rules Manu gives,
> "fn" isn't available for use (unless "item" or similar is injected, as
> mentioned earlier in this thread)

Right, that's the problem.  It's also a problem with older  
microformats.  For example, one can't safely embed hListing in  
hReview, nor vice versa, because both include a "description"  
property, which may be misinterpreted by any parser that doesn't  
understand both microformats.  This inability to embed conflicts with  
the modularity/embeddability principle.  So we're left choosing  
between two microformat principles that don't work well together in  
practice.  We could get them to work together by continuing that MFO  
discussion, but then we'd be conflicting with yet another principle:  
solve a specific problem.  So which principle do we discard here?

--
Scott Reynen
MakeDataMakeSense.com