On [Aug 14], at [ Aug 14] 5:22 , Martin McEvoy wrote:
Is the "item" property in haudio MFO?
Item
*The element /MUST/ be processed opaquely. No sub-elements should be
read from any hAudio contained in a track element.
http://microformats.org/wiki/haudio#Item
... or am I misunderstanding the "microformat object(opaque)" problem.
Item solves a small part of the problem MFO proposes to solve. Item
has an opacity rule for embedding hAudio within hAudio. MFO would
provide a similar rule for embedding anything within anything else.
By detaching the opacity indicator from a specific microformat, MFO
would have the advantages of being usable for embedding future
microformats. For example, hAtom has no rule for opacity of embedded
hAudio, and it couldn't possibly have such a rule because hAudio did
not exist when hAtom was created. Because both use "published," this
leaves room for ambiguity MFO would remove.
MFO also has the advantage of decoupling opacity from other
semantics. Item makes it impossible to embed another hAudio with a
shared name, but MFO would make that possible by giving the publisher
more control over describing the meaning of their content. This could
reduce unnecessary duplication, for example, in describing single-
track album releases.
The documented real-world examples with widely-published microformats
are, of course, far more relevant than the above hypothetical examples
with nascent hAudio:
http://microformats.org/wiki/mfo#Examples
--
Scott Reynen
MakeDataMakeSense.com
_______________________________________________
microformats-new mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-new
