[
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.
I think, on reading your whole message, that I understand the distinction
you're trying to make.
You have a point. Calling namespaces even syntactically a URI will perpetuate
confusion. I guess all that remains if this objection os granted is:
"A namespace is any string. It is considered good practice to use for a
namespace a string form that includes some form of authority identifier under
the control of the vocabulary owner, such as a URI scheme that includes an
authority, or a formal public identifier."
Basically reductio ad minimum or reductio ad pessimum, based on your POV. I
can't imagine anyone considering it reductio ad optimum.
> > 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.
Yes. When Tim Berners-Lee was discussing "Webizing Python", he suggested
using URIs for Python package names. Even though I knew this idea had about
as much chance in Python as an RIAA executive has of getting into heaven, I
did and do think it's a cleaner solution than Java's pseudo URIs. Yes Java
gains the element of control, but it loses the element of generic package
management facilities.
Same thing for XMLNS. I think it's a bad idea to invent its own scheme a la
Java because then it has to invent its own peculiar infrastructure for that
scheme.
> 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.
But under John's proposed wording, there would be no need for namespace
parsing software at all. It would be simply a string to be compared.
> > > 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*
The thing is that contrary to Simon, I don't think that namespaces now cause
interop problems. They really just cause conceptual problems (all the
supposed interop problems Simon posed are really concept problems, but the
acid test: that software written strictly according to the namespace spec
should be compatible, is passed by XMLNS 1.0)
The change you're suggesting would introduce interop problems while providing
very little mitigation of the conceptual problems, which IMO seem mostly a
matter of misunderstanding of URIs.
> > 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 ...).
Yes we do. For example:
http://bête.com
Is an invalid URI, and thus an invalid namespace name. It must be escaped to
http://b%eate.com
One thing I don't know is how this URI restriction interacts with the recent
opening up of DNS to i18n.
--
Uche Ogbuji Fourthought, Inc.
http://uche.ogbuji.net http://4Suite.org http://fourthought.com
Track chair, XML/Web Services One Boston: http://www.xmlconference.com/
Basic XML and RDF techniques for knowledge management, Part 7 -
http://www-106.ibm.com/developerworks/xml/library/x-think12.html
Keeping pace with James Clark - http://www-106.ibm.com/developerworks/xml/libra
ry/x-jclark.html
Python and XML development using 4Suite, Part 3: 4RDF -
http://www-105.ibm.com/developerworks/education.nsf/xml-onlinecourse-bytitle/8A
1EA5A2CF4621C386256BBB006F4CEC
|
