Re: URIQA

Patrick Stickler wrote:
> 
> ...
> 
> This works for GET, but not for PUT or DELETE.
> 
> An early stage of URIQA development actually defined special MIME types
> for concise bounded descriptions (in an attempt to try to accomplish what
> was needed without any extensions to the present Web architecture) -- but 
> ambiguit arises when performing e.g. a PUT because the behavior of the 
 > server differs depending on whether the input is a
 > representation or description.

I'm not sure that the definition of PUT is that clear. Let's say you 
have a resource representing a "white paper" with representations in 
XML, HTML and PDF. Does a PUT to PDF necessarily obliterate the XML? Or 
does it just replace the PDF rendition?

The safest thing is to have a separate URI for the PDF rendition and PUT 
that.

As far as DELETE, I don't understand why you would DELETE (as opposed to 
clear) the description of an object. Either the resource exists or it 
does not. If nothing is known about it then it should have an empty 
description. But the description doesn't have to be deleted.

 >...
> To do this, the best solution that I've been able to come up with which
> requires the least modification to the existing Web architecture is a single
> header (serving as a flag) which allows us to differentiate between dealing
> with representations from dealing with descriptions.

This is actually quite a big change to web architecture. It will confuse 
vast amounts of technology like caches.

> ...
> I agree, and if you look at the behavior of the reference implementation of
> URIQA (and this is also noted in the URIQA spec) all concise bounded
> descriptions are distinct resources in their own right, and are given
> distinct URIs.

Then that's where you should PUT.

> This also allows one to use PUT/DELETE to interact with those distinct
> representations, including the use of conneg, in a traditional fashion.

So you've solved the problem without the need for those headers!

  Paul Prescod

Received on Tuesday, 1 July 2003 19:31:15 UTC