RELAX NG includes a native type system, but this type library has been kept minimal by design because more complete type libraries are available. It consists of just two datatypes (token and string) that differ only in the whitespace processing applied before validation. The whole RELAX NG datatype system can be seen as a mechanism for adding validating transformations to text nodes. These transformations change text nodes into canonical formats (formats in which all the different formats for a same value are converted into a single normalized or “canonical” format). The two native datatypes don’t detect format errors (their formats are broad enough to allow any value) but still transform text nodes in their canonical forms, which can make a difference for enumerations. Other datatype libraries, covered in Chapter 8, can detect format errors.

Enumerations are the first place you can see datatypes at work. Applying datatypes to enumeration values is done by adding a type attribute in value patterns. Up to now, we haven’t specified any datatype when we’ve written value elements. By default, they have the default type token from the built-in library. Text values of this datatype receive full whitespace normalization similar to that performed by the XPath normalize-space( ) function: all sequences of one or more whitespace characters—the characters #x20 (space), #x9 (tab), #xA (linefeed), and #xD (carriage return)—are replaced by a single space, and the leading space and trailing space are then trimmed.

Reconsidering previous examples, writing:

<attribute name="available">
 <choice>
  <value>available</value>
  <value>checked out</value>
  <value>on hold</value>
 </choice>
</attribute>

or:

attribute 
 available {"available"|"checked out"|"on hold"}

has used the default type value (token) and is equivalent to the following:

<attribute name="available">
 <choice>
  <value type="token">available</value>
  <value type="token">checked out</value>
  <value type="token">on hold</value>
 </choice>
</attribute>

or:

attribute available {token "available"|token "checked out"|token
"on hold"}

When the token datatype is used, whitespace normalization is applied to the value defined in the schema and to the value found in the instance document. The comparison is done using the result of the normalization, which explains why "on hold" was matching " on hold " with spaces or tabs added before, between, and after the words.

To suppress this normalization, you can specify the second built-in datatype, string, which doesn’t perform any transformation on the values before comparing them to the specified value:

 <attribute name="available">
  <choice>
   <value type="string">available</value>
   <value type="string">checked out</value>
   <value type="string">on hold</value>
  </choice>
 </attribute>

or:

attribute available {string "available"|string "checked out"|string
"on hold"}

Using the new definition, the value of our attribute must exactly match the value specified in the schema: available, checked out, and on hold. No extra whitespace is permitted.