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.

<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