Uploaded image for project: 'Xerces-C++'
  1. Xerces-C++
  2. XERCESC-1905

Uniqueness constraint issue when deriving via restriction using substitution groups.

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 3.0.1
    • Fix Version/s: None
    • Labels:
      None
    • Environment:
      x86_64-windows-vc-9.0

      Description

      The schema compilation reports the error with the following schema:

      <?xml version="1.0" encoding="UTF-8"?>
      <xs:schema targetNamespace="test" elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="test">

      <xs:element name="SubHead" type="SubHeadType">
      <xs:unique name="SubHeadUnique">
      <xs:selector xpath="*"/>
      <xs:field xpath="@ID"/>
      </xs:unique>
      </xs:element>

      <xs:complexType name="SubHeadType">
      <xs:sequence>
      <xs:element name="Child" type="ChildType" maxOccurs="unbounded"/>
      </xs:sequence>
      </xs:complexType>

      <xs:complexType name="ChildType">
      <xs:simpleContent>
      <xs:extension base="xs:string">
      <xs:attribute name="ID" type="xs:string"/>
      </xs:extension>
      </xs:simpleContent>
      </xs:complexType>

      <xs:element name="Sub" type="SubType" substitutionGroup="SubHead">
      <xs:unique name="RUnique">
      <xs:selector xpath="*"/>
      <xs:field xpath="@ID"/>
      </xs:unique>
      </xs:element>

      <xs:complexType name="SubType">
      <xs:complexContent>
      <xs:extension base="SubHeadType">
      <xs:attribute name="id" type="xs:string"/>
      </xs:extension>
      </xs:complexContent>
      </xs:complexType>

      <xs:element name="BFail" type="BFailType"/>

      <xs:complexType name="BFailType">
      <xs:sequence>
      <xs:element ref="SubHead"/>
      </xs:sequence>
      </xs:complexType>

      <xs:element name="R" type="RFailType"/>

      <xs:complexType name="RFailType">
      <xs:complexContent>
      <xs:restriction base="BFailType">
      <xs:sequence>
      <xs:element ref="Sub"/>
      </xs:sequence>
      </xs:restriction>
      </xs:complexContent>
      </xs:complexType>

      <xs:element name="Sub2" type="SubType"/>

      <xs:element name="BPass" type="BPassType"/>

      <xs:complexType name="BPassType">
      <xs:choice>
      <xs:element ref="Sub2"/>
      <xs:element ref="Sub"/>
      </xs:choice>
      </xs:complexType>

      <xs:element name="RPass" type="RPassType"/>

      <xs:complexType name="RPassType">
      <xs:complexContent>
      <xs:restriction base="BPassType">
      <xs:sequence>
      <xs:element ref="Sub"/>
      </xs:sequence>
      </xs:restriction>
      </xs:complexContent>
      </xs:complexType>

      </xs:schema>

      The error reported is:
      "<file>, line 50, char 35
      Message: element 'Sub' has identity constraint that does not appear in corresponding element 'SubHead' in the base
      Did not parse a schema document cleanly so not printing Schema for Schema XSModel information"

      If the uniqueness constraint on the Sub element is removed the schema is compiled successfully.

      According to the XML Schema specification, the head of a substitution group is to be treated as a choice between all of the members of that substitution group. Therefore the particle derivation validation for the RFailType boils down to whether
      <xs:sequence>
      <xs:element ref="Sub"/>
      </xs:sequence>
      is a valid restriction of
      <xs:choice>
      <xs:element ref="SubHead"/>
      <xs:element ref="Sub"/>
      </xs:choice>

      According to the MapAndSum for a sequence particle derived from a choice particle, 2 conditions must be met:

      "1 There is a complete 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).
      2 The pair consisting of the product of the

      {min occurs}

      of R and the length of its

      {particles} and unbounded if {max occurs} is unbounded otherwise the product of the {max occurs} of R and the length of its {particles}

      is a valid restriction of B's occurrence range as defined by Occurrence Range OK (§3.9.6)."

      These are both met - however the schema compilation is reporting that condition 1 is not met. The XML Schema specification rules for determining the individual element's validity are as follows:

      "For an element declaration particle to be a - valid restriction- of another element declaration particle all of the following must be true:
      1 The declarations'

      {name}

      s and

      {target namespace}

      s are the same.
      2 R's occurrence range is a valid restriction of B's occurrence range as defined by Occurrence Range OK (§3.9.6).
      3 One of the following must be true:
      3.1 Both B's declaration's

      {scope} and R's declaration's {scope}

      are global.
      3.2 All of the following must be true:
      3.2.1 Either B's

      {nillable} is true or R's {nillable}

      is false.
      3.2.2 either B's declaration's

      {value constraint} is absent, or is not fixed, or R's declaration's {value constraint}

      is fixed with the same value.
      3.2.3 R's declaration's

      {identity-constraint definitions} is a subset of B's declaration's {identity-constraint definitions}

      , if any.
      3.2.4 R's declaration's

      {disallowed substitutions} is a superset of B's declaration's {disallowed substitutions}

      .
      3.2.5 R's

      {type definition} is validly derived given {extension, list, union} from B's {type definition}

      as defined by Type Derivation OK (Complex) (§3.4.6) or Type Derivation OK (Simple) (§3.14.6), as appropriate."

      Since the element in the derived sequence particle is the same as the element in the base choice particle, and they are both global - the element declaration is a valid restriction.

      This can be seen to be implemented correctly when dealing with a choice directly (as opposed to one derived from a substitution head) in the example where RPass derives from BPass. These types are compiled without issues. It would seem as though the choice created from the substitution head does not include the uniqueness constraints from the members global element definitions.

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              jgager Jack Gager
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated: