- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Fri, 2 Jan 2009 12:38:33 +0200
On Jan 1, 2009, at 17:24, Toby A Inkster wrote: > So why RDFa and not Microformats? There's a possibility that this is a false dichotomy and both are bad. > Firstly, RDFa provides a single unified parsing algorithm that > Microformats do not. Separate parsers need to be created for > hCalendar, hReview, hCard, etc, as each Microformat has its own > unique parsing quirks. For example, hCard has N-optimisation and ORG- > optimisation which aren't found in hCalendar. With RDFa, a single > algorithm is used to parse everything: contacts, events, places, > cars, songs, whatever. More to the point, Microformats not only require per-format processing but the processing required for each Microformat isn't specified at all. That's bad. RDFa, on the other hand, uses CURIEs, which is bad. (More generally, I think using URIs as identifiers instead of using them for above-TCP- layer protocol addressing is bad, but relying on the namespace mapping context is even worse.) Have there been any attempts to remove the badness of Microformats without introducing the badness of RDFa in the process? That is, have there been attempts of defining unified parsing while retaining the feel of Microformats without relying on the namespace mapping context from the layer below? If not, why not? I'm assuming that people in the Microformat community have clue. Yet, on the face of it, viewed from outside the community, their formats seem to have a big problem. Why hasn't the community fixed it? Is it a non-problem after all in practice? > Lastly, there are a lot of parsing ambiguities for many > Microformats. One area which is especially fraught is that of > scoping. The editors of many current draft Microformats[1] would > like to allow page authors to embed licensing data - e.g. to say > that a particular recipe for a pie is licensed under a Creative > Commons licence. However, it has been noted that the current > rel=license Microformat can not be re-used within these drafts, > because virtually all existing rel=license implementations will just > assume that the license applies to the whole page rather than just > part of it. RDFa has strong and unambiguous rules for scoping - a > license, for example, could apply to a section of the page, or one > particular image. Is the problem in the case of recipes that the provider of the page navigation around the recipe is unwilling to license the navigation bits under the same license as the content proper? In the case of images, why should a program inferring something about licensing trust assertions made in a different HTTP resource (possibly even from a different Origin)? -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/
Received on Friday, 2 January 2009 02:38:33 UTC