Re: [xml-dev] This basic property of equality x = x may not holdwith cer

[Michael Kay <mike@saxonica.com>]

There's a considerable tendency among my colleagues in the Schema WG to 
get sucked into metaphysical debates about identity and equality, and 
the complexities are fascinating and endless, but you really have to do 
better than this.

Firstly, the thing you are talking about is not an XML Schema but an XML 
Schema Document. The schema document A has a target namespace T (or the 
absence of one), and of course this does not change. When a schema 
document is the subject of a chameleon include, it is transformed into a 
different schema document in a different namespace. In your example 
there are two chameleon includes, leading to two transformations, c1(A) 
and c2(A). These produce two schema documents with different target 
namespaces, t1 = namespace(c1(A)) and t2 = namespace(c2(A)). Both these 
schema documents c1(A) and c2(A) declare Author elements, but they are 
different Author elements in different namespaces.

No contradictions here at all.

The first essential when trying to understand XSD at any level of depth 
is to appreciate the distinction between schema documents and schemas.

Michael Kay
Saxonica

On 06/10/2011 19:19, Costello, Roger L. wrote:
> Hi Folks,
>
> In school I learned that the square root of a number always equals the square root of the same number, e.g.,
>
>      sqrt(9) = sqrt(9)
>
> More generally, any value x always equals itself:
>
>      x = x
>
> I learned that this basic property of equality is important for mathematical reasoning. And in computer science classes I learned that it is an important property for enabling rewrite rules (replace one expression with an equivalent expression).
>
> Below I demonstrate that the namespace of XML Schema A may not equal the namespace of the same XML Schema. That is,
>
>      namespace(A) = namespace(A)
>
> is not always true.
>
> Example: The following XML Schema declares an Author element. What namespace does Author reside in?
> --------------
> Author.xsd
> --------------
> <?xml version="1.0" encoding="UTF-8"?>
> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";>
>
>      <xs:element name="Author" type="xs:string" />
>
> </xs:schema>
>
> Since there is no targetNamespace, you might answer that the Author element is in "no namespace." And you would be correct, unless ...
>
> Suppose that schema is included by this schema:
>
> -----------
> A.xsd
> -----------
> <?xml version="1.0" encoding="UTF-8"?>
> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";
>                        targetNamespace="http://www.example.org";>
>
>      <xs:include schemaLocation="Author.xsd" />
>
> </xs:schema>
>
> Notice that A.xsd has a targetNamespace. By the Chameleon Effect the Author element is namespace-coerced to A's namespace. Thus, the Author element resides in the http://www.example.org namespace.
>
> Next, suppose Author.xsd is included by this schema:
>
> -----------
> B.xsd
> -----------
> <?xml version="1.0" encoding="UTF-8"?>
> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";
>                      targetNamespace="http://www.trouble.org";>
>
>      <xs:include schemaLocation="Author.xsd" />
>
> </xs:schema>
>
> Now the Author element resides in the http://www.trouble.org namespace.
>
> Thus, a function, namespace, when applied to the same XML Schema (Author.xsd) may produce different results. That is,
>
>      namespace(Author.xsd)  = namespace(Author.xsd)
>
> may not be true.
>
> So, what are the impacts of this? At the very least, reasoning about XML Schemas which can be namespace-coerced (via the Chameleon Effect) may be challenging since a basic property of equality does not always hold. What are the other impacts?
>
> The only kind of XML Schemas that are subject to the Chameleon Effect are no-namespace schemas. Should it be considered Best Practice to avoid no-namespace schemas?
>
> /Roger
>
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
>