Subject: Re: Unofficial last call on draft-snell-atompub-feed-expires-04.txt

From: Mark Nottingham <[email-masked]>
Date: Thu, 6 Oct 2005 13:38:36 -0700

FWIW, the Media RSS extension cites http://web.resource.org/rss/1.0/ 
modules/dcterms/#valid] as a best practice.

On 29/09/2005, at 4:45 PM, James Holderness wrote:

>
> Just a follow-up on the representation of Date Ranges in dublin  
> core. I was under the mistaken impression that you needed to use a  
> DCMI Period encoding to represent a date range, but apparently ISO  
> 8601 time intervals are perfectly valid. In order to clarify the  
> situation, the DC Date Working Group has recently recommended the  
> following replacement for the comment associated with the date  
> element:
>
> "Typically, Date will be associated with the creation or  
> availability of the resource. A date value may be a single date or  
> a date range. Date values may express temporal information at any  
> level of granularity (including time). Recommended best practice  
> for encoding the date value is to supply an unambiguous  
> representation of the single date or date range using a widely- 
> recognized syntax (e.g., YYYY-MM-DD for a single date; YYYY-MM-DD/ 
> YYYY-MM-DD for a date range; YYYY-MM-DDTHH:MM to specify a single  
> date and time down to the minute)."
>
> Full details of the recommendation can be found here:
> http://dublincore.org/usage/meetings/2005/09/madrid/files/ 
> 2005-07-29.date-comment.txt
>
> Personally I think that makes the idea of using dublin core for  
> this extension a whole lot more palatable.
>
>
>

--
Mark Nottingham     http://www.mnot.net/

---

From: James M Snell <[email-masked]>
Date: Fri, 07 Oct 2005 09:42:39 -0700

Let me stew on this a bit more.  Generally speaking, I think the dcterms 
are too loosely defined, but let me see if I can't get this to grow on me.

Mark Nottingham wrote:

>> following replacement for the comment associated with the date  element:
>>
>> availability of the resource. A date value may be a single date or  a 
>> date range. Date values may express temporal information at any  
>> level of granularity (including time). Recommended best practice  for 
>> encoding the date value is to supply an unambiguous  representation 
>> of the single date or date range using a widely- recognized syntax 
>> (e.g., YYYY-MM-DD for a single date; YYYY-MM-DD/ YYYY-MM-DD for a 
>> date range; YYYY-MM-DDTHH:MM to specify a single  date and time down 
>> to the minute)."
>>
>> Personally I think that makes the idea of using dublin core for  this 
>> extension a whole lot more palatable.
>>
>>
>>
>
>
> --

---

From: James M Snell <[email-masked]>
Date: Sat, 08 Oct 2005 07:37:33 -0700

Ok all, after looking this over in detail, I personally still have a 
preference for the age:expires and age:max-age elements in the 
feed-expires spec.  Of course, this is likely due more to the fact that 
I wrote the draft as opposed to a sound, objective and technical 
perspective.  So I want to open it up to a poll. 

Here are the options.

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

using age:expires:

   <entry>
     ...
     <age:expires>2005-12-12T00:00:00Z</age:expires>
   </entry>

   Advantage:
     * The value of the expires element uses the Atom date construct 
making it ALWAYS compatible with other Atom dates
   Disadvantage:
     * New namespace, new element

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.

So what do y'all think?

- James

---

From: "James Holderness" <[email-masked]>
Date: Sun, 9 Oct 2005 08:55:41 +0100

I'd be in favour of dcterms:valid (preferably restricted in form) for the 
following reasons:

* I'm worried that producers of RSS 1.0 feeds would be more likely to use 
dcterms:valid and thus consumers would be obliged to support it anyway.
* dcterms:valid has slightly more functionality in that you get to specify a 
start date.

However, I'm not vehemently opposed to age:expires if that's the route you 
choose to take.

James M Snell wrote:
> feed-expires spec.  Of course, this is likely due more to the fact that I 
> wrote the draft as opposed to a sound, objective and technical

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 9 Oct 2005 09:47:05 -0700

I'm torn; on the one hand, dcterms is already defined, and already  
used in other feed formats; on the other hand, the syntax is less- 
than-simple.

So, I'm neutral on this.

On 08/10/2005, at 7:37 AM, James M Snell wrote:

>
> Ok all, after looking this over in detail, I personally still have  
> a preference for the age:expires and age:max-age elements in the  
> feed-expires spec.  Of course, this is likely due more to the fact  
> that I wrote the draft as opposed to a sound, objective and  
> technical perspective.  So I want to open it up to a poll.
> Here are the options.
>
> I wanted to indicate that a given entry must expire at Midnight on  
> Dec, 12, 2005 (GMT).
> using age:expires:
>
>   <entry>
>     ...
>    * 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.
>
> So what do y'all think?
>
> - James
>
> Mark Nottingham wrote:
>
>
>
>> FWIW, the Media RSS extension cites http://web.resource.org/rss/ 
>> 1.0/ modules/dcterms/#valid] as a best practice.
>>
>>
>>> core. I was under the mistaken impression that you needed to use  
>>> a  DCMI Period encoding to represent a date range, but apparently  
>>> ISO  8601 time intervals are perfectly valid. In order to clarify  
>>> the  situation, the DC Date Working Group has recently  
>>> recommended the  following replacement for the comment associated  
>>> with the date  element:
>>>
>>> availability of the resource. A date value may be a single date  
>>> or  a date range. Date values may express temporal information at  
>>> any  level of granularity (including time). Recommended best  
>>> practice  for encoding the date value is to supply an  
>>> unambiguous  representation of the single date or date range  
>>> using a widely- recognized syntax (e.g., YYYY-MM-DD for a single  
>>> date; YYYY-MM-DD/ YYYY-MM-DD for a date range; YYYY-MM-DDTHH:MM  
>>> to specify a single  date and time down to the minute)."
>>>

--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems

---

From: Phil Ringnalda <[email-masked]>
Date: Sun, 09 Oct 2005 10:21:48 -0700

Mark Nottingham wrote:
> 
> I'm torn; on the one hand, dcterms is already defined, and already used 
> in other feed formats; on the other hand, the syntax is less-than-simple.

Indeed. A perfectly, utterly valid <dcterms:valid> value:

start=George W. Bush; scheme=US Presidents; name=Bush II

I'm -1 on using Dublin Core for anything other than providing 
human-readable labels for human-readable data.

Phil Ringnalda

---

From: James M Snell <[email-masked]>
Date: Sun, 09 Oct 2005 21:02:03 -0700

James Holderness wrote:

>
> I'd be in favour of dcterms:valid (preferably restricted in form) for 
> the following reasons:
>
> * I'm worried that producers of RSS 1.0 feeds would be more likely to 
> use dcterms:valid and thus consumers would be obliged to support it 
> anyway.

I would expect anyone who uses RSS 1.0 would be more likely to use 
extensions that are well suited to RSS 1.0 and that anyone who uses Atom 
1.0 would be more likely to use extensions that are well suited to 
Atom.  If there is the possibility of cross-over, great, if not, that's 
ok also.

> * dcterms:valid has slightly more functionality in that you get to 
> specify a start date.
>
I don't necessarily want more functionality.  The atom:updated date 
gives us a perfectly good start date.

> However, I'm not vehemently opposed to age:expires if that's the route 
> you choose to take.
>
Given the feedback thus far, I'm leaning strongly in favor of keeping 
age:expires

(thanks, Robert, for the clear up vote)

- James

---

From: Eric Scheid <[email-masked]>
Date: Mon, 10 Oct 2005 14:43:21 +1000

> gives us a perfectly good start date.

Perhaps atom:published would be better for this semantic. Unlike
atom:updated, it can be hold a future value, IIRC.

e.

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 9 Oct 2005 21:59:51 -0700

Yeah, that kind of tears it for me; we could profile it, but I'm less  
than convinced that the potential reuse is worth it (esp. when it's  
so trivial to map age:expires into dcterms:valid).

+1 to age:expires.

On 09/10/2005, at 10:21 AM, Phil Ringnalda wrote:

> I'm -1 on using Dublin Core for anything other than providing human- 
> readable labels for human-readable data.
>
> Phil Ringnalda
>
>
>
>

---

From: James M Snell <[email-masked]>
Date: Sun, 09 Oct 2005 21:58:29 -0700

Yeah, I've been thinking a bit about that.  The only thing that was 
holding me back was that atom:published is optional and only appears on 
atom:entry.  I wanted the extension to be able to work on the feed level 
also.  That said, the spec could be updated to say that IF the published 
date is used on the entry, it represents the moment at which the entry 
is considered "valid" and becomes the base for the age:max-age element. 

- James

---

From: "James Holderness" <[email-masked]>
Date: Mon, 10 Oct 2005 07:43:05 +0100

James M Snell:
> 1.0 would be more likely to use extensions that are well suited to Atom. 
> If there is the possibility of cross-over, great, if not, that's ok also.

Fair enough. I was just trying to make things easier for aggregator 
developers who are obliged to support both types. However, if age:expires is 
better for Atom (and that certainly seems to be the consensus) then that's 
the way you should go.

> I don't necessarily want more functionality.  The atom:updated date gives 
> us a perfectly good start date.

Well if you go with atom:published rather than atom:updated, as Eric 
suggested, then that clinches it for me. You have my vote.

Regards
James