10.4. Concepts and Observations
Creating a simple type is easy. Nonetheless, there are a few things to consider when creating a new simple type. This section covers adding constraining facets to simple types, noting the lack of non-instantiable simple types, specifying the scope of simple types, and blocking of simple types.
Each simple type has a value space and a lexical space. Furthermore, every value in the value space has a canonical lexical representation. This section covers these concepts.
10.4.1. Constraining Facets
The Schema Recommendation limits the use of constraining facets to simple types. Constraining facets enforce additional restrictions to a simple type derived directly or indirectly from a built-in datatype.
Listing 10.1 contains a simple example of a constraining facet associated with the partNameType. The partNameType is a restriction of the built-in token type. The minLength and maxLength constraining facets restrict partNameType to a short description of 40 characters.
The constraining facets also apply to simple types that are lists or unions of other simple types. Sections 10.5.3, 10.6.3, 10.7.3, and 10.8.3 cover the constraining facets of simpleType, restriction, list, and union, respectively.
Tip
The restriction element provides functionality for adding constraining facets to a simple type.
A restriction element contains constraining facets. The previously itemized sections discuss the constraining facets associated with different types. Sometimes the constraining facets occur in places that are not always obvious. Lists and unions, for example, require further derivations to add constraining facets.
10.4.2. The Value Space
The value space defines the range of permissible values. The following simple type specifies an integer between −5 and 5, inclusive, by restricting the value space:
<xsd:simpleType name="valueAbsoluteLessEqualFiveType">
<xsd:annotation>
<xsd:documentation xml:lang="en">
This simple type specifies a range
of integer values between -5 and 5,
inclusive.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:integer">
<xsd:minInclusive value="-5"/>
<xsd:maxInclusive value="5"/>
</xsd:restriction>
</xsd:simpleType> The value space for this simple type contains the integers between −5 and 5. The lexical space automatically loses all numerals that don’t name integers outside this range.
10.4.3. The Lexical Space
The lexical space defines the range of character-string representations of the values. Compare the previous example with the next example, which directly constrains the lexical space with a pattern:
<xsd:simpleType name="lexicalAbsoluteLessEqualFiveType">
<xsd:annotation>
<xsd:documentation xml:lang="en">
This simple type specifies a range
of integer values between -5 and 5,
inclusive.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:integer">
<xsd:pattern value="0|(-?[1-5])"/>
</xsd:restriction>
</xsd:simpleType> This example differs from the previous one in that it disallows “redundant leading zero” representations such as ‘001’.
In general, constraining facets should specify restrictions on the value space when appropriate. For example, specifying a pattern conceptually similar to the previous example, but for a decimal range between -5.0 and 5.0, is suspect at best.
10.4.4. The Canonical Lexical Representation
Each value in the value space has a canonical lexical representation. The canonical lexical representation of a value is the “official” lexical representation of a value. For example, the canonical lexical representation of the float value having representations ‘5’, ‘5.0’, ‘0005.000’, and ‘5.0E0’is ‘5.0E0’. Off hand, it appears that that canonical lexical representation is of no interest to the schema writer. On the contrary, the Schema Recommendation requires that all default values adhere to the following constraint:
If an element type or attribute type specifies a default or fixed value, that value must be valid with respect to the structure type.
This can lead to the presumably unintended situation where the canonical representation of the default value invalidates the simple type. The following scenario demonstrates this unfortunate situation. Listing 10.4 is a simple type that specifies a float value that might store dollar values.
Listing 10.4. A Simple Type to Store Dollar Values (pricing.xsd)
<xsd:simpleType name="dollarType">
<xsd:annotation>
<xsd:documentation xml:lang="en">
This simple type specifies decimal
values that conform to scientific
notation.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:float">
<xsd:pattern value="[0-9]+.[0-9][0-9]"/>
</xsd:restriction>
</xsd:simpleType> |
Note that the canonical form of a float requires exactly one digit before the decimal point.
The following element type is invalid, because the canonical lexical representation of the default value (even if represented as ‘1.0E2’ in the element type) cannot conform to the pattern specified by dollarType:
<xsd:element name="dollar"
type="dollarType"
default="100.00"/> 10.4.5. Non-instantiable Simple Types
Simple types are always instantiable. The XML representation of a simple type cannot specify a non-instantiable simple type. Furthermore, because a simple type does not contain element types or attribute types, there are no implicitly non-instantiable simple types. The inability to specify a simple type as non-instantiable means the XML representation of a schema cannot describe a simple type that an element cannot reference. For example, an element type is not supposed to associate the partNumberType in Listing 10.2 as a structure type. Instead, an element type is supposed to associate a derived type such as the assemblyPartNumberType. Unfortunately, there is no way to prevent an element type from directly using partNumberType. Conceptually, partNumberType is non-instantiable; in practice, partNumberType is always instantiable. To reiterate, the XML schema does not prohibit the ensuing element type:
<xsd:element name="partNumber" type="partNumberType"/>
Note that both complex types and element types may be non-instantiable.
Warning
The inability to declare a simple type non-instantiable could lead to unintended use of what conceptually a non-instantiable base simple type. This unintended use would occur in the XML instance, such as the one portrayed in Section 10.4.2.
10.4.6. Global, Local, and Anonymous Simple Types
A simple type can be global or local. A local simple type can be anonymous; in other words, a local simple type does not require a name. Complex types, element types, attribute types, and other simple types can reference a global simple type. Sections 10.7 and 10.8 (which cover lists and unions, respectively) provide examples of both local and global simple types.
10.4.7. Blocking
The simpleType element can have only the final attribute, not the block attribute. In general, the final attribute blocks the schema from further derivations of a simple type; the block attribute blocks a corresponding XML instance from specifying further derivations of a simple type. Presumably, because all simple types are instantiable, the World Wide Web Consortium (W3C) Schema Working Group found little value in supporting the block attribute.