« Public Invite-Only Events | Main | How do You Use Del.icio.us? »

February 01, 2005

Comments

Jeff Julian

If the aggregator community isn't going to pick a standard, then you can never assume your readers will support RSS, nor will you assume they support Atom. With this in mind, you can’t have an event standard for syndication that has its own "item" or "entry" container. It has to be slick enough to fit in to the standard for that particular channel. This allows it to be portable for any item-based XML standard. Maybe it isn't as big of a deal as I made it, but when ESF, the predecessor of ESS, was launched, the gods of the XML world didn't like the idea of one syndication standard the have the event spec reside in.

XHTML vs. XML in my mind isn’t even a battle. The specification needs to be parsed with ease, but at the same time, have a light weight schema. By using the span of XHTML and the class attribute to have meaningful values, but treated as a string instead of an enumeration, you are going to have problems. Also, the values of a span can’t not be linked to a particular type based on a string value of an attribute. By this, I mean a Boolean can not be assumed as a value of a span element, because a particular attribute with the value of “IsActive” has been passed. Maybe this isn’t a big issue either, but I surely wouldn’t want to be on the parsing end of an hCal feed.

Since I am the only active writer of ESS, I would love to hear other negative feedback on the specs design, and more on XHTML vs. XML as a standard for syndication protocols.

Sooz

I signed up with the OpenEvents Wiki back in November but I haven't kept up with anything. I think I need to catch up because this sounds really interesting and could be worth tapping Exploit Boston!'s event calendar into. (I fully endorse you giving me a hard time for not "getting this" sooner.)

peter caputa

I am almost sold on xml, instead of xhtml.

Next step, I think is determining what elements need to be included in the schema. I think we need to get as close to ical as possible to allow for interop with desktop scheduling apps.

We also need to define a standard way of expressing the values, for the same reason. Eg date needs to be expressed like: "20041005" so that outlook et al can read it in directly - at some point.

I'd like to hear more from the AGGREGATOR community on this, especially including feedster and technorati.

Jeff Julian

I think if you support either any date format, there will always be an easy conversion to another. I originally was on the same page with you, but it is much easier to use RFC-822 than the iCalendar standard for sake of the adopters. I actually have an pretty simple XSLT conversion from ESS to iCalendar, so it is possible already with the published standard.

The comments to this entry are closed.