- From: <Patrick.Stickler@nokia.com>
- Date: Wed, 12 Feb 2003 18:49:25 +0200
- To: <miles@milessabin.com>, <www-tag@w3.org>
> -----Original Message----- > From: ext Miles Sabin [mailto:miles@milessabin.com] > Sent: 12 February, 2003 17:34 > To: www-tag@w3.org > Subject: Re: Proposed issue: site metadata hook (slight variation) > > > > 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. You miss my point. *Neither* MGET nor GET+Meta: require any kind of global naming convention. Every server is free to do whatever it likes. If a server wishes to name the body of knowledge known about a resource, and specify that name in the header of a response, let it do so. Whether the response was to MGET or GET+Meta: is irrelevant. > <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 11:49:29 UTC