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

Re: MGET and machine processing

From: Mark Baker <distobj@acm.org>
Date: Mon, 24 Nov 2003 09:55:55 -0500
To: Patrick Stickler <patrick.stickler@nokia.com>
Cc: www-rdf-interest@w3.org
Message-ID: <20031124095555.I1020@www.markbaker.ca>

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

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

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

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

> Thanks for the pointer.

No problem.

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Received on Monday, 24 November 2003 11:39:16 GMT

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