[uf-discuss] Process to handle decentralized creation of new
lachlan.hunt at lachy.id.au
Sun Oct 1 08:45:23 PDT 2006
Costello, Roger L. wrote:
> What happens when creating microformats becomes decentralized; that is,
> when communities go off and create their own new microformats?
> For example, one community might create a microformat for aquarium
> A separate, independent community might create a microformat for
> artillery tanks....
> <div class="tank">
I think this illustrates the need to choose unambiguous terms where
possible and, for these examples, classes like "aquarium" and "military"
would be better choices.
> Alas, we have two tank microformats with totally different semantics.
> This "microformat name collision" problem might lead to the suggestion
> to use namespaces for microformats.
We already have the profile attribute though it's not always used by
authors. If such a collision occurred, it probably wouldn't be very
likely that the both aquarium and and military format would be used on
the same page. However, it is theoretically possible that two
associated, yet conflicting formats may arise in the future.
> Thus, the aquarium community associates their microformat with this
> namespace: http://www.aquarium.org
> Now their microformat is used as such:
> <html xmlns:aquarium="http://www.aquarium.org">
Use of xmlns is not appropriate for microformats because there is no
concept of XML Namespaces in text/html, which is what most people use.
> <div class="aquarium:tank">
The class attribute is not a QName, so that won't work even in XHTML.
Besides, QNames have other problems associated with them, one of which
you pointed out:
> But using namespaces in microformats will trigger problems in other
> technologies, such as CSS.
(There are many other problems with QNames as well, though they're not
really relevant to microformats, so I won't go into them now.)
The namespace problem has been looked at by many others in the past.
Some proposals I remember reading about, which haven't really taken off,
<link rel="profile" href="http://example.org/ns/aquarium" title="aq">
<link rel="schema.XFN" href="http://gmpg.org/xfn/" />
<a rel="XFN.met" href="..." />
Then there's the whole issue about namespaces being confusing for
authors, which is claimed by some people I know. There are some,
including people like Ian Hickson, who are quite vocal about this,
particularly because it adds complexity for both authors and UAs.
Currently, I think the best approach is for microformats to be designed
with simple vendor prefixes, much like the way vendors can experement
For example, a marine biology organisation may develop their aquarium
format and give each property a "aq-" prefix, at least for the root
class name. Similarly, a military organisation may use a "mil-" prefix.
<!-- Or, because the root class is already "aq-tank", this is still
relatively unambiguous -->
Even microformats.org has adopted a kind of pseudo-vendor-prefix. Many
of them begin with "h" (like hResume, hListing, hReview, etc.) or "v"
(hCard: "vcard", hCalendar: "vcalendar")
This approach solves the CSS problem you mentioned earlier, because
different authors won't be using different prefixes for the same format.
More information about the microformats-discuss