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

From: James M Snell <[email-masked]>
Date: Mon, 26 Sep 2005 08:32:01 -0700

Over the past couple of weeks I've been working on a number of proposed 
Atom extensions that I am moving forward with as standards-track RFC's 
through individual submission.

I believe that the Expiration extension -- 
http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-expires-04.txt 
-- is complete and ready for an unofficial last call.  Before I submit 
this to Scott Hollenbeck asking for it t become a standards-track RFC, I 
would like to invite the members of the WG to comment | praise | 
complain | improve | all-of-the-above.  In >= 2 weeks I'll make any 
appropriate changes and submit the draft to Scott.

Summary: introduces a mechanism for specifying a date-time or maximum 
age for the informational content of a feed or entry
Example:
   <feed>
     ...
     <age:expires>2005-12-12T12:00:00Z</age:expires>
     <entry>
        ...
        <updated>2005-11-11T12:00:00Z</updated>
        <age:max-age>20000</age:max-age>
     </entry>
   </feed>
   The metadata in the feed element expires at noon on Dec , 12 2005,
   The metadata in the entry element expires 20000 miliseconds after 
noon on Nov, 11, 2005.

- James

---

From: Henry Story <[email-masked]>
Date: Wed, 28 Sep 2005 11:07:24 +0200

Would it be possible to merge, or at least have the history extension  
[1] use the same
name space as your extension, so that the the history's incremental  
and archive tags
can have the same namespace, and the history fh:prev can be  
transformed to a link object, thereby:
     - reducing the number of namespaces used by an atom feed
     - allowing the <link ...> construct to be used by the feed  
history proposal
?

Henry Story

[1] http://www.ietf.org/internet-drafts/draft-nottingham-atompub-feed- 
history-04.txt
On 26 Sep 2005, at 17:32, James M Snell wrote:
>
> Over the past couple of weeks I've been working on a number of  
> proposed Atom extensions that I am moving forward with as standards- 
> track RFC's through individual submission.
>
> I believe that the Expiration extension -- http://www.ietf.org/ 
> internet-drafts/draft-snell-atompub-feed-expires-04.txt -- is  
> complete and ready for an unofficial last call.  Before I submit  
> this to Scott Hollenbeck asking for it t become a standards-track  
> RFC, I would like to invite the members of the WG to comment |  
> praise | complain | improve | all-of-the-above.  In >= 2 weeks I'll  
> make any appropriate changes and submit the draft to Scott.
>
> Summary: introduces a mechanism for specifying a date-time or  
> maximum age for the informational content of a feed or entry
> Example:
>   <feed>
>     ...

---

From: James M Snell <[email-masked]>
Date: Wed, 28 Sep 2005 08:17:07 -0700

There are a couple of problems with that:

1. The specs serve two completely different purposes (feed history is 
not the same as meta expiration)
2. I don't control the feed history proposal

- James

---

From: "James Holderness" <[email-masked]>
Date: Thu, 29 Sep 2005 16:39:05 +0100

I know the Atom working group seemed to be against reusing dublin core in 
the core Atom spec, but since this is an extension, were dcterms:valid 
and/or dcterms:available ever considered as alternatives? From my 
understanding they appear to be describing essentially the same thing.

I don't particularly like the whole DCMI Period structure they're using, but 
since it's an existing format, any aggregator author that wishes to support 
this sort of thing is probably going to be supporting it anyway. Adding 
another extension that does essentially the same thing just gives them more 
work to do.

Or have I complete misunderstood the intended use?

James M Snell wrote:
> Summary: introduces a mechanism for specifying a date-time or maximum age 
> for the informational content of a feed or entry

---

From: James M Snell <[email-masked]>
Date: Thu, 29 Sep 2005 11:36:27 -0700

the dcterms:valid element is not quite expressive enough in that it is 
limited to dates (and does not include the time).  dcterms:available is 
equivalent to atom:updated.  There appears to not be any dcterm 
equivalent to my max-age element.  In other words, the dublin core stuff 
does not get us quite to where the expires extension does. 

James Holderness wrote:

>
> I know the Atom working group seemed to be against reusing dublin core 
> in the core Atom spec, but since this is an extension, were 
> dcterms:valid and/or dcterms:available ever considered as 
> alternatives? From my understanding they appear to be describing 
> essentially the same thing.
>
> I don't particularly like the whole DCMI Period structure they're 
> using, but since it's an existing format, any aggregator author that 
> wishes to support this sort of thing is probably going to be 
> supporting it anyway. Adding another extension that does essentially 
> the same thing just gives them more work to do.
>

---

From: "James Holderness" <[email-masked]>
Date: Thu, 29 Sep 2005 21:11:19 +0100

James M Snell wrote:
> limited to dates (and does not include the time).

Are you sure about that? The example here 
(http://web.resource.org/rss/1.0/modules/dcterms/#valid) certainly shows a 
time range, and the documentation for DCMI Period here 
(http://dublincore.org/documents/dcmi-period/) says nothing about limiting 
to a date either. You get to specify the scheme used, but they generally 
seem to use W3C-DTF which gives you as much (or as little) precision as you 
want.

> dcterms:available is equivalent to atom:updated.

I would have thought that equivalent was dcterms:modified.

dcterms:modified -> Date on which the resource was changed.
dcterms:available -> Date (often a range) that the resource will become or 
did become available.

> There appears to not be any dcterm equivalent to my max-age element.

I thought about that, but I couldn't see any real advantage to max-age in 
this context. It's not as if it's relative to the last time the document was 
retrieved in which case an equivalent end date would have to be recalculated 
every time the feed was downloaded. Since it's relative to the atom:update 
time, it only needs to be calculated when an item is updated and in that 
case you'd be updating the feed anyway.

Regards
James

---

From: James M Snell <[email-masked]>
Date: Thu, 29 Sep 2005 13:46:24 -0700

James Holderness wrote:

> James M Snell wrote:
>
>> the dcterms:valid element is not quite expressive enough in that it 
>> is limited to dates (and does not include the time).
>
>
> (http://web.resource.org/rss/1.0/modules/dcterms/#valid) certainly 
> shows a time range, and the documentation for DCMI Period here 
> (http://dublincore.org/documents/dcmi-period/) says nothing about 
> limiting to a date either. You get to specify the scheme used, but 
> they generally seem to use W3C-DTF which gives you as much (or as 
> little) precision as you want.
>
I'm going off of the description here: 
http://www.dublincore.org/documents/dcmi-terms/

Term Name: date
URI: 	http://purl.org/dc/elements/1.1/date
Label: 	Date
Definition: 	A date associated with an event in the life cycle of the 
resource.
Comment: 	Typically, Date will be associated with the creation or 
availability of the resource. Recommended best practice for encoding the 
date value is defined in a profile of ISO 8601 [W3CDTF] and follows the 
YYYY-MM-DD format.
References: 	[W3CDTF] http://www.w3.org/TR/NOTE-datetime
Type of Term: 	element 
<http://www.dublincore.org/usage/documents/principles/#element>
Status: 	recommended 
<http://www.dublincore.org/usage/documents/process/#recommended>
Date Issued: 	1999-07-02

Term Name: valid
URI: 	http://purl.org/dc/terms/valid
Label: 	Valid
Definition: 	Date (often a range) of validity of a resource.
Type of Term: 	element-refinement 
<http://www.dublincore.org/usage/documents/principles/#element-refinement>
Refines: 	http://purl.org/dc/elements/1.1/date
Status: 	recommended 
<http://www.dublincore.org/usage/documents/process/#recommended>
Date Issued: 	2000-07-11

Also, the description and examples of the Date element here: 
http://www.dublincore.org/documents/usageguide/elements.shtml

/Element Description:/ A date associated with an event in the life cycle 
of the resource. Typically, Date will be associated with the creation or 
availability of the resource. Recommended best practice for encoding the 
date value is defined in a profile of ISO 8601 [Date and Time Formats, 
W3C Note, http://www.w3.org/TR/NOTE-datetime] and follows the YYYY-MM-DD 
format.

Guidelines for content creation:

If the full date is unknown, month and year (YYYY-MM) or just year 
(YYYY) may be used. Many other schemes are possible, but if used, they 
may not be easily interpreted by users or software.

Examples:

    Date="1998-02-16"
    Date="1998-02"
    Date="1998"

According to the authoritative descriptions, there is no mention of a 
time component.

> I would have thought that equivalent was dcterms:modified.
Sorry, was thinking atom:published, typed atom:updated

> dcterms:available -> Date (often a range) that the resource will 
> become or did become available.
>
> I thought about that, but I couldn't see any real advantage to max-age 
> in this context. It's not as if it's relative to the last time the 
> document was retrieved in which case an equivalent end date would have 
> to be recalculated every time the feed was downloaded. Since it's 
> relative to the atom:update time, it only needs to be calculated when 
> an item is updated and in that case you'd be updating the feed anyway.
>
With max-age, if your entry is supposed to expire after 6-months from 
the time it was updated, there is no need to recalculate the value.  If 
I used expires for this, my software would have to recalculate the 
expiration with every update operation.  It may be a minor savings of 
cycles, but it is still a savings.

- James

---

From: "James Holderness" <[email-masked]>
Date: Thu, 29 Sep 2005 23:14:38 +0100

James M Snell wrote:
> date value is defined in a profile of ISO 8601 [Date and Time Formats, W3C 
> Note, http://www.w3.org/TR/NOTE-datetime] and follows the YYYY-MM-DD 
> format.
>
> If the full date is unknown, month and year (YYYY-MM) or just year (YYYY) 
> may be used. Many other schemes are possible, but if used, they may not be 
> easily interpreted by users or software.
>
> Examples:
>
>    Date="1998-02-16"
>    Date="1998-02"
>    Date="1998"
>
>
> According to the authoritative descriptions, there is no mention of a time 
> component.

That's a fair interpretation, but I don't think it's the only one. Best 
practice recommends use of the W3C-DTF profile of ISO 8601 which 
specifically supports hours, minutes and seconds - even fractions of a 
second. They may go on to recommend the YYYY-MM-DD subset as being more 
easily interpreted, but they also say "Many other schemes are possible". If 
you look at the current usage of dc:date in the wild you'll find many 
examples with a full date and time (like say all of RSS 1.0 and many RSS 2.0 
documents).

And regardless of your interpretation of their W3C-DTF usage, the usage 
guide for Dublin Core Qualifiers 
(http://dublincore.org/documents/usageguide/qualifiers.shtml) specifically 
lists DCMI Period as a valid encoding scheme for dcterms:valid and 
dcterms:available. And if you look at the documentation for DCMI Period 
(http://dublincore.org/documents/dcmi-period/) you will see a nice example 
of a date range with full W3C-DTF date and time.

That documentation comes straight from the Dublin Core website. Is that not 
authoritative enough?

> With max-age, if your entry is supposed to expire after 6-months from the 
> time it was updated, there is no need to recalculate the value.  If I used 
> expires for this, my software would have to recalculate the expiration 
> with every update operation.  It may be a minor savings of cycles, but it 
> is still a savings.

Fair enough, but if that's the only justification for this extension is it 
really worth the effort?

That said, if you still want to go ahead with the spec I don't really have a 
problem with it. Aggregator authors wishing to support this kind of 
functionality will have twice the work to do, but they're probably used to 
that by now. ;-)

Regards
James

---

From: "James Holderness" <[email-masked]>
Date: Fri, 30 Sep 2005 00:45:09 +0100

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.