[whatwg] Trying to work out the problems solved by RDFa

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