7. Implementation limits

7.1. Limitations related to XML Schema Datatypes

Formal reference: XML Schema Part 2: Datatypes.

  • A 32-bit signed integer is used rather than an arbitrary precision integer to implement the length, minLength, maxLength, totalDigits and fractionDigits facets.

  • Similarly, the components of the duration datatype are implemented using 32-bit integers and double-precision floating-point numbers.

  • The length facet of datatype QName is implemented as the number of characters in the local part of the name (that is, the prefix part is not taken into account by facet length).

7.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" />
  • The implementation issues a warning for the following case: the element declaration corresponding to an element particle is abstract and there are no non-abstract substitutions for this declaration [x-p-props-correct].

  • 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.

7.3. Limitations related to DTD support

Formal reference: Extensible Markup Language (XML) 1.0 (Second Edition).

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 DTDs which are not checked:

  • Notation Declared: in an unparsed entity, the name after NDATA must match the declared name of a notation.

  • Standalone Document Declaration.

  • Proper Declaration/PE Nesting.

  • Proper Group/PE Nesting.

  • Proper Conditional Section/PE Nesting.