Re: MGET and machine processing

On Monday, Nov 24, 2003, at 00:09 Europe/Helsinki, ext Mark Baker wrote:

> On Sun, Nov 23, 2003 at 11:27:51AM +0200, Patrick Stickler wrote:
>> If http://example.com/foo.rdf denotes an RDF/XML instance, then
>> if you get back RDF/XML, you cannot tell, from the *server's* response
>> whether it is a representation of the RDF/XML instance denoted by
>> the URI (encoded as RDF/XML) or a description of the RDF/XML instance
>> denoted by the URI (encoded as RDF/XML).
>
> It's a representation (of the identified resource).  When you use GET,
> that's what you're *asking* for.

Er. Like. Uh. that's why I propose using MGET rather than GET,
because of the need to be clear that what one is requesting is
a description, not (merely) a representation.

> If you're using GET to return
> something else, such as the representation of another resource (which 
> is
> what a "description" is, as you use the term) I can understand why 
> you'd
> be having problems.

Well, while I consider it acceptable to treat a description as
a representation, it is nonetheless necessary to be clear about
the distinction when interacting with the server.

>
>>> Sure, it's not ideal, and if HTTP had mandatory extensions we 
>>> wouldn't
>>> have this problem.  But it's by no means a big deal in this specific
>>> case since you can just check if the media type that's returned is 
>>> the
>>> media type you asked for.  Suck it up! 8-)
>>
>> Er. Well, this is precisely what I meant earlier by "sloppy hacks".
>> The amount of potential (or rather, likely) overhead to work around
>> ambiguous behavior on the part of servers will be too costly in the
>> long run. It's OK for a single system, but not for a global standard.
>>
>> Sorry, that just doesn't satisfy my expectations for a well engineered
>> SW architecture, particularly given the far greater need for precision
>> and reliability that the SW has over the Web in general.
>>
>> Nope.
>
> It is by no stretch a "sloppy hack".

I'm sorry, but I consider any protocol which produces ambiguous
results to have a degree of slop in it.

> The difference between the perfect
> solution and the one we have is *MINISCULE* for 99% of what one might 
> want
> to do with conneg.

Yet if that 1% is critical, it's critical. I'm not looking for a perfect
solution, just one that meets some minimum requirements. Conneg does
not meet those requirements.

>
> If it's such a big deal for you, and you really need must-understand
> conneg semantics, then why aren't you using M-GET (per RFC 2774) 
> instead
> of MGET?

Good question. I admit I was not sufficiently familiar with RFC 2774 
(and
given the months of discussion over this issue, it's interesting that
this is the first time anyone has pointed it out to me).

Indeed 2774 looks like it might have the necessary features to meet 
those
minimum requirements. I need to read through it again in more detail, 
but
if it is the case that given the request

M-PUT http://example.com HTTP/1.1
Man: http://sw.nokia.com/URIQA-1/; ns=URIQA
URIQA-resolutionMode: description

if the server does not understand what the manditory header
URIQA-resolutionMode: means, it must issue an error response
rather than touch any representation, then that looks very promising.

Though, it still *isn't* the same as PUT. If 2774 works the way I
understand it after a quick read, what you really have is a means
to define virtual new methods which are constellations of M-* with
certain manditory headers. I can see the implementational efficiency
in such a generic approach. But the end result, insofar as semantics
and behavior of the server are concerned, is equivalent to introducing
new methods. It's just a more generic way to do it.

I'll have to look closer at this.  I'm curious, though, how broad the
deployed support is for RFC 2774...  and if/when it would be 
incorporated
into or blessed in conjunction with the HTTP spec.

Thanks for the pointer.

Patrick


> Mark.
> -- 
> Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

Received on Monday, 24 November 2003 11:38:25 UTC