Type Derivation by Restriction

["Winkowski, Daniel" <winkowski@mitre.org>]

This is a question regarding XML Schema type derivation by restriction. I
have a set of code lists that provide valid "domain values" for some set of
fields. These code lists may be reused in various fields in whole or by a
strict subset. It seemed natural to model the code lists as simple
enumerated types and each field as a complex type that may include further
restriction. Example below.

<?xml version="1.0" encoding="UTF-8"?>
<schema targetNamespace="http://www.mitre.org/test"
xmlns="http://www.w3.org/2000/10/XMLSchema"
xmlns:t="http://www.mitre.org/test" elementFormDefault="qualified">
  <element name="Field34" type="t:Codelist58-Type2">
    <annotation>
      <documentation>Test of derivation by restriction</documentation>
    </annotation>
  </element>
  <complexType name="Codelist58-Type2">
    <annotation>
      <documentation>LATITUDINAL HEMISPHERE</documentation>
    </annotation>
    <simpleContent>
      <restriction base="t:Codelist58">
        <enumeration value="N"/>
        <enumeration value="S"/>
      </restriction>
    </simpleContent>
  </complexType>
  <simpleType name="Codelist58">
    <annotation>
      <documentation>HEMISPHERES</documentation>
    </annotation>
    <restriction base="string">
      <enumeration value="N"/>
      <enumeration value="S"/>
      <enumeration value="E"/>
      <enumeration value="W"/>
    </restriction>
  </simpleType>
</schema>

The schema validates in both  XML Spy 3.5 and - XSV 1.175/1.85. A test
document is shown below:

<?xml version="1.0" encoding="UTF-8"?>
<Field34 xmlns="http://www.mitre.org/test"
xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance"
xsi:schemaLocation="http://www.mitre.org/test STestFF.xml">S</Field34>

XSV 1.175/1.85 validates the instance documents without errors when
Field34's content is "S" but reports errors when it is "E" which is just
what I would expect. 

XML Spy also validates the instance document for "S" but also for "E" which
was unexpected. When I put in "Q" it reported that the value does not match
the facet enumeration "N S E W N S" which suggests it is combining all
enumerations! 

So which is right?

Further testing revealed that the restriction was not behaving as I
expected. If I added an additional enumeration "BAD" to the restricted
Codelist58-Type2 based on Codelist58 no validation complaints occur. Is this
proper? I expected restriction to be strict and not allow additions
(extensions) to the content model.

<complexType name="Codelist58-Type2">
    <annotation>
      <documentation>LATITUDINAL HEMISPHERE</documentation>
    </annotation>
    <simpleContent>
      <restriction base="t:Codelist58">
        <enumeration value="N"/>
        <enumeration value="S"/>
        <enumeration value="BAD"/>
      </restriction>
    </simpleContent>
  </complexType>

You might ask what I am trying to achieve with this design beyond furthering
my understanding of XML schemas. The intent is that the code lists would
support the design of configuration manageability and more specifically
consistency checking. In this way illegal values could not be added to types
derived from the code lists.

Ref: to the spec
http://www.w3.org/TR/xmlschema-1/#element-complexContent::restriction 

- Daniel G. Winkowski