home | O'Reilly's CD bookshelfs | FreeBSD | Linux | Cisco | Cisco Exam    

Book HomeXML SchemaSearch this book

5.4. Some Oddities of Simple Types

While simple types are structurally simple, they still have some complications worth watching for.

5.4.1. Beware of the Order

The order of the different derivation methods (restriction, list, or union) is significant.

We have already seen that derivation by list and union lose the semantic meaning of the types and their facets, which are replaced by a common set of facets with their own meaning (xs:length, xs:maxLength, xs:minLength, xs:enumeration, and xs:whiteSpace for derivation by list, and xs:pattern and xs:enumeration for derivation by union).

This means that all the restrictions on the atomic or member types must be done before the derivation by list or members (as we have seen in the corresponding sections for the facets) and that a new restriction can then be performed using the common set of facets.

The order between derivation by list and derivation by union depends on the result to achieve, as a list of unions is different from a union of lists, as one might expect:

<xs:simpleType name="listOfUnions">
  <xs:list>
    <xs:simpleType>
      <xs:union memberTypes="xs:date xs:integer"/>
    </xs:simpleType>
  </xs:list>
</xs:simpleType>

<xs:simpleType name="UnionOfLists">
  <xs:union>
    <xs:simpleType>
      <xs:list itemType="xs:date"/>
    </xs:simpleType>
    <xs:simpleType>
      <xs:list itemType="xs:integer"/>
    </xs:simpleType>
  </xs:union>
</xs:simpleType>

These two datatypes match the following:

<UnionOfLists>
  2001-01-01 2001-01-02
</UnionOfLists>

<UnionOfLists>
  1 2 3
</UnionOfLists>

<ListOfUnions>
  2001-01-01 2001-01-02
</ListOfUnions>

<ListOfUnions>
  1 2 3
</ListOfUnions>

<ListOfUnions>
  2001-01-01 1 2
</ListOfUnions>

But don't match:

<UnionOfLists>
  2001-01-01 1 2
</UnionOfLists>

This requires all the items of the list to have the same member type.

The order in which a set of derivation by restriction is completed is also significant when the same facets are being redefined, since we have seen that there are some restrictions that depend on the facets being used.

5.4.2. Using or Abusing Lists to Change the Behavior of Length Constraining Facets

We have seen that a derivation by list impacts not only the value space of the item types, but also their meaning. We have also seen that their set of facets is replaced by a generic set.

In the case of length-constraining facets, the length unit is generally a number of characters (in the general case) or bytes (binary types) before a derivation by list and becomes a number of whitespace-separated values for any list datatype.

A restriction by list then allows constraint of the number of whitespace-separated "words" on any datatype. For instance, if we want to define a string datatype of 100 and 200 words, each having a length of less than 15 characters and using only basic Latin characters, we can write:

<xs:simpleType name="word">
  <xs:list>
    <xs:simpleType>
      <xs:restriction base="xs:string">
        <xs:maxLength value="15"/>
        <xs:pattern value="\p{IsBasicLatin}*"/>
      </xs:restriction>
    </xs:simpleType>
  </xs:list>
</xs:simpleType>
      
<xs:simpleType name="story">
  <xs:restriction base="word">
    <xs:minLength value="100"/>
    <xs:maxLength value="200"/>
  </xs:restriction>
</xs:simpleType>

The first definition defines the constraint on the words and the second adds the constraint on the string itself, which is seen here as a list of words. However, one should note that in this example we have no way to define a constraint on the total number of characters of the "story." The next chapter will demonstrate that these two constraints can be defined using a set of patterns on the string itself.



Library Navigation Links

Copyright © 2002 O'Reilly & Associates. All rights reserved.











??????????????@Mail.ru