W3C home > Mailing lists > Public > xmlschema-dev@w3.org > October 2004

RE: Including Chameleon Schemas

From: Alessandro Triglia <sandro@mclink.it>
Date: Wed, 27 Oct 2004 15:35:00 -0400
To: "'Paul Spencer'" <paul.spencer@boynings.co.uk>, <xmlschema-dev@w3.org>
Message-ID: <001e01c4bc5c$0e86b9a0$9a01a8c0@aldebaran>



> -----Original Message-----
> From: xmlschema-dev-request@w3.org 
> [mailto:xmlschema-dev-request@w3.org] On Behalf Of Paul Spencer
> Sent: Wednesday, October 27, 2004 05:10
> To: xmlschema-dev@w3.org
> Subject: Including Chameleon Schemas
> 
> 
> 
> XML Schema part 1 says that:
> 
> The ·XML Schema· corresponding to <schema> contains not only 
> the components
> corresponding to its definition and declaration [children], 
> but also all the
> components of all the ·XML Schemas· corresponding to any 
> <include>d schema
> documents. Such included schema documents must either (a) 
> have the same
> targetNamespace as the <include>ing schema document, or (b) no
> targetNamespace at all, in which case the <include>d schema 
> document is
> converted to the <include>ing schema document's targetNamespace.
> 
> My question relates to the meaning of "converted" in the last 
> line. Does
> this mean just that the definitions and declarations in the <include>d
> schema document belong in the targetNamespace of the 
> <include>ing schema
> document


The answer is in clause 3.2 under "Schema Representation Constraint:
Inclusion Constraints and Semantics":

-----------------------
3.2 [...] the schema corresponding to the <include>d item's parent <schema>
must include not only definitions or declarations corresponding to the
appropriate members of its own [children], but also components identical to
all the ·schema components· of I, except that anywhere the ·absent· target
namespace name would have appeared, the ·actual value· of the
targetNamespace [attribute] of SII’ is used. In particular, it replaces
·absent· in the following places: 

3.2.1 The {target namespace} of named schema components, both at the top
level and (in the case of nested type definitions and nested attribute and
element declarations whose code was qualified) nested within definitions;

3.2.2 The {namespace constraint} of a wildcard, whether negated or not;
-----------------------


> , or that references to these definitions and 
> declarations in the
> <include>d schema document also change to reference the new 
> namespace? 


The references you mention are a characteristic of the XML representation of
the Schema.  In the language of "schema components" used all over the Rec,
there are no "references" - schema components have properties, and a
property of a schema component can be a schema component.

See, for example:

--------------------
3.8.1 The Model Group Schema Component

The model group schema component has the following properties:

Schema Component: Model Group

{compositor}   One of all, choice or sequence. 
{particles}   A list of particles 
{annotation}   Optional. An annotation.
--------------------

Here, the "particles" property is a list of particles, which are schema
components.  The text does not say that the model group schema component
contains references to particles.

Alessandro Triglia
OSS Nokalva


> In
> other words, the <include>d schema document behaves as though 
> there were a
> targetNamespace declaration *and a defaultNamespace 
> declaration with the
> same URI*. I suspect just the former, in which case the 
> <include>d schema
> document cannot reference it's own definitions and declarations.
> 
> I have noticed that the MS .NET parser seems to interpret this by the
> stricter definition, but that others do not. I have been 
> arguing on and off
> with others about this for years, but have never had a 
> definitive answer and
> cannot find anything in the archives.
> 
> Regards
> 
> Paul Spencer
> 
> 
> 
> 
Received on Wednesday, 27 October 2004 19:38:26 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:15:11 UTC