[
Lists Home |
Date Index |
Thread Index
]
On Sat, 2002-08-03 at 13:38, Uche Ogbuji wrote:
> > Ugh. I've been avoiding responses. My suggested change was to change
> > the statements that "a namespace name is a URI reference," wherever they
> > appear, to "a namespace name is not a URI reference." It's just a
> > string.
>
> Hmm. I prefer John's wording. I think your would just increase the confusion.
I'm not certain I agree. I almost think that the motto of the
Namespaces in XML specification should be "A namespace name is not a
URI." It can't be treated as a URI in any useful way.
A namespace name is a one-way transformation of a URI into one of its
possible lexical representations. Multiple namespace names may be
generated from a single URI.
> > The solution that I *vastly* would prefer is to make namespace names URI
> > references. If they are URI references, then they follow the rules for
> > URI references, in terms of comparison for equality, and normalization.
> > This would mean that you'd have to actually look at the URI to see if
> > it's a known scheme, and if so, use the comparison rules of that scheme
> > (a lot of URL-style schemes are quite similar, if that makes a
> > difference, and are also the most widely used). This would mean that
> > http://www.talsever.com/ and http://www.Talsever.com/ compare equal.
>
> I think part of the problem for this is that it would greatly complicate
> NS-aware software.
I agree, to an extent. I think one of the reasons for selecting URIs,
rather than, for example, reversed domain names (case sensitive, mind)
in the style of java package naming, was probably an underlying
expectation that URIs are well supported.
Unfortunately, by divorcing namespace names from URIs immediately after
generation of the name, deployed URI parsing software can't be used.
Granted that there's a lot more string comparison software about, the
problem with using it is that namespace names *look* like URIs, even
though they aren't. So it's tempting to use URI-related software, and
the rules of comparison that the URI registrations take such care to
specify, when it turns out to be ... wrong.
> After all, the fact that an authority based on DNS is just
> one rule from one species of URI. As an example of another that would have to
> be implemented, in a UUID URN, dashes are optional, so that
>
> urn:uuid:3c3b8cd7-3c9a-4cc7-b6af-f180dd757568
> urn:uuid:3c3b8cd73c9a4cc7b6aff180dd757568
>
> And yes, I've used UUID URNs in practice, so this is not just an academic
> objection. I believe OIDs and FPIs have their own comparison schemes.
>
> As you can see, this gets out of hand quickly.
*shrug* I don't think it's any different from the current situation,
really. There are a number of possible routes to cope with it,
including UnknownURISchemeException (in languages that support
exceptions), or returning the value "true," "false," and
"false-by-simple-string-comparison" from the operation testing whether
two URIs are equal.
> > The drawback to making namespace names actually *be* URI references,
> > rather than strings that bear a strong resemblance to URI references but
> > no shared behavior at all, is that inconsistent results may occur,
> > depending upon whether the parser recognizes the scheme. An
> > unrecognized scheme can only be compared, as now, character-by-character
> > for equality with no normalization, no case-insensitivity. So a parser
> > that does recognize the scheme may give different results than a parser
> > that does not.
>
> Exactly. I don't think this is tenable.
I do. *shrug*
> > "relative string" is fairly meaningless, as things now stand.
>
> "relative string" is pretty meaningless. Period. Where did you see it come
> up?
I made it up. A namespace name is a string, period. It happens to be
generated from a URI, but it stops having any URI characteristics, at
all, as soon as it is frozen into a particular namespace name. This is
one of the reasons that I prefer the formulation "a namespace name is
not a URI." It avoids silliness that says, well, it's sort of a URI,
only not really, and thus avoids the silliness of talking about relative
URIs, when there aren't any absolute URIs about to hang a relative
from. They're all strings. Once you admit that a namespace name is not
a URI, and is in fact a string, then it becomes clear that talking about
relative namespace names is talking about relative non-URIs is talking
about relative strings. At which point the absurdity of that particular
debate becomes fairly clear.
>
>
> > With a change, "relative URI" might have meaning.
>
> Of course that's what I was saying. As Mike Brown put it: "the strings are
> syntactically either an empty string or an absolute URI reference". UNless we
No. They. Aren't.
They are *not* URIs. At all.
They are derived from URIs, but if they were URIs they would have *some*
of the behavior of URIS. They have *none*. They are all string. Pure
string. 100% string, unadulterated, untarnished, clean of any remotest
taint of URIness.
Allowing "relative not-a-URI" is just not meaningful. If you can't
parse an absolute namespace name, you can't parse a relative one, and
you can't absolutize it, either, because a string is a string is a
string is a string. It may have been a URI in its wild youth, but once
it grew up and became a string, accepted everywhere, no one should
confuse it with another string that merely happens to be an alternate
lexical representation of the same URI.
> also change the errata that deprecates relative URIs, in which case we really
> have nothing more than a string with a special set of escaping rules disjoint
> from XML's. Which sounds to me like the boiled down residue of a very bad job
> overall.
Sorry, do we have any escaping rules? I don't recall seeing such a
thing in the Namespaces rec (I'm not considering the anyURI type in W3C
XML Schema; does that have escaping rules? Or interesting rules for
comparison? *sigh* Guess I'll go look ...).
Amy!
--
Amelia A. Lewis amyzing@talsever.com alicorn@mindspring.com
The less I seek my source for some definitive, the closer I am to fine.
-- Indigo Girls
|
