Re: Link Extensions Draft Update

[Alistair Miles <[e-mail]>]

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
> <[e-mail]> wrote:
> >
> > On 1/7/10 4:32 AM, "James Snell" <[e-mail]> 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: [e-mail]
Tel: [phone]