W3C home > Mailing lists > Public > www-rdf-interest@w3.org > November 2003

Re: MGET and machine processing

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Tue, 25 Nov 2003 19:21:49 +0200
Cc: www-rdf-interest@w3.org
To: "ext Mark Baker" <distobj@acm.org>
Message-Id: <DA8FEDAF-1F6B-11D8-8456-000A95EAFCEA@nokia.com>


On Monday, Nov 24, 2003, at 16:55 Europe/Helsinki, ext Mark Baker wrote:

> On Mon, Nov 24, 2003 at 02:41:34PM +0200, Patrick Stickler wrote:
>> 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.
>
> Right.  Using a different URI would be another way to do that! 8-)

Both representations *and* descriptions are distinct resources
from the resource denoted by a request URL (except for the special
case where the resource is a digital entity and the representation
is a bit-equal copy of it).

So whether you are asking the server for a representation or
a description, you should (usually) expect to get back *something
else* and have the URI denoting that something else specified
in the response header.

But one cannot know, from some URI, what some *other* URI denoting
a description of the thing denoted by the first URI might be, no
more so than one can know what URI might denote a representation
returned for some request having a *different* request URI.

>
>>> 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.
>
> I was thinking that you'd want to use it on a new content negotiation
> header, rather than resolutionMode, as I believe the latter is more
> suitably communicated by using a different URI, per above.
>
> e.g.
>
> M-GET http://example.com HTTP/1.1
> Man: http://sw.nokia.com/URIQA-1; ns=1
> 1-MAccept: application/rdf+xml
>
> where "MAccept" is defined to have the conneg semantics you need.
> The mandatory extension semantics of 2774 only apply to headers, not
> their values.  So all 2774 is giving you here is the ability to deploy
> a new feature, not fix a "broken" one.

No. Content negotiation does *not* do the job. And we will want
to use content negotation *as* content negotiation, for requesting
different possible encodings of descriptions.

I've pointed this out before.

In short, content negoation does not work, nor should it be overloaded
in this fashion, as the semantic distinction between description and
(other form of) representation has nothing whatsoever to do with
encoding (even if RDF/XML is a default encoding for descriptions).

>
>> 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'd simply describe it as doing what HTTP should have done in the first
> place.  Practically, yes, those are new methods, but they really need 
> to
> be new because they're incompatible with what they aim to replace; one
> can't describe the behaviour of FOO in terms of M-FOO, but can describe
> M-FOO in terms of FOO.
>
> Perhaps that's what you meant, dunno.

That's what I meant.

RFC 2774 IMO is encouraging in that it demonstrates that I'm not the
only one who considers the existing methods with only optional headers
insufficient for failsafe extensions. I.e., there *are* cases when new
methods are needed (whether they be real new methods or virtual new
methods, per 2774 with M-* + manditory headers).

>
>> 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.
>
> RFC 2774 was DOA.  It was well thought out, but needed to be deployed
> in conjunction with addressing a compelling problem in order to see
> wide spread use, IMO.
>
> Roy Fielding's next protocol, Waka, will have mandatory extensions
> baked in, along with a lot of other HTTP issues resolved and some new
> features.  See;
>
> http://gbiv.com/protocols/waka/

That's kinda what I suspected. And probably why I had missed it.

I think we'll see much easier deployment of MGET and friends than
something as ambitious as RFC 2774.

Patrick


>
>> Thanks for the pointer.
>
> No problem.
>
> Mark.
> -- 
> Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Received on Tuesday, 25 November 2003 12:42:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:52:03 GMT