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

[previous response incomplete]

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

Still, having to check each and every response, proactively,
to be sure the server understood what was asked seems overly
cumbersome.

After all, the design of HTTP is that there are methods (verbs)
and if the server doesn't understand, it shouts, otherwise
the client presumes that all is well.

I wouldn't want a solution that allowed complete breakdowns
in communication between client and server to have only
subtle indications.

I want the server to barf if it doesn't understand.

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

Like what? *Web* software? Why would you need to modify web
software that doesn't care about the semantic web. And if
some software doesn't understand the new verbs, so what? It
still can continue to function just fine without modification
and without impact by the introduction of semantic web
enabling extensions to other software.

You'll need to provide a specific convincing use case for me
to agree that the addition of MGET and friends is going to
impact any notable number of existing applications.

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

No. We don't have to take any such risk.

MGET and friends introduce no such risk, and no impact to the
present behavior of Web applications -- while providing a clear
and efficient solution for implementing Semantic Web applications
along side Web applications.

Patrick

Received on Wednesday, 12 February 2003 11:57:49 UTC