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

``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]

``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]

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.