Re: MGET and machine processing

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

> > 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".  The difference between the perfect
solution and the one we have is *MINISCULE* for 99% of what one might want
to do with conneg.

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?

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

Received on Sunday, 23 November 2003 17:07:32 UTC