Specifying data types and validation criteria

Page authors can specify data types and validation criteria for form input elements in order to improve the user experience of entering data into a form and the quality of the submitted data. Devices, which support this functionality, may provide users with alternate mechanisms for entering the data corresponding to the chosen data type, for example, a button that opens a calendar, or a slider for the xforms:range element. In addition, devices may provide a different virtual keyboard or set the mode of a numeric keypad based on the type of the input to make it easier for the user to enter the data. Forms processors may also validate input values and, for example, display an error message if the entered data do not match the specified validation criteria.

Page authors can specify data types and validation criteria for form input elements in order to improve the user experience of entering data into a form and the quality of the submitted data. Devices, which support this functionality, may provide users with alternate mechanisms for entering the data corresponding to the chosen data type, for example, a button that opens a calendar, or a slider for the xforms:range element. In addition, devices may provide a different virtual keyboard or set the mode of a numeric keypad based on the type of the input to make it easier for the user to enter the data. Forms processors may also validate input values and, for example, display an error message if the entered data do not match the specified validation criteria.

Note:

Data types and validation criteria can only be associated with xforms:input elements.

Specifying data types

Data types can be specified using the xforms:bind element, or the type attribute of the si:item element. If both methods are used in the same time and the xforms:bind element defines a different data type than the si:item element, the type defined by xforms:bind will be used.

The following table lists the supported primitive data types. The data types that originate in XForms should be bound to http://www.w3.org/2002/xforms.

Data type Description
mcs:tel  A phone number. This type has no pattern. Note that 'mcs:tel' is a custom type built into MCS, i.e. there is no equivalent in the XForms model. It must be bound to http://www.volantis.com/xmlns/2006/01/xdime/mcs.
xforms:anyURI  An absolute URI.
xforms:date  A date value (year, month, day) with no time zone.
xforms:dateTime  A date and time value (year, month, day, hour, minute, second, fraction of a second) with the time zone set to UTC.
xforms:decimal  A decimal value.
xforms:double  A double value.
xforms:email  An e-mail address or a list of e-mail addresses.
xforms:float  A float value.
xforms:string  A string value.
xforms:time  A time value (hours, minutes, seconds, fractional seconds) with no time zone.

Specifying validation criteria

Page authors can use several elements from the XML Schema specification to define validation criteria. The xsd:restriction element allows page authors to imposes restrictions on input form controls. This element can contain the xsd:simpleType element and/or the xsd:maxInclusive, xsd:minInclusive, xsd:maxLength and mcs:pattern elements. The xsd:simpleType element defines a simple type and specifies the constraints and information about the values. The xsd:minInclusive and xsd:maxInclusive elements specify inclusive bounds for numeric values, respectively. The xsd:maxLength element specifies maximum number of characters allowed in the input form field. The mcs:pattern element can contain a regular expression that defines the validation pattern.

The following table lists the available restrictions and their supported data types.

Restriction Supported data types
xsd:maxLength xforms:anyURI, xforms:email, xforms:string, mcs:tel
xsd:minInclusive xforms:date, xforms:dateTime, xforms:decimal, xforms:double, xforms:float, xforms:time
xsd:maxInclusive xforms:date, xforms:dateTime, xforms:decimal, xforms:double, xforms:float, xforms:time
mcs:pattern xforms:anyURI, xforms:email, xforms:string, mcs:tel

The xforms:bind element can be used to bind a type to a form control.

<?xml version="1.0" encoding="UTF-8"?>
<html xmlns="http://www.w3.org/2002/06/xhtml2"
  xmlns:si="http://www.volantis.com/xmlns/2006/01/xdime2/si"
  xmlns:xforms="http://www.w3.org/2002/xforms"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <head>
    <title>xsd:maxLength</title>
    <xforms:model id="model1">
      <xsd:schema>
        <xsd:simpleType name="myType" >
          <xsd:restriction base="xforms:string">
            <xsd:maxLength value="16"/>
          </xsd:restriction>
        </xsd:simpleType>
      </xsd:schema>
      <xforms:instance>
        <si:instance>
          <si:item name="password"/>
        </si:instance>
      </xforms:instance>
      <xforms:bind nodeset="password" type="myType"/>
    </xforms:model>
  </head>
  <body>
    <xforms:input model="model1" ref="password">
      <xforms:label>Password:</xforms:label>
    </xforms:input>
  </body>
</html>
Note:

Not all XML elements and attributes are supported by MCS. Refer to the topic entitled XML Schema elements for the complete list of supported elements.

Defining base types

The base type of a restriction can be specified in the following ways:

  1. Primitive types - the base type is one of the supported primitive types, i.e. 'mcs:tel', 'xforms:anyURI', 'xforms:date', 'xforms:dateTime', 'xforms:decimal', 'xforms:double', 'xforms:email', 'xforms:float', 'forms:string', 'xforms:time'.

    <xsd:schema>
      <xsd:simpleType name="myType">
        <xsd:restriction base="xforms:string">
          <mcs:pattern value=".*cat.*"/>
        </xsd:restriction>
      </xsd:simpleType>
    </xsd:schema>
  2. Custom types - the base type is another custom type. Note that the parent restriction must be less restrictive than the child restriction.

    <xsd:schema>
      <xsd:simpleType name="myType">
        <xsd:restriction base="otherMyType">
          <xsd:maxLength value="51"/>
        </xsd:restriction>
      </xsd:simpleType>
      <xsd:simpleType name="otherMyType">
        <xsd:restriction base="xforms:string">
          <xsd:maxLength value="512"/>
        </xsd:restriction>
      </xsd:simpleType>
    </xsd:schema>
  3. Inline types - the base type is specified directly within the xsd:restriction element. Note that the parent restriction must be less restrictive than the child restriction, and the inline type must have no name attribute.

    <xsd:schema>
      <xsd:simpleType name="myType">
        <xsd:restriction>
          <xsd:simpleType>
            <xsd:restriction base="xforms:string">
              <xsd:maxLength value="512"/>
            </xsd:restriction>
          </xsd:simpleType>
          <xsd:maxLength value="51"/>
        </xsd:restriction>
      </xsd:simpleType>
    </xsd:schema>

Using mcs:pattern

The mcs:pattern element can contain a regular expression (in the sense of the ECMAScript specification) that defines the validation pattern. If multiple mcs:pattern elements are specified within a single xsd:simpleType element, then their values will be combined together (using the logical OR operator) as if they appeared in a single regular expression. For example, the following restriction:

<xsd:schema>
  <xsd:simpleType name="myType">
    <xsd:restriction base="xforms:string">
      <mcs:pattern value=".*cat.*"/>
      <mcs:pattern value=".*dog.*"/>
    </xsd:restriction>
  </xsd:simpleType>
</xsd:schema>

will result in:

<input type="text" pattern=".*cat.*|.*dog.*"/>

However, if multiple mcs:pattern elements are specified on different levels, then the pattern closest to the simple type of the field will be used. For example, the following code:

<xsd:schema>
  <xsd:simpleType name="myType">
    <xsd:restriction>
      <xsd:simpleType>
        <xsd:restriction base="xforms:string">
          <mcs:pattern value=".*dog.*"/>
        </xsd:restriction>
      </xsd:simpleType>
      <mcs:pattern value=".*cat.*"/>
    </xsd:restriction>
  </xsd:simpleType>
</xsd:schema>

will result in:

<input type="text" pattern=".*cat.*"/>

Styling forms

Page authors can use the in-range, out-of-range, required, optional, valid and invalid pseudo-classes to style XForms elements based on their validation status. The in-range and out-of-range pseudo-classes can be used to control styling of an XForms element that has a data range defined when the entered data are within or outside that range, respectively. The required and optional pseudo-classes are used to style required form fields and the optional ones. A field is required when its value is required before the instance data is submitted. The invalid pseudo-class specifies all style changes that should be applied to an XForms element when its value fails validation, and valid specifies styles that should be applied when the validation succeeds.

Related topics