Ok, new version of the Link Extensions draft has been posted.. includes the 'accessed' attribute...
http://www.ietf.org/internet-drafts/draft-snell-atompub-link-extensions-06.txt - James On Tue, Jun 1, 2010 at 4:40 PM, James Snell <[email protected]> wrote: > On Tue, Jun 1, 2010 at 2:27 PM, Bob Wyman <[email protected]> wrote: >> The draft, as currently written, seems to be a bit ambiguous about the >> source eTags and the meaning of "modified". >> My assumption is that an eTag, when used as a link attribute, should not be >> something generated by the link element creator but should be a mere passing >> on of an eTag generated by the server that hosts the resource that is linked >> to. Thus, eTag should be seen as something which, like "hash", simply >> records and passes on information related to the state of the resource at >> some specific point in time when it was previously accessed. In this case, >> you could never have a eTag attribute on a link if the linked-to server did >> not support eTags. If this assumption is correct, I think it might clarify >> things if it were stated in the draft. > > Agreed. > >> It seems that "modified" might be slightly different. In some cases, it >> seems reasonable that modified would be the modified or updated date >> reported on accessing a web resource. On the other hand, it seems like it >> would also be reasonable, in cases where the server does not report modified >> dates yet the author of the link has knowledge of the modification history, >> that the link author might include a modified date even though it is NOT >> reported by the server. However, this means that the link author is not >> simply recording and passing on data offered by the server. This means that >> the meaning of "modified" would be somewhat ambiguous. Am I reading this >> right? > > Yes.. I think we need to limit "modified" to the date reported by the > server. If no date is specified, the modified attribute should not be > used. The feed producer should not make up a value on it's own for > that attribute. The etag and modified attributes should provide enough > valuable information to perform a reasonable conditional get on the > linked resource. If the server doesn't provide that information in the > first place, then it's not of much value. > >> I continue to see evidence that formal systems for "Internet citation" or >> bibliography typically require that a "last accessed" date be included in >> citations. Thus, I'd like to suggest a new section (as discussed in earlier >> messages): >> >> X. The 'accessed' attribute >> >> The 'accessed' Attribute specifies a date and time when the >> resource identified by the atom:link or atom:content element was >> accessed. The 'accessed' attribute SHOULD record the most recent date >> and time at which the resource was accessed. The value MUST conform >> to the "date-time" production defined by [RFC3339]. An uppercase >> "T" character MUST be used to separate date and time, and an >> uppercase "Z" character MUST be present in the absence of a numeric >> time zone offset. The 'accessed' attribute MAY appear as a child >> of the atom:link and atom:content elements. >> >> accessed = attribute accessed { xsd:dateTime } >> >> An example accessed attribute for an enclosed MP3 file: >> >> <atom:link rel="enclosure" >> href="http://example.org/media/myfile.mp3"; >> accessed="2010-12-12T12:12:12Z" /> >> >> bob wyman >> > > +1. I've been looking at this also. We are going to need to include > some semantics for when the accessed attribute is omitted. This > attribute essentially needs to establish the point in time at which > the modified, etag and hash were considered to be valid... if it is > omitted, then the atom:updated has to be assumed to be the fallback. > > - James > -- - James Snell http://www.snellspace.com [email protected]
