RE: now://example.org/car (was lack of consensus on httpRange-14)

Roy,

I apologize in advance for being clearly dense on this subject.  It
certainly is helpful for me to understand this area a little better.  And I
think we're getting close to the areas of my misunderstanding.

There are 2 assertions you made that I really don't get: 1) shouldn't change
software if resource becomes dereferencable; and 2) no implication that
resources identified by dereferencable schemes will actually be
dereferenced.  I'll explain my confusion on these assertions in reverse
order.

I know you have said it plenty of times, that identification and access are
separate, but for the longest time http: things were access oriented.  Heck
that's why the web is the set of network available information items.  I
really do think that somebody seeing an http: thingy gets a strong
implication that they ought to be able to have access to a representation.
The decision to make URLs and URNs into URIs didn't suddenly mean that
everybody now thinks of http: URIs as more for identifiers than for access.
It seemed really clear to me that URIs=URLs+URNs for syntactic comparison
purposes.  And any non urn: URIs are actually URLs.

And I did read through almost all of the uri mailing list last night and
today.  Some of the fun things I found: 1) the message from Marc Andreessen
about wanting to wrap up URLs as back end and out of user-site mechanisms so
he could start working on URNs; 2) the discussions about whether urls should
be prefixed with url: in plain text like email to indicate the presence of a
link.  Reminds me of our 4 year old xlink and html discussions on link
identification.  3) I was briefly confused about the discussions around SOAP
that happened in 1994.

Exploring this a bit further, I'll quote a part of 2396.  I know that you
know it off by heart so I'm not trying to be cheeky, but it helps me in
expressing my position.  "A URI can be further classified as a locator, a
name, or both.  The term "Uniform Resource Locator" (URL) refers to the
subset of URI that identify resources via a representation of their primary
access mechanism (e.g., their network "location"), rather than identifying
the resource by name or by some other attribute(s) of that resource."

When I take an http: URI and then classify it as a locator, name or both, it
turns out it is a locator because http: is the primary access mechanism, eg.
network location, for the URI.  So saying that an http: uri does not imply
access in any way just blows my mind.  The only reason the xmlns identifier
doesn't imply access is because the namespace spec said so, and still people
keep on thinking or implying it does.  Namespaces had to specifically
mention the lack of access, and lots of people said it over and over again,
and still it didn't stick.

I want to re-emphasize that I agree totally that http: URIs do not REQUIRE
access.  I just don't seem to understand why you don't think it implies
access.  Cuz it sure does to me and apparently a whole bunch of other
people.  And having every spec that uses URIs have to say whether or not
that access should be done (like namespaces), when it could be (at least
from my pov) more easily expressed in having different schemes, seems to
place an undue burden on developers and software.

On to the first assertion.  I'm still confused about why you don't see the
utility in changing behaviour.  I think this is my central misunderstanding
of your position, because it I guess I'm too uninformed to figure why we
wouldn't want software to do something different.  I picked up the idea
because people starting talking about how great the world was going to be
when things that were only for identifiers could now be used for access, and
the gloating over those poor folks who were using urns commenced.  I started
thinking about how the software would actually work to do it, and I came up
against a situation where it appears that "magic" happens.  To illustrate:
If I create an xmlns identifier that says http://foo, and I don't provide a
resource, then it's clearly an identifier.  A human/machine that attempts to
deref the identifier gets a 404.  If I then change my mind, and provide a
resource because I want them to have more info, I provide a resource and
representation(s).  I want the client to do something different, that's why
I'm now providing the representation(s)!   But the client doesn't know that
I've now decided to provide information.  In order for the client to do
something different with the same URI value, magic has to happen.  That's
what's baffling to me about your position, that you don't want the software
to do something different if a representation can now be provided, yet I do.

Assuming that I want the software to do something different, if we used one
scheme for identifiers, and then another for access, then it's super duper
separated.  In fact, it seems to me to be super clear to people how xmlns
should be used if we said something like "The namespace name SHOULD be
dereferencable.  In such cases, a foobar document should be the
representation type.  In cases where the namesapce name is not
dereferencable, the namespace name scheme should be
some-non-dereferencable-scheme".  Then software can go: is it non-deref?
Yes, don't worry about it.  No, at some point get the representation.  If a
404 happens, there's a problem and I might have to error as I need the
representation.  And the software that compares namespace names at run time
will know to change it's behaviour of the namespace name changes.  And a
human authoring the namespace name also can clearly indicate via the uri
whether it's dereferencable or not.

So perhaps you can explain to me why software wouldn't need to change when a
URI went from having no representations available to having representations
available.

Cheers,
Dave

> -----Original Message-----
> From: Roy T. Fielding [mailto:fielding@apache.org]
> Sent: Thursday, October 10, 2002 3:08 PM
> To: David Orchard
> Cc: www-tag@w3.org
> Subject: Re: now://example.org/car (was lack of consensus on
> httpRange-14)
>
>
> > Given the lack of constantness, how does a user of a thing
> know when it
> > changes from one form to another?  Presumably we want the
> software to do
> > different behaviour depending upon whether it's concrete or
> abstract.  And
> > the only tool we have is the name.  And changing the name means that
> > software and humans will have a chance at knowing to do things
> > differently.
>
> On the contrary, we do not want the software to do anything different.
> I don't understand where you picked up that idea.  The purpose of the
> representation, if any is available, is to provide information about
> the resource (to describe its current state).  There is no implication
> whatsoever that the client is going to access that resource, just as
> there is no implication today that the xmlns identifier will
> be accessed
> during the processing of XML.  Identification and access are separate.
>
> ....Roy
>
>

Received on Thursday, 10 October 2002 23:40:04 UTC