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
