Re: [tei-council] when is a QName not a QName?

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 make 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. 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 defines the first distinction but not the second. 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 “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 what namespace is the default namespace. 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 it has what a SQL programmer would call NULL as a value). [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?

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

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 ********************************************