Re: Site metadata; my preference

I'm tryign to keep this off of www-archive.

Patrick.Stickler@nokia.com wrote:
> 
> ...

> I'm very serious. And I've not been the only one to make this point.
> 
> It seems to me that your proposal makes SW applications second
> class citizens of the web since it takes twice the work to
> get their native content, metadata rather than representations.

That's not true. It takes exactly one dereference of a URI to get the 
REPRESENTATION of the metadata of URI X.

Sometimes, you need a previous URI dereference to know _what_ URI 
identifies the metadata of URI X, but heck, you very seldom care about 
the metadata of URI X without caring about URI X itself, so you are 
going to do two network transactions anyhow.

Furthermore, there is a big problem with the MGET proposal. It does not 
provide a way for a browser to be told that there is metadata available 
with a particular URI. This implies you need a header that says 
"MGET-available: true".

>>The URIs don't have any overhead on eth server, as the
>>resources are virtual documents generated in response to
>>a get in just the same way as you would generate  a response to
>>your MGET.  
> 
> 
> Fair enough. But there still is the need to have some means
> of autogenerating those metadata denoting URIs and if one can
> simply not need to, that is simpler.

This "autogeneration" is what thousands of marginally skilled CGI 
programmers do every day. Furthermore, the data that comprises the 
metadata lives somewhere. Unless we presume some complicated metadata 
management system, I think that that metadata will live in hand-authored 
text files with names (.metadata.xml) that the HTTP server knows is 
magic (alongside .htaccess and /index.html). Therefore the 
"autogenerated" URI is merely uri/.metadata.xml

> The quote doesn't apply to MGET! MGET denotes resources using
> URIs. The quote was about GET being perferred to POST because
> POST didn't specify a URI in the request. It's no
> more relevant than arguing MGET is bad because 2 out of 3
> dentists recommend a toothpaste with flouride...

You are incorrect. POST _does_ specify a URI in the request. The problem 
is that POST-abuses use the same URI to "tunnel" requests to various 
resources. When SOAP is used to abuse HTTP, you look at the SOAP method 
and one or more parameters to figure out what the "real" object is. 
Similarly, with MGET, you must look at the method to know whether the 
data you see going across the wire is the representation of the resource 
or the representation of the metadata of the resource.

  Paul Prescod

Received on Tuesday, 18 February 2003 21:07:57 UTC