Re: MGET and machine processing

On Friday, Nov 21, 2003, at 17:14 Europe/Helsinki, ext Mark Baker wrote:

> GET the-uri HTTP/1.1
> Accept: application/rdf+xml

Sigh... I've addressed this use case so many times I've lost count.

If the resource denoted by the-uri *is* an RDF/XML instance, then
the above request is *ambiguous*.

At first glance, it seems like GET, PUT, etc. should work fine,
with a few headers tossed in, but in actual practice, it's a
rat's nest.

A SW agent should *not* have to examine the content returned
to determine if it is what it asked for. Either the server
understood what it meant (and the protocol is sufficiently
precise to achieve that) and returned what the agent asked
for, or it returns an error.

>> I've already conceded that one should add new methods rarely, if
>> at all -- just as with new URI schemes -- yet have also argued, from
>> real world implementational experience, that the new methods are
>> necessary.  If you can prove otherwise, fine, I'm all ears. But I
>> fail to understand your opposition to solutions such as URIQA in
>> the absence of either solid arguments/evidence that such solutions are
>> not needed or that better solutions to the same problems exist.
> How's that then?
> FWIW, I like the "URIQA-uri" header. 8-)  It addresses the
> self-descriptive problem with people using fragids on URIs to identify
> resources, in much the same way that the Host header solved the
> self-descriptive problem of partial URIs in the request line.

> I haven't fully thought through the implications though.  I'd prefer
> that folks simply stopped identifying resources using fragids.

Oh, I couldn't agree more ;-)

Or at least, that the entire global web infrastructure be fixed to treat
URIrefs with fragIDs as first class citizens...

>  But
> that's another (perma) thread. 8-)

And one that tends to feel more like a religious debate than
a technical one...

Anyway, have a nice weekend ;-)


> Mark.
> -- 
> Mark Baker.   Ottawa, Ontario, CANADA.

Received on Friday, 21 November 2003 11:25:51 UTC