[whatwg] Trying to work out the problems solved by RDFa
hsivonen at iki.fi
Fri Jan 2 02:38:33 PST 2009
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 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)?
hsivonen at iki.fi
More information about the whatwg