"As such, they consume that extensibility point, leaving me without one for any other use I may have."

Not quite true since an element can have multiple classes. What it does consume is that particular class name. It doesn't stop you from adding other class attributes like <span class="vevent myclass1 myclass2">.

Isn't the fact that the class names exist in a global namespace also a significant problem? The hcalendar-issues page includes a number of items which can be seen in that light. You could usefully emphasize the namespace advantage for your <trip xmlns="http://nwalsh.com/rdf/itinerary#" ... example.

The only way I see where it could be made easier. It's with a templating system, but do not ask the user to enter the data. :)

I was thinking of another possibility too, but I have to try first.

@Ed-

About class values being in a global namespace.... yes, in a sense they are in a flat namespace. On the other hand, they can be (relatively) easily disambiguated by context. For example, .hreview .descripion and .vevent .description.

@Norman-

"I'm not using and to markup the individual appointments, so I can't add hCalendar to them."

I don't follow what you're saying here.

re: validation...

A validation approach is being explored by Brian Suda in his X2V system- he's running a preflight procedure before trying to parse hcards, which catches nearly all errors. Also, I'm finding that having a reference implementation (X2V), helps about as much as validation. When I write code in hcard or hcalendar, I'll check it against X2V to make sure that things come out the way I expect them to. This method seems to work pretty well.

Its good to hear your feedback about microformats. Feel free to offer constructive feedback anytime.

-ryan king

@Ryan,

I think Norm is saying that you are limited in the type of markup you can use. In the sense a certain architecture of imbrication of span/div or other kind of elements. More than a bit here and there with the elements of your choices.

The good thing would be to find a universal solution. Whatever the person is using for the class names, to have it easily processable by a transformation rules. Maybe the profile saying this class name correspond to this in hcard. this one to that. And so to really give freedom to the user.

Unfortunately, there's still something which is painful for everyone is that as soon you want to explicit data structures, you have to work for it (being n3, rdf/xml, microformats, wiki markup, etc.) It's why a template paradigm would be very useful in this domain of explicit data. You could look at datablogging for example, which has very neat features for templating.

@karl: The good thing would be to find a universal solution. Whatever the person is using for the class names, to have it easily processable by a transformation rules.

Absolutely right. It would have been much better if the hCalendar people had taken a step back to get a wider view. Using an approach like that of GRDDL would have allowed a lot more flexibility. Having a standard transformation available for the markup as they have defined it would allow those who don't wish to write XSLT to play.

On the other hand - I'm not too impressed with the details of GRDDL anyway.

Re: extensibility, my bad. I always forget that in XHTML, class="foo bar baz" means the union of the foo, bar, and baz classes.

I expected this essay to generate comments, and it did :-) I'll follow up in a few days with an attempt to synthesize what I learn from them.

Calendar data is very complicated and most people DON'T use divs and spans, instead they use tables to sperate date-time, location, and description information into individual cells. We are aware of this have have look into special rules for extracting information from tabular data. These are in the early stages, but HTML tables has very little used attributes called 'headers=' and 'axis=', these can be used to associate rows and cells to other cells.

There are no manditory elements that MUST be used in microformats, just more semantic ones. The most common is the abbr element. In all examples, properties like 'dtstart' and 'dtend' use abbr elements to give a human readable date-time as the node value and a machine readable date-time in the title attribute. There is nothing stopping someone from using any element they wish, just that the node value would have to be the machine readable date-time.

Another advantage of microformats is the ability to extract the data from the HTML to any format. hCard can be converted nicely to a vCard, but another advantage is the ability to use GRDDL to extract hCards to RDF vCards, RDF FoaF, or any other format.

XMDP is a way to describe a microformat, and for simpler microformats, you can use it to validate against. I have built some basic validators for XFN, GRDDL, and no-follow. When you get to more complex systems, it does get more difficult because it relies on knowledge about some of th RFCs referenced. Even with that draw-back it is possible to create a unique validator for microformat based on the XMDP file. A universal validator/parser has been proposed by used GRDDL and RDF to extract more of a machine readable schema from XMDP, but at the end of the day, microformats are designed first and foremost as human readable, machine readable second.

i look forward to a follow-up post about this topic.

-brian

which reminds me of something completely different.

I had created a while ago a calendar under the form of a list and rendered as a table. :)

So, given the objections you have, how would you respond to Tim Bray's "No New XML Languages" post on http://www.tbray.org/ongoing/When/200x/2006/01/08/No-New-XML-Languages if you haven't already?

Brian, "XMDP is a way to describe a microformat, and for simpler microformats, you can use it to validate against." - I'd say this isn't a true statement. I don't think that eyeballing something is the same as validation, which at least to my mind implies some sort of official stamp of approval.

I was wondering if interleave is really required for RELAX NG validation of microformats, cf. our very brief chat on #swig about it. I suppose that the problem is that you need to be able to select which child element classes will be used for each parent element class, for example... Couldn't you do that with substitution groups in W3C XML Schema, or something like that? I don't like to think that this is impossible.

Or perhaps the Schematron approach would be worth it. After all, it's just a load of XSLT, so the barrier for setting up your own local validator is actually a lot lower than for, especially, WXS, and to some extent RELAX NG (I use jing or rnv, but that hardly beats XSLT's implementation proliferation).