- From: Michael Schäfer <michael.schaefer@destatis.de>
- Date: Fri, 13 May 2011 09:16:21 -0400
- 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 sequence. > > 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... Regards, Michael
Received on Friday, 13 May 2011 13:16:17 UTC