2. Limitations related to XML Schema Structures
Prev | A. Implementation limits | Next

### 2. Limitations related to XML Schema Structures

Formal reference: XML Schema Part 1: Structures.

Constraints on XML instances which are not checked:

- Entity Name: an attribute value of type ENTITY or ENTITIES must match the name of an unparsed entity declared in the DTD.

Constraints on XML schemas which are not checked:

- ``The {model group} of the model group definition which corresponds to it per XML Representation of Model Group Definition Schema Components (§3.7.2) must be a ·valid restriction· of the {model group} of that model group definition in I, as defined in Particle Valid (Restriction) (§3.9.6).'' [src-redefine.6.2.2]

  In this case, the implementation simply overwrites the previously defined group.

- ``The {attribute uses} and {attribute wildcard} of the attribute group definition which corresponds to it per XML Representation of Attribute Group Definition Schema Components (§3.6.2) must be ·valid restrictions· of the {attribute uses} and {attribute wildcard} of that attribute group definition in I.'' [src-redefine.7.2.2]

  In this case, the implementation simply overwrites the previously defined attributeGroup.

- Attribute Group Definition Representation OK. [src-attribute_group.2] [src-attribute_group.3] Attribute Group Definition Properties Correct. [ag-props-correct.2] [ag-props-correct.3]

  attributeGroups are not validated as such. If something is wrong, it is detected when the the attributeGroup is actually used.

  Example 1: circular references are checked when the attributeGroup is actually used.

  Example 2: duplicate attribute and several ID attributes in the same attributeGroup are checked when the attributeGroup is actually used.

- Model Group Definition Representation OK. [mgd-props-correct]

  groups are not validated as such. If something is wrong, it is detected when the the group is actually used.

- Unique Particle Attribution. [cos-nonambig]

- Derivation Valid (Restriction, Simple). [cos-st-restricts.1.3] [cos-st-restricts.2.3.3] [cos-st-restricts.3.3.3]

  The implementation allows to add facets not defined by the base type.

- ``It must in principle be possible to derive the complex type definition in two steps, the first an extension and the second a restriction (possibly vacuous), from that type definition among its ancestors whose {base type definition} is the ·ur-type definition·.'' [cos-ct-extends.1.5]

- ``The {content type} of the {base type definition} must be a simple type definition of which the {content type} is a ·valid restriction· as defined in Derivation Valid (Restriction, Simple) (§3.14.6).'' [derivation-ok-restriction.5.1.1]

  - See above the limitations related to Derivation Valid (Restriction, Simple) [cos-st-restricts]

  - In this case, the implementation does not check that the new facet value actually restricts the facet value of the base type.

- ``No element member of the ·key-sequence· of any member of the ·qualified node set· was assessed as ·valid· by reference to an element declaration whose {nillable} is true.'' [cvc-identity-constraint.4.2.3]

Other specificities:

- The algorithm used to check Particle Valid (Restriction) [cos-particle-restrict] is more powerful than the one described in the spec.

  Rationale: the schema for schemas is found invalid when the algorithm described in the spec is used.

- `<xs:complexType name="title" mixed="true" />` is mixed, not empty.

- Not being able to load a schema include-ed, import-ed or redefine-ed by another schema is considered to be a fatal error [x-src-include.1] [x-src-import.1] [x-src-redefine.1]. For the spec, it is just a warning.

- A import construct must almost always specify a schemaLocation [x-src-import].

  However, the validation engine supports `xs:import` elements without a `schemaLocation` attribute, if an `xs:import` element for the same namespace but this time having a `schemaLocation` attribute has previously been processed.

  Example:

        <xs:import namespace="foo"
                   schemaLocation="http://foo.com/schema1.xsd" />

        <!-- Later, typically inside an included module. -->
        <xs:import namespace="foo" />

  Note that the other example below will not work because the validation engine cannot guess which of `schema1.xsd` or `schema2.xsd` contains the components to be imported.

        <xs:import namespace="foo"
                   schemaLocation="http://foo.com/schema1.xsd" />

        <!-- Later, typically inside an included module. -->
        <xs:import namespace="foo"
                   schemaLocation="http://foo.com/schema2.xsd" />

        <!-- Later, typically inside another included module. -->
        <xs:import namespace="foo" />

- Identity-constraint definition identities must be unique within an XML Schema [x-c-props-correct].

- A regular expression such as "`[a-zA-Z0-9-]`" is not supported as is. It must be rewritten like this: "`[a-zA-Z0-9\-]`".

- For readability, whitespace may be used in `selector` and `field` XPath expressions. But whitespace is only supported around '`|`' and not around all tokens as mandated by the W3C recommendation.

  That is, it is possible to specify this:

      <xs:key name="truck1" >
        <xs:selector xpath="." />
        <xs:field xpath="truck/@number | truck/@plate" />
      </xs:key>

  But not this:

      <xs:key name="truck1" >
        <xs:selector xpath="." />
        <xs:field xpath="truck / @number | truck / @plate" />
      </xs:key>

- The following valid element declaration is not supported.

      <xs:element name="foo">
        <xs:complexType>
          <xs:sequence>
            <xs:element ref="bar" />
            <xs:element name="bar" form="qualified" type="xs:decimal" /> <!--NOT SUPPORTED-->
          </xs:sequence>
        </xs:complexType>
      </xs:element>

      <xs:element name="bar" type="xs:decimal"  />

  An implementation limit error `x-cos-element-consistent` is reported in that case.

- The following valid element declaration is not supported.

      <xs:element name="foo">
        <xs:complexType>
          <xs:sequence>
            <xs:element name="bar" type="xs:token" />
            <xs:element name="bar" type="xs:token" nillable="true" />
          </xs:sequence>
        </xs:complexType>
      </xs:element>

  An implementation limit error `x-cos-element-consistent` is reported in that case.

Prev | Up | Next
1. Limitations related to XML Schema Datatypes | Home | 3. Limitations related to DTD support