06.03.05
MicroFormats Continued
In response to my previous inflammatory post, I got a pair of good comments from Ryan King and Brian Suda. To recap, we were focusing on two areas where microformats might run into difficulty: inability to perform validation against a machine-readable profile, and namespace collisions.
Ryan suggests that microformat authoring applets are a good way to mitigate problems that might otherwise crop up due to lack of validation. If microformats aren’t being coded by hand, they’re more likely to be valid. Anybody following this debate has probably already seen these.
Brian points out that, even within the current handful of microformats, collisions in the property namespace are already a real problem. He shows that because hCard and hCalendar both use “url” as a property name (albeit in similar ways), someone parsing an hCalendar that happens to contain an embedded hCard inside is liable to misinterpret hCard’s “url” as belonging to hCalendar. Is there a way around this? Can I write a parser for a particular kind of microformat such that it can handle other embedded microformats that I’ve never seen before without choking if there’s a namespace collision?
Tags: microformats
Tantek said,
June 4, 2005 at 6:43 am
Todd,
You have some good analysis here. Let me see if I can help answer a few questions.
First, so far there is no namespace problem with microformats. I say so far, because this has been deliberate, by design. Similarly, internet standards have worked just fine for 20+ years without namespaces (e.g. how many IETF RFCs and W3C TRs do we depend on everyday that use no namespaces? nearly all. Ironically, the ones that require use of namespaces for anything other than decoration in headers have seen very little, very slow adoption). This is why “namespaces” has been oft compared to “chicken-littling”, the claim that the sky is falling (or worse, the sky *might fall!) when years of experience have shown few *practical* problems (if any), that can often be easily resolved with a bit of discussion.
One of the key principles of microformats is the reuse of well established interoperably implemented specifications, building blocks etc. The “url” property, used in both vCard RFC2426, and iCalendar RFC2445 is thus reused in hCard and hCalendar. It actually means the same thing. Thus there is no need to namespace it. This is not a “collision”, this is reuse!
About the embedding question. What happens when you put an hCard with a “url” inside an hCalendar? How does the hCalendar know to not parse the hCard’s “url” as its own? Simple. When parsing an hCalendar, anything inside an hCard (i.e. element with class=’vcard”) is treated as part of the hCard. Similarly with hReview.
What happens with new microformats? Well, we’re crossing those bridges as we get to them, and new microformats are obviously being designed to be compatible with (and in fact, to take advantage of) already existing microformats.
Another part of the microformats philosophy is rather than sit around and argue about theoretical problems that paralyze you from doing anything for years and years, just build something small and simple, see how it works, and iterate. So far we’ve had a lot of rapid success with this approach.
The nice thing about this difference in methodology is that it provides an excellent self-selection mechanism. Folks that want to worry about theoretical problems are free to do so, find each other, keep each other busy with such discussions, and typically don’t get anything done except a lot of writing, maybe a few published papers. Meanwhile, the folks that say damn the theoretical problems, I’m going to build it anyway are free to do so, find each other, and are productively making progress building working solutions without being hampered by the nay-sayers.
ryan king said,
June 4, 2005 at 9:45 am
A couple things..
First of all, though I think the tools we’ve created so far are good, I think there’s far more potential in building these microformats into existing applicatioons. For example drx is a collection of programming resources on the web. Douglas Clifton has successfully integrated hReview into that application. This is what I mean by building authoring tools.
Second, I think it is possible to successfuly “write a parser for a particular kind of microformat such that it can handle other embedded microformats.” While said parser couldn’t really ‘handle’ the unknown microformat, it could at least be smart enough to ignore it, if it isn’t familiar with the format.
brian said,
June 4, 2005 at 6:59 pm
As a disclaimer, i guess i should say that i am working on both the hCard and hCalendar microformats and on X2V, a converter of hCa* to their respective formats. I’m 100% behind microformats, i am just bring-up many of these points because they help me clarify my work on the conversion tools and generally help people understand the abilities and limitations/benefits of microformats.
Ryan Said:
While said parser couldn’t really ‘handle’ the unknown microformat, it could at least be smart enough to ignore it, if it isn’t familiar with the format.
While i agree this should be the case, one problem is the mixing of microformat class values and regular css. If nested inside an hReview, i parse a value of class=”alertbox”, a regular valid css style name. Should the parser halt and ignore all content inside it (because “alertbox” might be an unknown microformat), even if the child nodes contains additional hReview information which would be skipped? or should it ignore the potential nested microformat of “alertbox”, or should it do nothing and assume the user knows what they mean? (this is where a validator would be real handy!)
Tantek said:
When parsing an hCalendar, anything inside an hCard (i.e. element with class=”vcard”) is treated as part of the hCard. Similarly with hReview.
While that is the easiest way to avoid complications, i’m not sure it is the best solution. I agree that the URL in vCard IS the same URL in iCal, so then why must the class=”url” be treated differently when nested in an hCard inside an hCal? My vote, since they are equivalent, would be to use the single instance of class=”url” in both profiles, otherwise you’d need to have a class=”url” inside the class=”vcard” and the same link again outside it again if you wanted that url in both microformats.
Many of these issues will be explained away as the spec is finished and polished. It is moot to concern yourself with some of the specific problems right now, but it is important to keep them in-mind as things progress.
I too completely agree that the best way to get a microformat out there is to just built it. Most of the issues i raise are because of problems i encounter while sorting out code to make the conversions. Tantek and Ryan have been doing a great job getting people tools to create hCa* and hReview marked-up HTML and i’ve been building tools to get the microformats out, so a lot of the time we are looking at the same problem from two different directions.
If anyone else has any thoughts, issues, or questions, an excellent place to discuss the topic is on the Technorati Developer Wiki, both the hCard and hCalender microformats have Brainstorming pages where examples are explored, written and revised, again and again. With outside input we uncover issues and problems and fix them, or explain away misconceptions and innuendoes.