“Design depends largely on constraints.” — Charles Eames
Tuesday, 29 April 2003
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?
Filed under: Syndication
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 PM +10:00
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 PM +10:00
Phil,
I don't think that would do too much good; most people are going to be using libraries to parse and generate dates, and each will have its own way of doing things.
Normally, that would be a good thing, as RFC2822 dates have been around enough and widely-used enough (!) to be well-understood. However, it might be different in RSS's case, because:
- Some people will still generate - and parse - them by hand.
- XML tools don't have any concept of RFC2822 dates.
- Eventually, XML specifications themselves are going to be type-aware (I hear rumors of this happening soon in XML Query and elsewhere), and they won't know about RFC2822 dates at all, so they won't be able to manipulate them.I agree that adoption is a big key to making a difference here. Back to the profiling discussion, what if there were a flag - say an element in the head - that said, among other things, "I treat dates this way" so that aggregators would know when they're dealing with a feed built under certain assumptions?
The point here would be NOT to orphan current aggregators, but to encourage migration to a better date format, if it's worth it; it's not either/or, it's "do both, but prefer this one if you're smart."
Not sure why you need RDF Schema to see a dcterms:issued element...
Sam -
If they disagree, I'd say that there's likely an error in one. If the one with the more robust format has precedence, I think it helps.
The other options are -
- encourage people to only put dcterms dates into feeds (I think this is a bit draconian)
- stick with pubDate / lastBuildDate (I think this is probably OK for now, but will cause friction in the long term)
Tuesday, April 29 2003 at 9:09 PM +10:00