[
Lists Home |
Date Index |
Thread Index
]
Thanks to all who replied. I think my brain had turned to mush from looking
at too many schemas, very few of which were valid.
I looked again in the light of your replies, which basically confirmed what
I had thought was the only sensible way for substitution groups to work. The
problem turned out to be that, in the model I am working from, the schema
document that contains the head of the substitution group also directly
references one of the substituted elements. I will go back to the modeller
to see if this is what was intended or whether he intended to reference the
head of the group. Either way, implementation is possible, just messier if
he intended the model as written as it requires two additional schema
documents to avoid circular references.
Regards
Paul Spencer
> -----Original Message-----
> From: Michael Kay [mailto:mike@saxonica.com]
> Sent: 19 February 2005 08:55
> To: 'Paul Spencer'; 'Xml-Dev'
> Subject: RE: [xml-dev] Substitution Groups
>
>
> > File A defines a complex data type AType and an element A of
> > that type.
> >
> > File B defines a complex type BType that is an extension of
> > AType and an
> > element B of that type. Element B is in the substitution
> > group for element
> > A.
> >
> > It as an error if File B does not <include> file A since the
> > XML Processor
> > can't find the head of the substitution group.
> >
> > File A must <include> file B otherwise an instance that uses
> > element B will
> > be invalid.
>
> The schema rec contains some contradictory statements on this.
>
> Section 3.15.3 says:
>
> "For a .QName. to resolve to a schema component of a specified kind all of
> the following must be true:
> 1 That component is a member of the value of the appropriate
> property of the
> schema which corresponds to the schema document within which the .QName.
> appears,": in other words, component references in document A must resolve
> to something in the include tree rooted at A.
>
> However, section 3.1.3 and elsewhere contain statements like "Forward
> reference to named definitions and declarations is allowed, both
> within and
> between .schema documents.." with the implication that when a component A
> references a component B, component B can be anywhere: it doesn't
> have to be
> in a schema document included or imported by the document containing A.
>
> The advice I've had on xmlschema-dev (and which I've implemented in Saxon)
> is that the second statement is correct and the first one is wrong.
>
> Given this confusion in the spec, however, it's not surprising to find
> differences between implementations.
>
> Michael Kay
> http://www.saxonica.com/
>
>
|
