RE: Including Chameleon Schemas

Thanks Alessandro. I had missed that bit. That makes sense (the alternative
makes chameleon schemas pretty well pointless).

The reason I brought this up was that certain UK Inland Revenue schemas
(which <include> a schema document with no target namespace) validate OK
with Xerces, XSV, MSV and MSXML, but not with the .NET validator, which says
that all the global definitions in the <include>d schema document are
undefined. It seems unlikely to me that MS would have got something this
simple wrong. In my experience, when one validator objects to a schema and
others don't the one objecting is usually right. In other words, false
positives and common, false negatives are rare.

I would welcome anyone having a look. I have put an <include>ing and an
<include>d schema document at http://boynings.co.uk/ir/core-v2-0.xsd and
http://boynings.co.uk/eoy-2006-schema-2.0.xsd.

Regards

Paul

> -----Original Message-----
> From: xmlschema-dev-request@w3.org
> [mailto:xmlschema-dev-request@w3.org]On Behalf Of Alessandro Triglia
> Sent: 27 October 2004 21:05
> To: 'Paul Spencer'; xmlschema-dev@w3.org
> Subject: 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 Thursday, 28 October 2004 08:45:16 UTC