Standardizing on preferred round trip rules between iCalendar and hCalendar, or adding extra decorations to hCalendar to ease parsing by generic XML tools would probably be good, but creating a new incompatible format is just creating more problems for everyone.

First, EVERYTHING ELSE uses it! While RDF may be better suited, and JSON sleek and new, we should be pushing for a general information standard. XML should feed into or reference RDF, and it easily can be converted to other, similar representations like JSON. Realistically this data won’t (or shouldn’t) exist in any format until it is pulled from a source like a database, so the best choice should be the standard that can be generated easily by hand (for those of us with simple needs or quick tasks that won’t justify a db), AND can be easily served up by a script or directly from a database. This is one of the goals as I see it of XML: interchangeability.

Secondly, wider client support. And I mean both editors and browsers. I can currently create an SVG in Inkscape, tweak it in Notepad++, open it in Firefox or Gimp, and, if I’m feeling crazy, send it to a screen printer who can open it in Illustrator and make me a wicked huge print of it. I can (to some extent), embed that SVG into my site’s XHTML along side some MathML. Someday I might even get to drop some MusicML somewhere in there so that a visitor can get the tabs for ‘Yesterday’ and even get the browser to play it while they read it.

Now wouldn’t it be great if I could make my staff’s work calendar in Sunbird, tweak it in Notepad++, drop it directly into my schedule page’s XHTML and know that when they visit the site in something other than IE, they can not only get a good output of their schedule, but can add it to their Google calendar or send it straight to their phone, maybe without even needing an add on?

The thing that I like the least about hcalendar is that it’s trying (very nobly and cleverly, don’t get me wrong) to put scheduling info on top of HTML. The idea of microformats is great if the data is going to be there anyway in that format already and you want to add that extra layer. But most of them time we just want the schedule, not some divs and list items that also have that extra feature.

So XML is certainly the way to go. It makes the data more interchangeable between devices and applications, more embeddable/interactive with other pre-existing XML standards, and more available for editing by both humans and machines.

PS: Is there ANY actual implementation of X-Cal that is current and working? I’d really like to see a full example that is both valid and can be imported into Outlook or GCalendar.

On second thought: Nah, dumb idea, hCalendar sans presentation wouldn’t make any sense, would it?

Agreed.
Thought experiment: What if there were a canonical way to write hCalendar for purposes of data interchange?

A better reason is that we know from folks like Eventful and others that people are embedding calendar data in XML today in a variety of incompatible ways. It’s definitely progress if we can converge on a single XML format.

That’s a really interesting point. Question: There are infinitely many ways to represent a chunk of iCalendar in hCalendar. But is there a canonical way to do it? If so that might indeed meet the requirement for round-trip conversion between iCalendar and something angle-brackety.

Another question: How much validation does Optimus do? I ask because the current best iCalendar validator, http://severinghaus.org/projects/icv/, isn’t nearly as complete or robust as the RSS/Atom analog at http://feedvalidator.org/. Over at http://icalvalid.wikidot.com/ I’ve been doing some groundwork with Ben Fortuna and Doug Day but we haven’t gotten very far yet.

I think hCalendar actually solves the use cases you present for “an XML representation for iCalendar”, and there’s already an ecosystem of hCalendar generators, processors, search engines (Yahoo! Searchmonkey) and validators.

The Optimus microformats transformer and validator will for example validate your hCalendar for you:

http://microformats.org/wiki/optimus

From my perspective, agreement on anything reasonable — for XML and, as Jake points out, probably nowadays for at least also JSON too — is preferable to no agreement.

I’m a bit confused. What about the xCal-Basic draft?

http://tools.ietf.org/html/draft-royer-calsch-xcal-03

Is this applicable to your comment?

<vevent dtstart=”2009-01-01T09:00:00Z” uid=”2009.1″ dtstamp=”2008-05-27T00:00:01Z”>
<summary>Low Tide 0.39 ft</summary>
</vevent>

In general, you err on the side of too much structure, which is not bad, but can make life a bit harder for implementors.

The minimal version is

Low Tide 0.39 ft

Either way, it would be useful.

The main problem though with current ics is not the syntax per se, but that it allows for some wide variation between valid files (as I think you’ve discussed earlier).