[Resending, with some typos removed. Sorry.]

On May 24, 2017, at 4:01 PM, Syd Bauman wrote:

Michael (and Council) --

"I know what he said, but what does it mean?" [1] -- Napoleon Solo

It turns out, to my surprise, that an xsd:NCName is valid as an xsd:QName. See test file [2] and, if you need to, its schema [3]. I've tested this with both `jing` and `xmllint`.

It will be helpful, in answering your questions, to distinguish both between “namespace-qualified” (or “qualified” for short) names on the one hand and “unqualified” names on the other, and also between “prefixed” and “unprefixed” names. All QNames have a local name and optionally a namespace name (and are often taken as consisting precisely of that pair). A namespace-qualified name has a non-null namespace name; an unqualfied name has no namespace name (which we may choose to think of for some purposes as equivalent to “it has the null value in its namespace-name field”). A prefixed name has the form NCName + “:” + NCName; an unprefixed name is just an NCName. The utility of distinguishing having-a-namespace and having-a-prefix was, I think, not fully appreciated at the time the Namespaces spec was being prepared, so it does not do a good job of defining convenient terminology for discussing questions like those below. QNames are conveniently written in {ns-name}local-name notation, where {}foo denotes the QName whose local name is “foo” and which has no namespace name. (The empty string is not a namespace name.)

I can see that this is the case: production #6 of _Namespaces in XML_[4] clearly says that the prefix is optional. But I don't understand

a) what it means, i.e., what is the namespace part of a QName that does not have a prefix;

When an unprefixed name is to be interpreted as a QName, we need a way to identify the default namespace. The Namespaces spec tells us how to do this for XML element and attribute names, but not for other names. Names used in other contexts will follow whatever spec defines their interpretation: in XSD schemas, the use of QNames as attribute values is governed by the rules that say to use the same method of identifying the default namespace as is defined by the Namespaces spec; in function calls in XPath 2.0 expressions, the use of QNames to identify functions is governed by rules in the host language (XQuery, XSLT, XForms, …) that say how namespace prefixes are bound and which specifiy a particular namespace as the default function namespace, in which all unprefixed names are assumed to fall. So: “what it means" in detail depends on what spec governs the QName in question. But all the specs that come to mind right away follow the simple rule: unprefixed names are interpreted as names in the default namespace. The default namespace is either defined somewhere (as in the XDM default function namespace) or is undefined (in which case the QName has what a null namespace name / lacks a namespace name). [Digression] Note that for purposes of QName comparison most XML-related specs treat "the null / unspecified / absent namespace" as if it were itself a namespace distinct from all other namespaces, and an unqualified name “foo” as if it were known NOT to be in any particular namespace. That is not required by the Namespaces spec, which does not in fact license the inference that {}foo is distinct from {X}foo for any namespace named X, and rather inclines to the view that they COULD in fact be the same. [End digression.]

b) what the prose of [4] section 3 immediately before production #6 means ("some names may be given as qualified names"), since as far as I can tell the only XML names that aren't already qualified names are those that start with a colon, and who would do that?

Not every occurrence of Name in the XML spec’s grammar is to be replaced by a reference to QName: entities, notations, IDs, IDREFs, and possibly other XML names are not to be interpreted as QNames under the Namespaces spec.

Besides, "authors should not use the colon in XML names except for namespace purposes";[5] or

c) what's the point, i.e., why did W3C do it that way?

What way, particularly, did you have in mind? Bear in mind that very few people (including the authors and editors of the Namespaces spec) think very highly of the design, or of the exposition in the spec. Namespaces do one thing: they allow software which has been built to be “responsible for” names in a particular namespace to know whether a given name in an XML document is or is not a name for which they are responsible. There are many closely related things that XML Namespaces do not do, some of which the spec (especially in version 1.0) wrongly claims or suggests that they do. In particular: - XML Namespaces do not provide globally unique identifiers for objects: the internal structure of a namespace is unconstrained and there is no guarantee that a QName {N}L identifies only one thing within namespace N. - XML Namespaces do not associate semantics with names.

No rush on answering this, it doesn't change anything; it's just an "inquiring minds want to know" thing.

Be careful what you ask for.

Notes ----- [1] From _The Man from U.N.C.L.E._; see https://www.youtube.com/watch?v=w_Ky4KPzKwY#t=103.781343 from ~01:13 to ~01:43. [2] https://bauman.zapto.org/~syd/temp/4TEICouncil/QName_test.xml [3] https://bauman.zapto.org/~syd/temp/4TEICouncil/QName_test.rng [4] http://www.w3.org/TR/1999/REC-xml-names-19990114 [5] From a note in section 2.3 of the XML 1.0 spec, 2nd edition; http://www.w3.org/TR/2000/REC-xml-20001006

******************************************** C. M. Sperberg-McQueen Black Mesa Technologies LLC cmsmcq@blackmesatech.com http://www.blackmesatech.com ********************************************