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

RE: Proposed issue: site metadata hook (slight variation)

From: <Patrick.Stickler@nokia.com>
Date: Wed, 12 Feb 2003 18:49:25 +0200
Message-ID: <A03E60B17132A84F9B4BB5EEDE57957B01B90B44@trebe006.europe.nokia.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:16 GMT