[uf-new] Microformats parsing,
in general (was: hAudio final draft)
scott at makedatamakesense.com
Sun Jun 17 12:55:15 PDT 2007
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
>> on the page.
> Has this been articulated anywhere on the Wiki?
Yes, the lack of a generic scoping mechanism is the problem discussed
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 . 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?
More information about the microformats-new