Revised Feed Ranking Draft

[James M Snell]

I've posted the revised version of the Feed ranking draft updated to 
reflect the recent conversations. This is a major update.


 http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-index-03.txt

Sample:


  ...
  
  
 
   ...
   1   
   4.5
 
 
   ...
   3   
   3.0
 
 
   ...
   2   
   5.0
 

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

[James Holderness]

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

Re: Feed History -04

[Henry Story]

I think this is good, but I would prefer the atom:link to be used  
instead of
the fh:prev structure, as that would better fit the atom way of doing  
things.
I also think it may be very helpful if we could agree on an extension  
name space
that all accepted extensions would use, in order to reduce name space  
clutter.


Henry


On 7 Sep 2005, at 01:18, Mark Nottingham wrote:


Feed History -04 is out, at:
  http://www.ietf.org/internet-drafts/draft-nottingham-atompub-feed- 
history-04.txt


Changes:
  - fh:stateful -> fh:incremental, with appropriate changes in text
  - more explicit cardinality information
  - implications of fh:prev being an Absolute URI spelled out
  - more explicit white space handling
  - Acknowledgements section

More information, including implementation details, at:
  http://www.mnot.net/blog/2005/09/05/feed_history

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

Re: Feed History -04

[Mark Nottingham]

Hi Henry,

Thanks for the feedback. As I've explained before, I have a pretty  
strong preference for the current design, to make it usable in other  
formats; i.e., the scope of this is not just Atom (which is why I'm  
probably going to do it as an Individual submission).


One path forward would be to have a special case of fh:prev, just for  
Atom, where it was spelled atom:link. I'm not crazy about this, as  
exceptions are generally bad, and because it would require  
implementors to special-case their code; i.e., they'd have to look  
for one element if it's an RSS feed, and a different element if it's  
an Atom feed. I know this is already done widely, but I see no reason  
to artificially require the practice here. However, if a number of  
implementors stand up and say that they wouldn't mind such a special  
case, and no one is against it, I'd make the change.


WRT namespaces, I agree that namespace clutter isn't great, but it's  
hard to avoid while still getting the benefits of namespaces. Perhaps  
once there are a lot of extensions that are used in day-to-day  
practice, someone will package them up into a bigger, wrap-up  
namespace that contains everything.


Cheers,



On 29/09/2005, at 10:21 AM, Henry Story wrote:

I think this is good, but I would prefer the atom:link to be used  
instead of
the fh:prev structure, as that would better fit the atom way of  
doing things.
I also think it may be very helpful if we could agree on an  
extension name space
that all accepted extensions would use, in order to reduce name  
space clutter.


Henry


On 7 Sep 2005, at 01:18, Mark Nottingham wrote:



Feed History -04 is out, at:
  http://www.ietf.org/internet-drafts/draft-nottingham-atompub- 
feed-history-04.txt


Changes:
  - fh:stateful -> fh:incremental, with appropriate changes in text
  - more explicit cardinality information
  - implications of fh:prev being an Absolute URI spelled out
  - more explicit white space handling
  - Acknowledgements section

More information, including implementation details, at:
  http://www.mnot.net/blog/2005/09/05/feed_history

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









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

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

[James M Snell]

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.


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

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

[James Holderness]

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).


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

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

[James M Snell]

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).



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.


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 
-MM-DD format.

References: [W3CDTF] http://www.w3.org/TR/NOTE-datetime
Type of Term: 	element 

Status: 	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 


Refines:http://purl.org/dc/elements/1.1/date
Status: 	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 -MM-DD 
format.


Guidelines for content creation:

If the full date is unknown, month and year (-MM) or just year 
() 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.



dcterms:available is equivalent to atom:updated.



I would have thought that equivalent was dcterms:modified.


Sorry, was thinking atom:published, typed atom:updated


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.


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

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

[James Holderness]

James M Snell wrote:
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 -MM-DD 
format.


Guidelines for content creation:

If the full date is unknown, month and year (-MM) or just year () 
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 -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

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

[James Holderness]

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., -MM-DD for a single date; 
-MM-DD/-MM-DD for a date range; -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.