I can’t help wondering why you would keep your schedule in XHTML?

My public schedule, the one I put on the Web, is most efficiently kept in XHTML because that’s how it’s going to be published. So now I can add a little extra information (still via XHTML) and it’s easily translated into ICS or other calendaring formats. My personal schedule is not in XHTML, but then I have no intention of publishing that to the Web, so there’s little point in keeping it in a Web-compatible format.

You’re probably right that most people would want to store their schedules in an application and export it to the Web. However, and this is the crucial part, schedules that are meant for the Web—conference schedules, event listings, tour dates, speaking appearances, and so on—are in my mind best served by hCalendar.

Most people who use a calendaring application are using it for meetings, appointments, and similar stuff that they would never want to put online. (Would I want the rest of the world to know when I’m seeing a proctologist? Hell no! …assuming I were, of course.) The things that they do want to put online should either be stored in XHTML, or published in XHTML… and in either case, adding the hCalendar information makes it far more powerful than just blatting it out as non-annotated markup.

Because that way, as I said in the post, the same information meant for display in Web browsers (and other user agents) can be picked up by search engines with the hCalendar information—thus allowing them to provide better search results. A quick example: if a large movie site published theater times with hCalendar information, and also provided reviews in hReview, then they or any other search engine would be able to let users execute searches like “show me all of the movies that got at least four out of five stars that have showings that start in the next three hours”. Add in a simple postal code, and you can add “in my area” to that query.

Take it further: suppose we had an “hCommerce” microformat that allowed for embedding information about prices, currencies, and so on. Now you can add “that cost less than $9 per person” to the query. (Which, in New York City, would probably get “no results”, but that’s their problem.)

To bring it back to the point at hand, the point here is not to make it easier to produce the information. In fact, adding semantic information, regardless of the mechanism, makes it harder to produce information. Microformats are a lot less hard than many other approaches, in my view, but they still add some complexity. The whole point is to make things easier for the users/readers/consumers—the people looking for this information, and who want to use it in their own personal ways.

Why would I produce an ICS file separate from my XHTML when I could embed all of the relevant calendar information into the XHTML and automatically produce an ICS from that information?

I can’t help wondering why you would keep your schedule in XHTML? Most people would want to use an application specifically designed for that purpose and export it to the web, NOT the other way around.

Regards, Pat Egen
Calendaring Evangelist, and end user!
http://www.calconnect.org

P.S. Dave Thewlis is the guy I brought in to be the Exec Director. He’s the one who does most of the work.

For that matter, why would anyone?

As for hCalendar, why not just embed the iCalendar file info right in the HTML as well, or, have a LINK REL=”ALTERNATE” type link in the HEAD tags that points to the ICAL file(s) for that page? We do that in EVDB.

@Robert: try Mozilla Sunbird

it must be great to be part of such a intresting project!