W3C home > Mailing lists > Public > www-tag@w3.org > February 2004

RE: HTTP Methods. MGET.

From: <Patrick.Stickler@nokia.com>
Date: Sat, 28 Feb 2004 21:50:26 +0200
Message-ID: <A03E60B17132A84F9B4BB5EEDE57957B02A2E996@trebe006.europe.nokia.com>
To: <waldenm@optonline.net>, <danny666@virgilio.it>
Cc: <www-tag@w3.org>

-----Original Message-----
From:	www-tag-request@w3.org on behalf of ext Walden Mathews
Sent:	Sat 2004-02-28 17:01
To:	Danny Ayers
Cc:	www-tag@w3.org
Subject:	Re: HTTP Methods. MGET.

: It's probably been mentioned already, but switching on the mime type
: work as-is, as the RDF/XML won't usually be about the resource identified
: the uri. I've a feeling Patrick also had an answer for the suggestion of a
: different mime type...

Abstracting from the actual protocol implementations for a second, is it
true that all that is needed is some way to unambiguously mark a GET
request so it's clear that it's asking for resource.description, as opposed
to resource.representation?  I don't believe I've ever witnessed consensus
on that yet in this thread.

          I agree, so long as (a) the server clearly understands or does not
          understand the request and (b) side effects or incorrect responses
          do not occur if the server does not understand the request.

          There has been an RFC floating around for some time introducing
           manditory headers into HTTP, such that if the server doesn't understand
           a manditory header, it signals an error rather than simply ignoring the
           unknown header and proceeding. If such machinery existed in HTTP,
           then the new methods would NOT be necessary.

           But because there is no way to ensure that side effects or inefficent
           responses occur (such as returning a 30MB representation because 
           that special header wasn't understood), the only solution I've been able
           to come up with is the introduction of distinct methods providing the
           desired behavior in a reliable, efficient, scalable, and robust manner.

           If anyone thinks they have a better idea, I continue to wait to hear it.

           I've not yet heard better.


: Incidentally, Roy states "doubling method space is evil", and shows a
: similar sentiment about halving method space, as HTML forms tends towards.
: Is this because it has been determined (through formal reasoning?) we have
: *exactly* the methods we'll ever need, or merely that only minor,
: incremental additions/reductions should be considered?

Sorry if I failed to find the answer to this in Patrick's publications, but
MGET is the vehicle into description space, and descriptions are properly
identified resources, then are the other M* methods really needed?  If not,
then the "doubling" problem is mitigated, right?

          The other methods are needed if we wish to allow interaction with
           descriptions other than retrieval. E.g. adding to the knowledge about
           a resource or removing some or all of the knowledge about a resource.

           Also, note that the semantics/behavior of MPUT/MDELETE do not differ
           from PUT/DELETE simply in the matter of dealing with descriptions rather
           than arbitrary representations -- but also in that they are not absolute,
           but partial operations on a description. PUT completely replaces an already
           existing representation (if any). DELETE completely removes a representation.
           Yet MPUT adds to the description of a resource. And MDELETE can partially
           remove statements from the description of a resource (or remove it entirely).

           So, even if headers are used, it would seem to me inappropriate to use PUT
           and DELETE since the header would actually change the semantics of the
           traditional methods.

           So to that end, I really don't see how URIQA is "doubling", because the
           new methods are not trivial copies or slight variations of the existing methods.


Received on Saturday, 28 February 2004 14:50:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:03 UTC