- From: Eddie Robertsson <erobertsson@allette.com.au>
- Date: Wed, 03 Apr 2002 18:12:51 +1000
- To: Simon.Cox@csiro.au
- CC: costello@mitre.org, jeni@jenitennison.com, priyal@microsoft.com, dareo@microsoft.com, xmlschema-dev@w3.org
Hi Simon, > One of my colleagues has challenged my interpretation of the spec. > He claims to have found evidence that *any* valid member of a substitution > group can validly be the content of a type derived by restriction containing > the SG head. > > He appears to have a point. > The issue is probably "when" the substitution group head is replaced by its > equivalent choice group, and when and how many of the members of the > equivalent choice group are considered. > Given that members may be added to the substitution group in external > schemas, then this could have quite an impact on a validating service. > > My head is now spinning on this. > Can any of you guys tease it out? I'm just about to head off home but I just thought I add my view on this. I think one important thing to keep in mind here is that different schema validators can implement the order of the elements in the choice group differently. My guess would be that if an element is added to a substitutionGroup from say an external schema then that element would be added as the last element in the choice group that is created by the processor. However, I don't think this is specified in the spec anywhere which means different processors can implement this differently. This will then impact the following section in the spec: "[Definition:] A complete functional mapping is order-preserving if each particle r in the domain R maps to a particle b in the range B which follows (not necessarily immediately) the particle in the range B mapped to by the predecessor of r, if any, where "predecessor" and "follows" are defined with respect to the order of the lists which constitute R and B." So, if different validators implement the order in the choice group differently then order-preserving may work in some cases whereas in some cases it won't work. At a first glance I can't see any problems with the examples below but I think the above should be kept in mind. Cheers, /Eddie > > > -----Original Message----- > From: Clemens Portele [mailto:portele@interactive-instruments.de] > Sent: Wednesday, 3 April 2002 3:14 PM > To: Simon.Cox@csiro.au > Subject: RE: [RESEND] Derivation by restriction > > Simon wrote: > > > My understanding is that this states that when deriving a type by > > restriction, all the particles in its content model must be > > the same or > > derived by restriction. > > As I read the specs (and John H's remark) this is true only for local > elements but not for global ones; in this case a valid substitution > group is sufficient to create valid instances of the base. This means: > The best practice example on Roger Costello's page is valid, also if > BookType extends PublicationType - which will almost certainly be the > case. Do we agree on this? Probably not, since you write (or am I > missing something again): > > > In GML we use a pattern where in the content model of a > > derived type, we > > restrict a substitution group (i.e. an implicit choice group) > > to a specified > > member. This is fine when the type of the member is a > > restriction of the > > type of the head. But fails if the type of the member in the > > content model > > of the derived type is an extension of the type of the head > > element in the > > content model of the base type. > > > > Note that it is OK for a substitution group member to have a > > type derived by > > extension from the type of the head element. > > But the constraints are on how you can use it within content models. > > Let me repeat my analysis from some days ago. If you are correct, where > is my mistake? > > <xsd:element name="E1" type="X1"/> > <xsd:complexType name="B"> > <xsd:sequence> > <xsd:element ref="E1"/> > </xsd:sequence> > </xsd:complexType> > > <xsd:element name="E2" type="X2" substitutionGroup="E1"/> > <xsd:complexType name="R"> > <xsd:complexContent> > <xsd:restriction base="B"> > <xsd:sequence> > <xsd:element ref="E2"/> > </xsd:sequence> > </xsd:restriction> > </xsd:complexContent> > </xsd:complexType> > > Let's assume that the element definitions of E1 and E2 are valid and X2 > is derived from X1 by extension. > > Then the question is: Is "R" valid? > > XML Schema Part 1, 3.4.6, Rule "Schema Component Constraint: Derivation > Valid (Restriction, Complex)", subitem 5.3 says: > > "If the {content type} of the {base type definition} is mixed or the > {content type} of the complex type definition itself is element-only, > then the particle of the complex type definition itself must be a ·valid > restriction· of the particle of the {content type} of the {base type > definition} as defined in Particle Valid (Restriction) (§3.9.6)." > > I read this as > > <xsd:element ref="E2"/> > > must be a valid "restriction" of > > <xsd:element ref="E1"/>. > > In 3.9.6, Rule "Schema Component Constraint: Particle Valid > (Restriction)" the relevant subitem seems to be 2.1: > > "Any top-level element declaration particle (in R or B) which is the > {substitution group affiliation} of one or more other element > declarations is treated as if it were a choice group whose {min occurs} > and {max occurs} are those of the particle, and whose {particles} > consists of one particle with {min occurs} and {max occurs} of 1 for the > top-level element declaration and for each of the declarations in its > ·substitution group·." > > That is: > > <xsd:element ref="E1"/> > > is treated as > > <xsd:choice> > <xsd:element ref="E1"/> > <xsd:element ref="E2"/> > </xsd:choice> > > and we get: > > <xsd:element name="E1" type="X1"/> > <xsd:complexType name="B"> > <xsd:sequence> > <xsd:choice> > <xsd:element ref="E1"/> > <xsd:element ref="E2"/> > </xsd:choice> > </xsd:sequence> > </xsd:complexType> > > <xsd:element name="E2" type="X2"/> > <xsd:complexType name="R"> > <xsd:complexContent> > <xsd:restriction base="B"> > <xsd:sequence> > <xsd:element ref="E2"/> > </xsd:sequence> > </xsd:restriction> > </xsd:complexContent> > </xsd:complexType> > > Then the rule to be applied seems to be "Schema Component Constraint: > Particle Derivation OK (Elt:All/Choice/Sequence -- RecurseAsIfGroup)": > > "For an element declaration particle to be a ·valid restriction· of a > group particle (all, choice or sequence) a group particle of the variety > corresponding to B's, with {min occurs} and {max occurs} of 1 and with > {particles} consisting of a single particle the same as the element > declaration must be a ·valid restriction· of the group as defined by > Particle Derivation OK (All:All,Sequence:Sequence -- Recurse) (§3.9.6), > Particle Derivation OK (Choice:Choice -- RecurseLax) (§3.9.6) or > Particle Derivation OK (All:All,Sequence:Sequence -- Recurse) (§3.9.6), > depending on whether the group is all, choice or sequence." > > I.e. this transforms our schema to: > > <xsd:element name="E1" type="X1"/> > <xsd:complexType name="B"> > <xsd:sequence> > <xsd:choice> > <xsd:element ref="E1"/> > <xsd:element ref="E2"/> > </xsd:choice> > </xsd:sequence> > </xsd:complexType> > > <xsd:element name="E2" type="X2"/> > <xsd:complexType name="R"> > <xsd:complexContent> > <xsd:restriction base="B"> > <xsd:sequence> > <xsd:choice> > <xsd:element ref="E2"/> > </xsd:choice> > </xsd:sequence> > </xsd:restriction> > </xsd:complexContent> > </xsd:complexType> > > Then the rule to be applied according to the last rule is "Schema > Component Constraint: Particle Derivation OK (Choice:Choice -- > RecurseLax)": > > "For a choice group particle to be a ·valid restriction· of another > choice group particle all of the following must be true: > 1 R's occurrence range is a valid restriction of B's occurrence range as > defined by Occurrence Range OK (§3.9.6); > 2 There is a complete ·order-preserving· functional mapping from the > particles in the {particles} of R to the particles in the {particles} of > B such that each particle in the {particles} of R is a ·valid > restriction· of the particle in the {particles} of B it maps to as > defined by Particle Valid (Restriction) (§3.9.6). > NOTE: Although the ·validation· semantics of a choice group does not > depend on the order of its particles, derived choice groups are required > to match the order of their base in order to simplify checking that the > derivation is OK." > > Here, the definition of "order-preserving" is important: > > "[Definition:] A complete functional mapping is order-preserving if > each particle r in the domain R maps to a particle b in the range B > which follows (not necessarily immediately) the particle in the range B > mapped to by the predecessor of r, if any, where "predecessor" and > "follows" are defined with respect to the order of the lists which > constitute R and B." > > And since <xsd:element ref="E2"/> is a valid restriction of itself and > the order-preservation rule is fulfilled, the type definition of "R" is > valid (which was your point). >
Received on Wednesday, 3 April 2002 03:01:36 UTC