[
https://issues.apache.org/jira/browse/XERCESJ-1306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandy Gao resolved XERCESJ-1306.
--------------------------------
Resolution: Invalid
Xerces' behavior is exactly as required by the 1.0 spec, which (I agree) is
counter-intuitive and needs to be fixed in the spec. (Schema 1.1 does fix it.)
Clause 2.1 in "Particle Valid (Restriction)" [1] require that global elements
with sub-group members are converted to choices. So the base type
"hierarchicalContainer":
<xs:sequence>
<xs:element ref="heading" maxOccurs="unbounded"/>
<xs:element ref="hcontainer" maxOccurs="unbounded"/>
</xs:sequence>
Essentially becomes:
( (A | B | C ) +, ( X | Y | Z ) + )
Your derived type "bookType1":
<xs:sequence>
<xs:element ref="number"/>
<xs:element ref="chapter" maxOccurs="unbounded"/>
</xs:sequence>
becomes:
( B, Z + )
Following rules in "Particle Valid (Restriction)", the first half is OK, but
the second half is problematic. "Particle Derivation OK
(Elt:All/Choice/Sequence -- RecurseAsIfGroup)" will turn Z+ into (Z+|) (i.e. a
choice with a single item Z+). This obviously doesn't match the base (X|Y|Z)+,
where unbounded is outside the choice.
Now the second example:
<xs:sequence>
<xs:element ref="number" />
<xs:element ref="hcontainer" maxOccurs="unbounded"/>
</xs:sequence>
is turned into:
( B, ( X | Y | Z ) + )
This is allowed because the second half looks exactly the same as the base, by
having "unbounded" outside the choice.
And the third example:
<xs:sequence>
<xs:element ref="number"/>
<xs:element ref="chapter"/>
</xs:sequence>
becomes:
( B, Z )
Now B restricts (A|B|C)+ and Z restricts (X|Y|Z)+, hence valid.
Again, this is complex and counter-intuitive, but unfortunately that's what the
spec says.
http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/#cos-particle-restrict
> Errors using substitution groups in restrictions
> ------------------------------------------------
>
> Key: XERCESJ-1306
> URL: https://issues.apache.org/jira/browse/XERCESJ-1306
> Project: Xerces2-J
> Issue Type: Bug
> Components: XML Schema 1.0 Structures
> Affects Versions: 2.9.1
> Environment: Xerces-J 2.9.1 within Oxygen 9.0 in MacOSX
> Reporter: Fabio Vitali
> Assignee: Sandy Gao
>
> I am trying to go from abstract to concrete using substitution groups. So far
> I have not managed, and I am wondering why:
> Example:
> <?xml version="1.0" encoding="UTF-8"?>
> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";>
> <xs:element name="heading" type="block" abstract="true" />
> <xs:element name="number" substitutionGroup="heading"/>
> <xs:element name="title" substitutionGroup="heading"/>
>
> <xs:complexType name="block" mixed="true">
> <xs:choice>
> <xs:element name="b" type="block"/>
> <xs:element name="i" type="block"/>
> </xs:choice>
> </xs:complexType>
>
> <xs:element name="hcontainer" type="hierarchicalContainer"
> abstract="true" />
> <xs:element name="section" substitutionGroup="hcontainer"/>
> <xs:element name="chapter" substitutionGroup="hcontainer"/>
>
> <xs:complexType name="hierarchicalContainer" abstract="true">
> <xs:sequence>
> <xs:element ref="heading" maxOccurs="unbounded"/>
> <xs:element ref="hcontainer" maxOccurs="unbounded"/>
> </xs:sequence>
> </xs:complexType>
> <xs:complexType name="bookType1">
> <xs:complexContent>
> <xs:restriction base="hierarchicalContainer">
> <xs:sequence>
> <xs:element ref="number"/>
> <xs:element ref="chapter" maxOccurs="unbounded"/>
> </xs:sequence>
> </xs:restriction>
> </xs:complexContent>
> </xs:complexType>
>
> </xs:schema>
> --
> Error
> rcase-Recurse.2: There is not a complete functional mapping between the
> particles.
> URL: http://www.w3.org/TR/xmlschema-1/#rcase-Recurse
> derivation-ok-restriction.5.4.2: Error for type 'bookType1'. The particle of
> the type is not a valid restriction of the particle of the base.
> URL: http://www.w3.org/TR/xmlschema-1/#derivation-ok-restriction
> Comments
> To my knowledge, BookType1 should work: number is substitutable for heading
> and maxOccurs of the restriction is less than maxOccurs of the base, chapter
> is substitutable for hcontainer, and maxOccurs of the restriction is equal to
> maxOccurs of the base. So to my knowledge this should note pose problems.
> Yet...
> Notes
> Funny that if I only substitute the first name of the two elements, it
> suddenly works. The following example is identical except that "chapter" has
> gone back to the abstract element "hcontainer".
> <xs:complexType name="bookType2">
> <xs:complexContent>
> <xs:restriction base="hierarchicalContainer">
> <xs:sequence>
> <xs:element ref="number" />
> <xs:element ref="hcontainer" maxOccurs="unbounded"/>
> </xs:sequence>
> </xs:restriction>
> </xs:complexContent>
> </xs:complexType>
> Even funnier i that if I remove the repeatability of the hcontainer it also
> works. The following example is as the first one, except that I am forbidding
> repeatability of element "chapter". This is accepted and generates no error.
> <xs:complexType name="bookType3">
> <xs:complexContent>
> <xs:restriction base="hierarchicalContainer">
> <xs:sequence>
> <xs:element ref="number"/>
> <xs:element ref="chapter"/>
> </xs:sequence>
> </xs:restriction>
> </xs:complexContent>
> </xs:complexType>
> Any idea of why it works this way?
> Regards
> Fabio
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
