Subject: 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) <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

From: Antone Roundy <[email-masked]>
Date: Mon, 10 Oct 2005 09:23:50 -0600

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.

---

From: Antone Roundy <[email-masked]>
Date: Mon, 10 Oct 2005 09:37:29 -0600

Gaaaah!  Sorry about the mile long subject. Gotta be careful with  
that copy and paste!