Re: Why MD5 Headers are Imperative

"5.3
 
 Once a resource has been created and the URI of its Atom Entry Document (its 
 "Member URI") is known, that URI can be used to retrieve, update, and delete 
 the resource."

I'm saying this is a logical fallacy.  The Member URI may be used to update 
and delete the resource, but it will only ever retrieve a _representation_ of 
the resource.  Suggest:

"Once a resource has been created and the URI of its Atom Entry Document (its 
'Member URI') is known, that URI may be used to update and delete the 
resource.  The Member URI may also be used to retrieve a readable 
representation of the resource or, using the Atom Protocol, a writable 
representation of the resource."

>
>I'm not sure what problem you're trying to solve. It seems that you're 
>saying that the current HTTP machinery, using Last-Modified, Etag, 
>Cache-Control and so on is insufficient.
>

No, not insufficient.  Inappropriate.  The assumption is being made that any 
and every edit made via APP must be deemed significant.  So the Atom Format 
says this is up to the publisher, but the Atom Protocol (as currently 
written) gives this control squarely to the editor.

>
>example for that? In particular, why isn't a string ETag sufficient, and 
>if it isn't, why doesn't that cause problems in WebDAV as well?
>

Because WebDAV correctly assumes this determination is up to the editor.  
Since this is a perfectly reasonable fallback means of updating an Atom Entry 
Document when it is desirable to give this control to the editor, all the 
more reason to make sure that APP supports Atom-specific manipulations.

Here's the example:  I'm generating summaries elsewhere on my site using the 
placement of the <p/> tag (just for the sake of the example, although re-
serializing the XML is another example of an insignificant change) but this 
has absolutely no effect on any request for the full-content representation. 
The only consumers of this Atom Entry Document are readers who don't care 
about that <p/> tag and editors who do very much care about that <p/> tag.

http://canuck.bisonsystems.net/dev/atom/entry-client-2.xml

Without some differntiating mechanism, every time an editor changes the 
location of that <p/> tag will be de facto considered a significant change 
even if I as the publisher have determined that it will not change the value 
of <updated>.  So for the purpose of reading that Atom Entry Document, the 
previously-cached version whose eTag value was equal to atom:id+atom:updated 
remains the publisher's choice for the feed and any other resource on any 
other website derived from that feed.

I could go on, let me know how I should, what's not clear etc.

-EJB

>
>Eric J. Bowman schrieb:
>> ...
>> If the purpose of an Atom Publishing Protocol is to interface with Atom-
>> format documents which uniquely allow this divergence then some method other 
>> than HTTP cache-control must be used to determine whether the Member 
>> resource 
>> has been edited on the back-end in a way which has not changed its cached 
>> representation. What we need is some method to implement a "validated miss" 
>> which doesn't ivalidate requests (which may not have the purpose of editing) 
>> for the Member resource, but which serves an undeniably fresh editable 
>> representation to APP clients, while preventing the lost-update problem.
>> ...
>
>Eric,
>
>
>I'm not sure what problem you're trying to solve. It seems that you're 
>saying that the current HTTP machinery, using Last-Modified, Etag, 
>Cache-Control and so on is insufficient. Could you give a concrete 
>example for that? In particular, why isn't a string ETag sufficient, and 
>if it isn't, why doesn't that cause problems in WebDAV as well?
>
>Best regards, Julian
>