W3C home > Mailing lists > Public > public-xml-core-wg@w3.org > May 2011

Re: Reserved XML names and namespaces

From: Michael Schäfer <michael.schaefer@destatis.de>
Date: Fri, 13 May 2011 09:16:21 -0400
Message-ID: <4DCD1A32.1050104@destatis.de>
To: Jirka Kosek <jirka@kosek.cz>
CC: liam@w3.org, public-xml-core-wg@w3.org, Innovimax W3C <innovimax+w3c@gmail.com>
Mohamed and Jirka,

thanks a lot for your clear opinions. We will  - in some analogy to
XSL Transformations with its two root elements - define an element
'Transport' as an alternative to 'XMLTransport' and dump 'XMLTransport'
after a transitional period, let's say two releases from now (It looks
even better because the XML protocol defines three layers - transport,
package and message - which will then be represented by accordingly
named elements ;) ).

Still, I see some fog to be lifted, figuratively spoken.

> An XML with Namespaces document should at first be XML document (because one is a subset of the other)
> Since it's not allowed in XML, it is a fortiori not allowed for XML with Namespaces document
My idea was that the XML spec and the rule in question predate the
Namespace spec and would possibly have to re-interpreted in the light
of the second.

> my personal opinion (not representing XML Core WG) is that namespaced
Is there an official one?

> precisely reserved for future use). Production rule [4] in XML
> Namespaces spec says that NCName must conform to XML Name minus ":". And
> XML spec says:
> "[Definition: A Name is an Nmtoken with a restricted set of initial
> characters.] Disallowed initial characters for Names include digits,
> diacritics, the full stop and the hyphen.

In XML Namespaces spec, production rule [11] declares LocalPart to be
equivalent to NCName, and production rule [4] declares NCName to be
equivalent to Name in XML spec minus the ':' char.

Production rule [5] in XML spec declares Name to have set of initial and
following chars, but it alone does not ban "xml" as an initial character

> Names beginning with the string "xml", or with any string which would
> match (('X'|'x') ('M'|'m') ('L'|'l')), are reserved for standardization
> in this or future versions of this specification."
Maybe some confusion arises from separating this rule  - which is neither
a production rule nor a definition - from production rule [5].

> Another supportive argument is that if your elements have localname
> starting with "xml" you will not be able to use default namespace
> because resulting syntax will be clearly not conforming to XML spec.
I understand that "private" XML names must not collide with what is defined
in the XML spec. On the other hand, I find that XML namespaces provide a
separation of vocabularies that could not be clearer. And if an element
is in a namespace, the namespace has to be declared in the document, so the
parser should know it's in one, even if it's the default namespace.

> conformance with XML and XML Namespaces specifications. Also please note
> that there are some XML tools which will choke on elements starting with
> "xml". So it is really bad idea to use such named elements in your
> document type.
That's been puzzling me since the problem came up. Our schemata have been
created with oXygen and XML Spy, used for code generation in Web Sphere AS
and with XMLBeans, used for validation with Xerces and other parsers, and
have been WS-I tested. So far, no pains. But of course, that's a wholly
different point...


Received on Friday, 13 May 2011 13:16:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:43 UTC