Re: Why MD5 Headers are Imperative

2006/8/18, Eric J. Bowman:
> My atom.dbxml file could have multiple <entry> nodes, there is no restriction
> against multiple nodes sharing the same atom:id (not an xml:id) provided as
> per RFC 4287 that their <updated> times differ.  The container element for
> the atom.dbxml file is <feed>.  So I'm fully compliant.
>
> The APP consensus is that I can only ever hope to manipulate the <entry> in
> that <feed> with the most-recent <updated> value for its atom:id.  But I want
> a protocol which allows me to interact with every legal <entry> in that
> <feed> even if two or more of them share the same Atom ID.
>
> What if I implement app:control app:draft?  As soon as there's a new draft of
> a document, it becomes exclusive under APP and nobody can go back and touch
> the existing document because its <updated> value is no longer most-recent.

That's the first really understandable message I read from you! ;-)

No, AFAICT, the current draft does not imply that you cannot store
more than one resource with the same atom:id (i.e. it does not suggest
a one-to-one relationship between a resource and an atom:id).
But yes, recent discussions on the list (e.g. about syncing) have been
based on that assumption.

I'd personnaly implement this by assigning "temporary" atom:id's to
the drafts, just as you'll assign temporary URIs to the "draft
resources", so there will be no problem at all. My point is that if
you make a copy of an entry for editing, then its a distinct resource
(its not "the entry" but "an editable copy of the entry"), so why not
assigning it a new atom:id. But note that the protocol has no notion
of "check-out" or "check-in", so this will be implementation dependant
and on the client side, not the server side. May I suggest you to
envision an extension to the Atom Protocol to support versionning à la
WebDAV? (merely check-outs/check-ins).

Just an idea...

--
Thomas Broyer