Re: MGET and machine processing

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

> On Fri, Nov 21, 2003 at 06:20:12PM +0200, Patrick Stickler wrote:
>>
>> 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.
>
> I could say the same thing. 8-)
>
>> If the resource denoted by the-uri *is* an RDF/XML instance, then
>> the above request is *ambiguous*.
>
> You can lookup what every byte in that message means in RFC 2616, RFC
> 2396, and the IANA media type registry, so there's no ambiguity at all.
> Even if the the resource were a bag-o-bits or a timbl:Document (which
> most aren't), the request makes sense.
>
> For example, "http://www.markbaker.ca/2003/rdfforms/" identifies the
> RDF Forms namespace.  The namespace isn't an RDF/XML document, but an
> RDF/XML can be returned by dereferencing the URI (i.e. can represent
> the namespace).
>

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).

An agent should *not* have to look at the content itself to determine
if its request was understood. It should be able to discern from the
response header and status code whether the server understood its
request.

Again, I assert the approach you proposed produced ambiguous results.

>> 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.
>
> Not in my experience.  I'm using HTML/RDF conneg in my current project,
> and we've not had any problems.

Lucky you.

Just because you haven't fallen into the rat's nest, does not
mean it's not there...  and we're talking about a *global*
standard that *everyone* would be using -- so the fact that your
use cases don't intersect with these critical problems doesn't
justify your approach as optimal for that global solution.

>
>> 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.
>
> 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.

Patrick


>
>> Anyway, have a nice weekend ;-)
>
> Cheers,
>
> Mark.
> -- 
> Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

Received on Sunday, 23 November 2003 04:31:41 UTC