mnot’s blog

Design depends largely on constraints.” — Charles Eames

Tuesday, 29 April 2003


RSS Schema and dates

Sam mentions dc:date; that’s what I was thinking, except that ‘date’ on its own is pretty useless. As Bill points out, dcterms gives you different date semantics.

dcterms:issued seems to match RSS’s pubDate most closely, while as far as I can tell, dcterms:modified matches lastBuildDate.

The question I have is of precedence; aggregators that support both will need to defer to one or the other. I’d think that the W3C-formatted form would be preferable, because it’s easier to parse (so simple, I’ve written one), and less likely to be misunderstood (e.g., “Thursday” instead of “Thu”, variable length fields, etc.).

One way to go about it in the schema would be to say that if pubDate is present, dcterms:issued must be present; that way, it’s backwards-compatible with things expecting pubDate.

What do people think? Is date parsing enough of a problem (both from a getting-it-right standpoint and a oh-what-a-pain-to-implement standpoint) to encourage a shift towards the W3C datetime format?


Sam Ruby said:

My experience is that many if not most validators ignore dates, but those that do respect dates, handle both, but I doubt that there is any consistency at this point on precidence rules.

Given this, I strongly advise against putting both in place. What should an aggregator do if these disagree?

In fact, the validator currently doesn’t express a bias between these alternatives, but does flag when there are redundant definitions.

Tuesday, April 29 2003 at 4:32 AM

Phil Ringnalda said:

As a sometimes author of bad aggregators, I’d be very interested in a switch if you can guarantee me that absolutely every single person in the world will make the switch. Otherwise? No benefit, some harm as you encourage people to use either dc:date, that I’m already looking for, or maybe dcterms:issued, which I would only find and recognize if I was using a hypothetical RDF Schema-aware parser.

I’d say it would do far more overall good to write a very careful and clear guide to exactly what you can and can’t do in an RFC822+ date, and give it to Dave to link to from the RSS 2.0 spec. Not sure whether it should just codify the aspects of RFC822 that we usually use, or admit that “Tue,(sday) 28(th of) Apr(il in the year of Our Lord) 2003 (at) 07 (far too early) : 01 G” is in fact a fully valid 822 date, though.

Tuesday, April 29 2003 at 5:38 AM