[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: eTag, modified and accessed attributes in Link Extensions Draft

Ok, new version of the Link Extensions draft has been posted..
includes the 'accessed' attribute...


- James

On Tue, Jun 1, 2010 at 4:40 PM, James Snell <jasnell@xxxxxxxxx> wrote:
> On Tue, Jun 1, 2010 at 2:27 PM, Bob Wyman <bob@xxxxxxxx> 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