RE: Including Chameleon Schemas

> -----Original Message-----
> From: Alessandro Triglia [mailto:sandro@mclink.it] 
> Sent: Wednesday, October 27, 2004 15:35
> To: 'Paul Spencer'; 'xmlschema-dev@w3.org'
> Subject: RE: Including Chameleon Schemas
> 
> 
> 
> 
> > -----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.


Me, I prefer to read the Rec in a more direct way.  

You have an <include>d schema document and an <include>ing schema document.
You already know how to build the (abstract) "valid schema" corresponding to
the included schema document.  Your goal is to build the (abstract) schema
corresponding to the including schema document.

*Conceptually*, you should:

- build the (abstract) "valid schema" from the included schema document
(which you know how to do);

- create a copy of each schema component of the "valid schema", changing any
"absent" target namespace property value into the value of the
targetNamespace attribute of the including schema document;

- add all those copies to the (abstract) schema corresponding to the
including schema document, making sure that you are not adding the same
schema component twice.

By the way, the procedure for <redefine> has a lot in common with this one.

Alessandro Triglia
OSS Nokalva


> > 
> > 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 20:08:10 UTC