- From: <keshlam@us.ibm.com>
- Date: Thu, 8 Jun 2000 17:46:36 -0400
- To: David Carlisle <david@dcarlisle.demon.co.uk>
- cc: xml-uri@w3.org
>But that assumes already the most contentious issue >the rec does not define the namespace name to be in URI space it >defines it to be a URI reference. Granted. Except that what the rec really intended was not even that; it was supposed to define the namespace name as something that looked like a URI plus an optional #locator suffix. Overstating the case is what got us into this. Having said that, I think I can see where Tim B-L & Co. are coming from.Since the spec does say it's a reference -- however unintentional that may have been -- I can't blame them for trying to "drop the other shoe" and say "and what it refers to is really the Namespace". I strongly dislike some of the impliations of that, specifically in the fact that it makes relative-syntax namespace declarations a poor choice. For that reason, I would prefer to Forbid relative syntax, at which point the distinctions between the other options become moot. And it sounds like a weak from of Forbid -- namely the Deprecate/Undefined proposal -- may in fact be acceptable to a wide enough population. I'm less certain than I once was about my second choice. I understand the architectural argument laid out above, but I still strongly dislike the idea of burning cycles to support something that almost everyone now agrees was a bad idea in the first place. >in this analogy the namespace name isn't the address it's the offset >to it. I think I've decided that using an offset as a name is Just Plain Dumb. The question is whether it's worth doing the work to support "what the user probably meant to say", or declaring that they shouldn't have said it in the first place. > If namespace names are URI references, and ./foo is a URI >reference then ./foo is a namespace name. This is not inconsistent ALL THREE OPTIONS ARE CONSISTENT. That's the problem. If we can manage to eliminate any one of them we can probably reach a compromise on the remaining two... but with all three active, any compromise will be unacceptable to someone.
Received on Thursday, 8 June 2000 17:46:51 UTC