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

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

From: Simon St.Laurent <simonstl@simonstl.com>
Date: Thu, 07 Sep 2000 13:21:45 -0400
Message-Id: <200009071718.NAA22405@hesketh.net>
To: XML-uri@w3.org
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.

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

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

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

>Clear enough, no? Just like you have a clear
>enough picture of the number 42. If two
>numerals are the same (digit for digit,
>with an agreement about what radix we're using)
>then the numbers they denote are the same.
>But I don't know much more about the numbers --
>I don't know what color they are, if they are
>colored at all. Or what part of the plan they're
>on, if they're on this planet at all.
>But I can happily add and subtract them and
>go about my business.

Numbers are a lot clearer, despite the odd thrills of number theory.  I
have a far clearer - and much more useful - idea of what 42 constitutes
than http://www.w3.org/1999/xhtml.

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

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

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

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.
This mailing list is a start, but only a start.

Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
XHTML: Migrating Toward XML
http://www.simonstl.com - XML essays and books
Received on Thursday, 7 September 2000 13:18:37 UTC

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