From: "Mike Schinkel" <[EMAIL PROTECTED]>
because Microformats squat on a scare resource (names in classes.)
This is not a scarce resource, people can (and are) naming classes as they
choose.
Any constraint happens at the parsing stage, since microformat-aware parsers
look
for specific class names etc. (see below)
From: "Costello, Roger L." <[EMAIL PROTECTED]>
down to an issue of interoperability. If the Microformat's community
splinters and, say, multiple versions of hCard are created then we
immediately have an interoperability problem.
No, this is merely a rendering problem. From the microformat hCard parsing
page [1]
forward compatible parsing
When parsing the contents of an hCard, any unrecognized class names must be
ignored. >Similarly, unrecognized values for hCard properties must also be
ignored.
So, if one wanted to extend hCard with additional fields i.e. blog-url,
activity-url they are free to do so. Generic
parsers/renders *will not barf* and simply discard the superset.
Specific parsers/renderes would be needed however to accomodate this.
In other words, the constraints imposed by microformats.org should not
effect
others. They can leverage off of existing microforamtted-objects, build
their own alongwith corresponding parsers/renderes and in browsers that
only understand standard microformats, they most likely will degrade
gracefully and the subset be parseable/renderable
[1] http://microformats.org/wiki/hcard-parsing
S. Sriram
_______________________________________________
microformats-discuss mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-discuss
