misconceptions: Difference between revisions
(Elaborate two dangers of not using profiles.) |
m (Add links) |
||
| Line 23: | Line 23: | ||
It is therefore important to <em>use</em> the profile attribute. | It is therefore important to <em>use</em> the profile attribute. | ||
The GRDDL spec shows how to make a profile, and how generic data clients to follow, to ground the data into RDF. This will maximize re-use of the data, in combination wit other data. There is a growing class of | The [http://www.w3.org/2003/g/data-view GRDDL] spec shows how to make a profile, and how generic data clients to follow, to ground the data into RDF. This will maximize re-use of the data, in combination wit other data. There is a growing class of [http://esw.w3.org/topic/GrddlImplementations grddl-aware systems] which will use GRDDL-enabled microformat data without any alteration. | ||
=== microformats use unscoped class names === | === microformats use unscoped class names === | ||
Revision as of 19:37, 27 September 2007
misconceptions about microformats
Some misconceptions either appear often enough, or may have been held by people that are experts in the fields of markup, web standards etc., and thus it is useful to document and debunk them.
misconceptions
microformats use non-URI based extensibility
misconception: Microformats use non-URI based extensibility.
Microformats make use of the profile attribute, in the <head> element to reference one or more profiles (this is all per HTML4 spec) to an XMDP profile document (XMDP is derived from the "hints" in HTML4 as to what a profile document "could" be), to define specific rel (e.g. XFN 1.1 profile and class (e.g. hCard profile) values.
Thus microformats are built upon a form of URI based extensibility. Tantek did this by design for XFN, his first experiment into formally extending HTML, and before he even coined the word "microformat" (XMDP & XFN were developed in 2003, "microformats" were first proposed in 2004).
What we have found is that, just like HTML was often used in the wild without explicit DOCTYPE URIs (and tools e.g. browsers supported it), microformats are often used in the wild without explicit profile URLs (and tools e.g. browser plugins support it).
However, missing a DOCTYPE does little or no damage, as (modulo tag soup issues) the DOCTYE is a link in the chain of reasoning about what the document means. The HTML profile for microformats is however a crucial link. There are two dangers is it is omitted:
One danger is that, because tools such as browser plugins support microformats without checking for a profile, then those tools will erroneously pick up data from pages which use classes for a completely unrelated purpose. This attributes to the author information which they never meant to give.
The other danger is that no generic data-gathering device can be built. The web ceases to be self-describing, in that there then would be no one common algorithm for deriving the data from a given page. Web client software has to be all updated for the latest microformats which they want to support. While this would scale for a small number of well-known global microformats, it does not scale when domain-specific, or culture-specific, or company-specific microformats are added.
It is therefore important to use the profile attribute.
The GRDDL spec shows how to make a profile, and how generic data clients to follow, to ground the data into RDF. This will maximize re-use of the data, in combination wit other data. There is a growing class of grddl-aware systems which will use GRDDL-enabled microformat data without any alteration.
microformats use unscoped class names
misconception: Microformats definitions use unqualified/scoped class attribute strings as semantic tags.
This is incorrect on two counts.
First, as above, microformats make use of profile URLs to define class name semantics. Thus it is entirely possible (though both unlikely, and undesirable) for someone to redefine class names with their own definitions in their own profile URL.
Second, compound microformats (e.g. hCard, hCalendar, hReview) use a fairly uniquely chosen string for the "root element" (e.g. vcard, vcalendar, vevent, hreview) and then generic terms only inside that root element. Thus use of any generic terms are scoped (some might even say "namespaced") within the fairly uniquely chosen "root element" class name.