Hi James! It's been great to see this draft revitalized and progressing. I am certainly in favor of the non-namespaced attributes and the generalized "hash" approach.
I understand Eric's objection that "significant" may not always include hash changes, so changing that to a "MAY" sounds reasonable. (I have no concerns in general about specified significance, since we have very specific requirements on our publishers regarding both updated and hash. In our case, *any* change is significant, and we require hash values to be correct -- but since this is enforced at our own contract level, we don't need such requirements in the spec.) I have two questions: 1. I am a bit concerned about referencing a Candidate Rec (CSS3 Media Queries). Might that stall this from becoming an RFC? (In any case, the link in version 7 of this I-D is outdated, the current CSS3 Media Queries CR is from 27 July 2010.) If so, maybe it's better to split that part out? 2. I wonder if you have an estimate on what's needed to get this to Last Call? I'd like to help as much as I can, but I don't really know how (apart from expressing my support on this list). Implementation-wise, I can donate any specific implementation code you need (at least in java), but probably won't have time to wrap up and publish a hosted source project (e.g. a properly packaged Abdera extension) anytime soon (although I can contribute to such if the infrastructure was in place). (Background recap: we are using the hash mechanism in an egov project [1], and publishers are starting to implement it. We need to inform of the (hash attr) syntax changes to the publishers (less than 5 are currently implementing this, but some 95 more are to follow over the coming year(s)). Thus we really need to work to ensure the stability of the current syntax. We are certainly aware that it's not proper conduct to reference I-D:s, but have chosen to take the risk of changes in this case over inventing our own extension for such a generic thing as hash digests.) Thanks for your efforts! Best regards, Niklas Lindström, Valtech [1] The Swedish Legal Information System (Docs in swedish: <http://dev.lagrummet.se/dokumentation/>.) On Sun, Jul 4, 2010 at 12:52 PM, eric scheid <[email protected]> wrote: > > On 1/7/10 4:32 AM, "James Snell" <[email protected]> wrote: > >> http://www.ietf.org/internet-drafts/draft-snell-atompub-link-extensions-07.txt >> >> A few minor updates, and one significant update... the new requirement is >> that >> changes to the hash, etag, modified and accessed attributes MUST be >> considered >> to be "significant" with regards to the value of atom:updated. This is a >> requirement on the feed publisher. > > -1, sorry, can't agree with this > > The "atom:updated" element is a Date construct indicating the most > recent instant in time when an entry or feed was modified in a way > the publisher considers significant. Therefore, not all > modifications necessarily result in a changed atom:updated value. > > atomUpdated = element atom:updated { atomDateConstruct } > > Publishers MAY change the value of this element over time. > > A minor and trivial change to a linked resource, eg. whitespace, could well > cause a change in (eg.) the hash, but that (usually) is not significant. > > Similarly a change in the 'accessed' attribute especially when the 'hash' > and 'etag' *didn't* change is pretty much the definition of not-significant. > > s/MUST/MAY/ > > > e.
