Hi, I'm not sure what the status of the link extensions draft is, but if it's helpful there's in implementation of the hash attribute using MD5 for media-link entries in AtomBeat >0.2-alpha-3 [1], test case is at [2].
Cheers, Alistair [1] http://code.google.com/p/atombeat/wiki/ReleaseNotes#0.2-alpha-3 [2] http://code.google.com/p/atombeat/source/browse/trunk/parent/atombeat-integration-tests/src/test/java/org/atombeat/it/content/extended/TestMediaLinkExtensions.java On Wed, Sep 29, 2010 at 01:47:39PM +0200, Niklas Lindström wrote: > > 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. > -- Alistair Miles Head of Epidemiological Informatics Centre for Genomics and Global Health <http://cggh.org> The Wellcome Trust Centre for Human Genetics Roosevelt Drive Oxford OX3 7BN United Kingdom Web: http://purl.org/net/aliman Email: [email protected] Tel: +44 (0)1865 287669
