OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] How to match targetNamespace URIs in XML Schemas tonamespace declarations in XML instances when the targetNamespace attributecontains characters that are illegal in URIs?

On 03/11/2011 04:04, Geoff Shuetrim wrote:
CAB13hhaNbQz+e7qSpE+S3LWxfPkswh_UPoR3HCrCd=gPFBZTQA@mail.gmail.com" type="cite">I have come across an XML Schema document with a targetNamespace attribute that contains, among other characters, a backslash character, for example "http://example.com/target\namespace".

The XML specifications, taken as a whole, are hopelessly muddled about the exact rules on whether namespace names have to be valid URIs, whether leading and trailing whitespace is ignored, and other such details. For example the conformance section of the Namespaces 1.0 specification says nothing on the subject [ http://www.w3.org/TR/REC-xml-names/#Conformance ]

though the phrase

Definition: A document is namespace-well-formed if it conforms to this specification.

is capable of being read many ways, one of which is as a tautological self-reference.

The spec does say "[Definition: An XML namespace is identified by a URI reference [RFC3986]... ]", but it nowhere has any kind of "MUST", and I believe the omission is deliberate because I raised the point while the spec was still in draft and the WG responded saying they had decided to do nothing. So I believe the situation is that the use of an invalid URI in a namespace declaration does not prevent the document being namespace-well-formed.

There are other specs that do require namespace names to be legal URIs, for example the Infoset and the Canonicalization spec. Other specs such as XSD and XSLT/XQuery simply get caught in the crossfire.

The best advice one can give is therefore to apply Postel's law: when you have the choice, always use a valid URI, but when you are accepting input from others, accept any string of characters (and compare them 'as is', perhaps after trimming leading and trailing whitespace).

XSD 1.1 has taken this route by allowing any sequence of characters to appear in an xs:anyURI value, and by clarifying that the mapping from the lexical space to the value space is one-to-one. (XSD 1.0 had the awful statement "Thus in practice the above definition imposes only very modest obligations on ·minimally conforming· processors [to check the value].", without offering any clear guidance on what those obligations are.)

Michael Kay

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS