W3C home > Mailing lists > Public > xml-uri@w3.org > September 2000

Re: I-D ACTION:draft-daigle-uri-std-00.txt

From: Dan Connolly <connolly@w3.org>
Date: Thu, 07 Sep 2000 13:37:03 -0500
Message-ID: <39B7E04F.1EE7151@w3.org>
To: "Simon St.Laurent" <simonstl@simonstl.com>
CC: XML-uri@w3.org
"Simon St.Laurent" wrote:
> At 12:07 PM 9/7/00 -0500, Dan Connolly wrote:
> >The one identified by that URI. It's not clear to me
> >that you need to know more about this resource other
> >than that it can be identified by that URI.
> >
> >If you do, can you explain why?
> Well, I might want to describe the Web page that rests there, I might want
> to describe the namespace it identifies, or I might want to describe XHTML
> 1.0 in some other general way.

What's stopping you?

This doesn't show me why you need to know more about
the resource.

> I don't have any way to distinguish between those choices based on the URI.
> It's clear what that URI represents.

It remains unclear to me that you need any such way.

> >If you want to know more about it, one of the
> >things you can try is to access it. In the
> >case of this resource, you're likely
> >to learn a little bit about its current state:
> >
> >       "This is an XML namespace defined in the XHTML[tm]
> >       1.0 specification. [...]
> >       This namespace may change without notice.
> >       [...]
> >"
> All you've done is provide an entity body which adds one more choice to the
> question of what I'm describing.

No, what you're describing is clear: it's the
one and only resource identified by the
URI http://www.w3.org/1999/xhtml .

>  An XHTML page that says it is a namespace
> is pretty much the same as 'this is not a pipe'.  Fun stuff, but too
> difficult to pin down to be useful.

Useful for what? What use do you have in mind
for which you need to know more about this
particular resource than that it is identified
by the URI http://www.w3.org/1999/xhtml ?

Many of us are satisfied with leaving the
term 'resource' largely unspecified, just like the term
'character'. You claimed that we need more
of a specification. I am asking you to justify
that claim.

> >Yes... if you do your GET request differently, you
> >might get a description in french or in XML Schema syntax.
> >W3C (i.e. the HTML WG) hasn't guaranteed that its state
> >doesn't change over time either, so you might
> >discover that this namespace is specified
> >by XHTML version 62 if you ask at some later date.
> >
> >But it's the same resoure, regardless of what
> >you learn about it over time.
> Actually, I wasn't talking about the GET returning different results.  The
> contexts were GET and xmlns="http://www.w3.org/1999/xhtml".

Oh. I see; at least, I think so... that is: as
written, the "namespaces in XML" spec doesn't
really say whether we should look at
the attribute value in
	<a href="http://www.w3.org/1999/xhtml">...</a>
where the value of the href attribute (once turned
from a URI reference to a URI) identifies something
in the Web, or ala

	<base href="http://www.w3.org/1999/xhtml"/>

where it's just a syntactic thingamabob that doesn't
necessarily identify anything at all, but is
just consumed for syntax-manipulation stuff.

If that's what you mean by "different contexts,"
then what you wrote (in your message of
Thu, 07 Sep 2000 12:07:49 -0500) seems out of place:
> It seems, however, that we may have different manifestations based on the
> context within which a URI is used

If you look at xmlns="..." ala <base href="..."/>
then you're not looking at it as a URI at all,
and the question of "exactly what is the resourc
that it identifies" doesn't make any sense.


> >> I'm tired of koans.
> >
> >I suggest that you deal happily with relationships
> >much like the relationship between resources
> >and URIs all the time. Numerals and numbers,
> >code points and characters, noun
> >phrases and the concepts they denote, etc.
> Yes, but I don't deal with them in computing environments where binary
> results are a very very necessary evil.

If you want binary results, deal with URIs, not

Computers compare persons' names (and addresses,
telephone numbers, height, weight, photograph,
etc.) but they don't compare persons. Likewise,
computers happily compare URIs all day long
without ever once bothering with the question
of whether two resources are identical.

I still don't see why you need more of a specification
of what a resource is.

> >> Then I suppose Namespaces in XML is foolish for using URI references in a
> >> fashion that ignores the resource (or fails to define the relationship
> >> between the namespace and the resource) entirely...
> >
> >Why? The functionality that "Namespaces in XML" gives
> >us is to associate a URI with some of the elements
> >and attributes in an XML document. That's all,
> >but it turns out to be handy for all sorts of stuff.
> All sorts of undefined stuff that lurches regularly over the behavior
> specified in Namespaces in XML.  Remember how you kept dropping schemas at
> namespace URIs? Now that's a recipe for confusion on a grand scale.

If you say so (that is: a lot of people do seem to get
confused when you say there is something to be confused about).

But by analogy, the TCP spec says a lot of
stuff that's not in the IP spec; is it likewise
a "recipe for confusion on a grand scale"?

I don't think so. It's just straightforward
layered design.

Similarly, I think using namespace names
to find schemas is just straightforward
layering of schema specs on top of the namespaces spec.

> >If uriOne and uriTwo are java strings that
> >conform to the syntax of an absolue URI,
> >then java's String.equal will work just fine.
> But URIs are far more complex than that, for reasons enumerated in RFC2396.

Not so. If you can compare strings, you can compare
URIs. Every URI is a string. URIs that are distinct
strings are distinct. I have said this any number
of times, and it's right there in the spec:

	"An identifier is an object that can act as a
	reference to something that has identity.  In the
	case of URI, the object is a sequence of characters
	with a restricted syntax."
	-- http://www.ietf.org/rfc/rfc2396.txt

But folks continue to show that they think otherwise.
I am at a loss.

> >> Section 6 of RFC 2396 is inadequate in circumstances where applications
> >> must deal with URIs of more than one scheme - especially if those URIs
> >> don't "use elements of the common syntax".  I'll take byte-by-byte or
> >> case-insensitive as a foundation happily, but it has to apply across the
> >> board.  It clearly doesn't, at present.
> >
> >strcmp()/String.equal doesn't? That's news to me.
> That works - but it ain't specified by RFC 2396 as an acceptable or
> mandatory fallback.

See above. RFC2396 does specify that URIs strcmp()/String.equal
can be used to compare URIs because it specifies that
they are character sequences.

> RFC 2396 seems to be a Torah without a Talmud.  It'd be nice to see the
> assumptions people have about RFC 2396 written down formally and compared.

OK: I assume that since URIs are specified to
be character sequences (this is quite explicit;
see the excerpt above) that a function
that compares character sequences can be used
to compare URIs.

That seems like a logical necessity to me, but
perhaps others would call it an assumption.

I'd be happy to see the spec revised to say
it explicitly, but it seems that we could
be at it a long time if we undertook to
specify all the things that are logically
entailed by RFC 2396.

I also interpret

	"An identifier is an object that can act as a
	reference to something that has identity."

to mean "exactly one something".

I take this as common (technical) usage
of the term "identifier" and "identity".

Again, I'd be happy to see the spec revised to
say so explicitly, but again, I think we could be
at it a long time if we undertook to spell
out the definitions of all the words and phrases
used in the spec.

> This mailing list is a start, but only a start.

Dan Connolly, W3C http://www.w3.org/People/Connolly/
Received on Thursday, 7 September 2000 14:38:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:44 UTC