Re: FYI: I-D ACTION:draft-dusseault-http-patch-02.txt

    On Fri, 2004-07-09 at 12:42, Lisa Dusseault wrote:
    > As you point out, not all deltas apply to all formats.  That makes it 
    > harder for the server to create an empty representation to patch.  How 
    > would it work for, say, GDIFF?  What kind of file would the server 
    > create?  Would it be a text/plain file or some other MIME type?  
    
    Ultimately, servers are going to have to choose a patch application
    method based on the content-type of the PATCH content.  That method will
    know what it can patch, and will have to indicate an error should it be
    applied inappropriately - empty or non-existent resources are edge cases
    that don't need to be discussed at all in the description of PATCH.
    
I tend to think of "edge cases" not as details that could be left
out of the specification, but as test cases for whether the specification
makes sense.  I think we would normally prefer to see a simple
specification that adequately covers the edge cases (without special
treatment) rather than one that doesn't, or one that ends up with
layers of complexity to cover edge cases.

At the risk of sounding like a broken record, this seems to me
like a clear justification for separating "content-type" and
"instance-manipulation".  That is, in the PATCH request, use
IM to describe what kind of delta format (or range update, or
whatever) is being applied, and use Content-Type to indicate
the, umm, Content-type of the resource being updated.

In the normal case (the resource already exists), the Content-type
header of the request is either redundant, or (if you're paranoid) a
way of doing type-checking.  In the edge case (no resource yet),
the Content-type header tells the server what to create.  Seems
simple to me :-)

-Jeff

Received on Friday, 9 July 2004 14:44:38 UTC