misconceptions

From Microformats Wiki
Revision as of 19:34, 25 September 2007 by Tantek (talk | contribs) (drafted with misconceptions from David Orchard)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

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 - The XHTML Friends Network, his first experiment into 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).

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-microformat (e.g. hCard 1.0, hCalendar 1.0, hReview 0.4 (in progress)) 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.

see also