Re: ERB call on addressing

>>It really boils down to whether you think the Xptr is addressing
>>something or not.
>
>Yup.  Obviously.  Also, it's a query.  I totally fail to see the
>utility, or even the existence, of a distinction between an
>address and a query.  Given the URL 
> http://docs.sun.com/ab2/alluser/ADVOSUG/@xmlToc
>tell me please, is that an address or a query?

An address. Is "c:\gtn\mydoc.html" a query against "gtn"?
To me an address returns a resource (a deterministic
result), while a query does not necessarily return
anything.

>I have no trouble with this at all.  On the web, a resource is,
>by definition, something that can be addressed.  So what a URL
>points at is a resource.  By definition, what an Xptr points at
>is also a resource.  Our innovation is to standardize (unlike
>the web) a rich query-or-address-call-it-what-you-will for XML docs
>which operates at a finer level of granularity than the URL.
>Thus it makes intuitive sense, and is logically clean, to call
>what the URL+Xptr gets you a sub-resource of the resource that
>the URL gets you.

It makes equally as much sense to say that an Xptr points to
a resource (as you note yourself) and to not have a distinction.
XML even allows arbitrary well-formed sub-trees to be parsed
outside of the context of the containers above it, lending even
stronger weight to the idea that any resource (by your definition)
is addressable by itself. The fact that groves codify the object
structure also adds weight.

>>Using ";" is accepted practise, and provides the right semantics
>>for XML (addressing)
>
>Based on my reading of the RFC's and my experience operating servers
>and using the web, I disagree with both halves of this sentence.

Well, let's agree to differ, because I have a least as much
experience in the WWW as you, and the software that I am responsible
for works perfectly well with parameters, thank you very much.

>Bill Smith has raised the issue of the RFC as a moving target, sigh...
>existing RFCs talk of
>
> <path>;<params>?<query>#<fragment>
>
>but "this year's model" is quite different.  However, no matter how you
>cut it, ";" flags a vaguely-specified "parameter" we want something with
>a highly-precise, and new-to-the-web, semantic.  Smells like new syntax
>to me.  Also, ';' is obviously a moving target, which is another reason
>to stay away from it.

Bollocks. I question the need for any "new-to-the-web" semantic,
because we've had sub-document addressing for more than 2 years.
If a URL is an address for a resource (something that is 
addressable), what more do you need? Why do you need to create
some artificial distinction between a resource and a sub-resource,
which by your definition, are the same thing (something
addressable)? All you are really doing is reinventing something
like my proposal of long ago with a different syntax and hairy
semantics.

>BTW, you Inso and Sun guys ought to raise a ruckus with TimBL and
>Roy Fielding, n'est-ce pas?

No. An RFC is an RFC. It is not a standard. It is not even normative.
RFC's codify existing practise or ideas. Running code wins in the
IETF, and we've had running code for over 2 years.

I agree with Lee. We need client-side fragment specs, but nothing
else. Everything else is an address into the address space
of the server, and it controls the format and interpretation of
them. I find parameters much cleaner, and will use them.

Received on Monday, 24 March 1997 22:55:54 UTC