Re: Re: URIs, concrete (was Re: Un-ask the question)
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@t... alicorn@m... The less I seek my source for some definitive, the closer I am to fine. -- Indigo Girls
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format