- From: Miles Sabin <miles@milessabin.com>
- Date: Wed, 12 Feb 2003 15:34:15 +0000
- To: www-tag@w3.org
Patrick.Stickler@nokia.com wrote, > I agree that it is ugly and impractical, and would expect servers > to do something more elegant, BUT note that the same issue exists > for the Meta: approach. MGET and GET+Meta: are equivalent in > semantics, and in either case, you'd have to come up with some URI to > denote the body of knowledge known about the resource, if you wanted > to say anything about it, etc. That's true, but no _global_ convention is needed for this to work in the GET+Meta case. One site might map /foo to /meta/foo, another might map it to /foo.meta or whatever was most convenient for their particular cae. Not depending on everyone having to agree on and adopt a global convention would make something like this far more likely to succeed. <snip/> > Well, a *big* problem I can see is that the client won't *know* that > the server has not understood it -- unless it is a requirement that > the server always return a Meta: tag (even if empty) to indicate that > it is returning a description of the resource rather than a > representation. I think that'd be the right way to go: a Meta-Location response header would be required, but could be empty if the server didn't wish to name the metadata resource. <snip/> > > I disagree ... I think there are serious technical obstacles to > > deploying a new request method. > > I'd love to hear them. Umm ... how about upgrading huge swathes of deployed software? > > > 5. Can the semantics of PUT and DELETE (at least) also be > > > modified to take the Meta: tag and thus allow the manipulation of > > > knowledge on the server (permissions allowing, of course)? > > > > Yes, with the proviso that a server which doesn't understand > > Meta will ignore it, and treat the PUT/DELETE as applying directly > > to the resource identified by the request URI rather than to it's > > metadata. > > Here's where my alarm bells go off. That would be a catestrophic > failure and a head on collision between the Web and Semantic Web. > > I'm beginning to see MGET as being safer and better than GET+Meta:, > even if the latter would have been easier to implement. > > It's just too dangerous and confusing and risky to mix the Web > behavior of a server with the semantic web behavior of the same > server. Best to have clear and distinct methods to differentiate > between them. Well, I think it's a case of taking a risk or it'll never happen. Cheers, Miles
Received on Wednesday, 12 February 2003 10:34:47 UTC