RE: Some comments on the PATCH draft

But we can't really rely on that behavior. HTTP allows for content negotiation within a single URL, there is no obligation to provide different URLs for each type.

It seems like PATCH needs to distinguish between two different cases.

Content-type specific patch formats - For example Web3S has a format called Application/Web3SDelta+xml. This patch format only makes sense against resources that can be modeled with the Web3S infoset. So in this case the PATCH doesn't need to specify any particular content-type that is being 'patched' since the patch isn't occurring at the content-type level at all, it's occurring at an underlying resource modeling level.

Multi-content type patch format - Some patch formats can be used against anything that can be expressed as a binary stream. Other patch formats can be used against anything that can be expressed as a XML document. Etc. The point is that for these PATCH formats to work, in the case of resources that support multiple content types, there must be an explicit statement of what content-type representation the patch is intended to be applied to.

It seems like in the later case there should just be a specific header unique to PATCH whose semantics are "my generic patch format is meant to be applied against content-type X". While the header isn't sufficient to cover all negotiation possibilities for what a resource returns it would certainly seem to be necessary.

        Yaron

> -----Original Message-----
> From: ietf-http-wg-request@w3.org [mailto:ietf-http-wg-request@w3.org]
> On Behalf Of Stefan Eissing
> Sent: Tuesday, July 03, 2007 6:06 AM
> To: Andreas Sewe
> Cc: ietf-http-wg@w3.org
> Subject: Re: Some comments on the PATCH draft
>
>
> It would make sense to advise against PATCH support for resources
> where the representation to be patched is not determined by the URI
> alone.
>
> I think this is less of an issue than it sounds. In my experience,
> resources with content negotiation often have URIs for the different
> negotiated resources. Like apache which serves different languages on
> "/" but each language representation has its own URI.
>
> Cheers,
>
> Stefan
>
> Am 03.07.2007 um 14:32 schrieb Andreas Sewe:
>
> >
> > James Snell, the author of the recently revived PATH draft, has
> > asked me
> > to resend my comments for further discussion to this list.
> > (Originially
> > I send my comments to James only.)
> >
> > So here they are:
> >> What bothers me currently about the PATCH draft is that it refers
> >> to resources throughout even though what is actually patched is a
> >> *representation* of a resource.
> >>
> >> Besides being an issue of terminology this also has some
> >> implications when content negotiation is used. Granted, content
> >> negotiation complicates things quite a bit and might not be
> >> needed in most cases, but since PUT works fine even for
> >> negotiated resources I have the feeling that PATCH should work,
> >> too.
> >>
> >> The problem with the draft is, however, that the content type of
> >> the entity send cannot be determined, since the Content-Type
> >> header contains (rightly so!) application/diff or some such type.
> >> But the assumption that the base media type is that of the
> >> resource is false as soon as that resource has many different
> >> representations. Which representation should the diff be applied
> >> to?
> >>
> >> Representations might differ by Content-Type, Content-Language,
> >> etc., information which can be found in the Vary header. But
> >> besides Content-Type the other headers can be provided directly;
> >> only Content-Type carries the diff format's media type.
> >>
> >> Unfortunately, I can't think of a clean solution of the top of my
> >> head; both adding a header like Patched-Type and requiring a
> >> media type parameter like application/diff;type="text/plain" seem
> >> clumsy to me. But if PUT works with content negotiation, so
> >> should PATCH!
> >>
> >> Regards,
> >>
> >> Andreas
> >
>
> --
> Stefan Eissing
>
> <green/>bytes GmbH
> Hafenweg 16
> D-48155 Münster
> Germany
> Amtsgericht Münster: HRB5782
>
>
>
>

Received on Tuesday, 3 July 2007 21:02:56 UTC