Re: Straw Poll: age:expires vs. dcterms:valid (was Re: Unofficial last call on draft-snell-atompub-feed-expires-04.txt) On Oct 8, 2005, at 8:37 AM, James M Snell wrote: I wanted to indicate that a given entry must expire at Midnight on Dec, 12, 2005 (GMT). using age:expires: [snip] using dcterms:valid (http://web.resource.org/rss/1.0/modules/dcterms/#valid) end:2005-12-12T00:00:00Z Advantage: * Existing namespace, known element Disadvantage: * Value can be many different things. I've even seen cases in which the content of dcterms:valid is an XML structure. My chief problem with dcterms:valid (and with dublin core in general) is that the elements are very loosely defined. The content can literally be anything folks want it to be and still be considered valid. Unless we constrain the value space for this element when used in Atom, it *could* lead to a bunch of extra work for consumers to parse and! process those dates. I prefer very crisply defined elements. Then again, reusing an existing namespace is Goodness. I think it would be going too far to say "when using dcterms:valid in Atom, you must follow this profile", because we don't own dcterms, and doing so might limit people from doing valid things with it that don't follow that profile. But I do think it would be reasonable to say "when using dcterms:valid in Atom, it is recommended that you follow this profile--otherwise your data may be technically valid, but not widely understood", thus giving developers an excuse for not supporting data not formatted according to that profile. If a use case that requires a different format becomes common, then developers can start supporting more formats at that point. That said, my "vote" is for doing what I just said--advocate the use of dcterms:valid for this purpose, with the date formatted to match Atom's date construct profile. BTW, you might choose language that ! leaves room for having both start and end dates for validity--! for exam

Mon, 10 Oct 2005 12:36:03 -0700


Oops, sent this from the wrong address on Saturday. No wonder it didn't get through.

On Oct 8, 2005, at 8:37 AM, James M Snell wrote:

I wanted to indicate that a given entry must expire at Midnight on Dec, 12, 2005 (GMT).
using age:expires:

[snip]

using dcterms:valid (http://web.resource.org/rss/1.0/modules/ dcterms/#valid)

 <entry>
   <dcterms:valid>end:2005-12-12T00:00:00Z</dcterms:valid>
 </entry>

 Advantage:
   * Existing namespace, known element
 Disadvantage:
* Value can be many different things. I've even seen cases in which the content of dcterms:valid is an XML structure. My chief problem with dcterms:valid (and with dublin core in general) is that the elements are very loosely defined. The content can literally be anything folks want it to be and still be considered valid. Unless we constrain the value space for this element when used in Atom, it *could* lead to a bunch of extra work for consumers to parse and process those dates. I prefer very crisply defined elements. Then again, reusing an existing namespace is Goodness.


I think it would be going too far to say "when using dcterms:valid in Atom, you must follow this profile", because we don't own dcterms, and doing so might limit people from doing valid things with it that don't follow that profile. But I do think it would be reasonable to say "when using dcterms:valid in Atom, it is recommended that you follow this profile--otherwise your data may be technically valid, but not widely understood", thus giving developers an excuse for not supporting data not formatted according to that profile. If a use case that requires a different format becomes common, then developers can start supporting more formats at that point.

That said, my "vote" is for doing what I just said--advocate the use of dcterms:valid for this purpose, with the date formatted to match Atom's date construct profile.

BTW, you might choose language that leaves room for having both start and end dates for validity--for example, to enable Atom delivery of a coupon that's valid for a particular span of dates.

Reply via email to