Fw: Namespaces

james anderson James.Anderson at mecomnet.de
Thu Feb 4 11:15:28 GMT 1999


The confusion issues from the spec itself.

In order to eliminate the origin of the problem, either (A)

1. the definition in section 1 is editied to delete the text:
   "XML namespaces differ from the "namespaces" conventionally used in
computing disciplines
   in that the XML version has internal structure and is not, mathematically
speaking, a
   set. These issues are discussed in 'A. The Internal Structure of XML
Namespaces'. "
2. the first paragraph in 5.2 is modified to say "unprefixed attributes are in
no namespace", or "unprefixed attributes are in the null namespace", or
something of that order instead of (to the effect) merely "unprefixed
attributes are not in the default namespace"
3. the caption to the second exmple in 5.3 is modified to make an analogous
positive assertion rather than merely "the default namespace does not apply to
attribute names".
4. appendix A is eliminated.

or (B)

5. the passages noted in 2 and 3 above are edited to incorporate the "per
element partition" terminology.
6. claims, that "in the sense the spec uses  the word namespace, an unprefixed
attribute is NOT IN ANY NAMESPACE", are abandoned.

It simply doesn't work to have the text referred to in items 1 through 4 above
present in the same specification.

James Clark wrote:
> 
> All this stuff about namespaces is just unnecessary, confusing
> complexity that invites the over-analysis that is so prevalent in this
> forum.  If the spec was called something like "XML Universal Names" and
> never mentioned the word "namespace" and didn't include Appendix A
> (which thankfully is not normative), absolutely no functionality would
> have been lost and I think there would have been far less confusion.

We do agree on this last point. My very first notes about namespaces (I think
it was likely almost a year ago) included a query as to why "per element
partitions" for *names* were even necessary. We agree. They are not.

It appears to the uninitiated, however, that the authors had cause to make
distinctions among the *names* of unqualified attributes themselves. Which
distinction the Appendix A text very clearly makes, and which the spec
supports by reference. There have even been notes posted which led me to
believe that this was intended to support certain XSL expressions. Which leads
the uninitiated to believe there is cause to support this distinction in an
implemented DOM.

Should this not be the case, then the option (A) above should be pursued.


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)




More information about the Xml-dev mailing list