[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri-comment] Comments on Extensible Resource Descriptor (XRD)Version 1.0 Working Draft 11
On 01/11/2010 11:02 AM, Will Norris wrote: > > I'm actually working on this now. I noticed we had a slight inconsistency in the spec, as to whether the document was still valid (in the expiration sense) at the exact time instant specified by<Expires>. In clarifying that, I've also changed the wording: > > The<Expires> element contains a dateTime value which indicates the time instant at which the document has expired. > > I agree that the term "valid" can be somewhat ambiguous, especially when used in a specification defining an XML language. Does that answer your questions, or is there still more there that could use additional clarification? > The specification text for this element does explicitly mention that it is independent of the caching semantics of the transfer protocol, but it seems like there should be more clarity about the interactions between an XRD expires and an HTTP expires. For example, if the HTTP expires is later in time than the XRD expires, during the time period between the two is it valid to interpret this as there being no valid XRD metadata? If I use the caching behavior of a standard HTTP implementation this is effectively what will happen unless I force it to revalidate its cache once the XRD metadata expires. While I can understand that the XRD specification wishes to remain transport-agnostic, I think it would benefit from a sentence or two explaining the expected behavior when any transport-protocol-specific caching mechanism outlives the XRD metadata, perhaps going so far as to say that parties publishing XRD metadata MUST ensure that it does not become invalid at an earlier time than the representation describing that metadata.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]