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
_______________________________________________
microformats-new mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-new
