Requirement for value constraints in XML Schema.

Dear XML Schema working group,

We would like to respectfully propose a new requirement for XML Schema
1.1, as described below.

Best regards,

Michael Benedikt and Jerome Simeon

Lucent Technologies
Bell Laboratories


Summary
--------

Responding to the 'call for requirements' posted on the XML Schema
Working Group page, we would like to propose to add more powerful
kinds of integrity constraints in XML Schema. More specifically, we are
proposing to add so-called "Value Constraints" as a feature to XML
Schema.


Feature description
-------------------

Currently, XML Schema 1.0 supports several forms of identity and
referential constraints. In many cases, additional business rules or
other forms of constraints need to apply on a given schema. "Value
constraints" are constraints on the document that involve restrictions
on the relationships
between text or simple values contained within certain portions of the
document.

Such constraints could allow, for instance: 

 * permissible combinations of simple values of among several elements
or attributes across a document. 

 * constraints over aggregate values

 * inequality constraints on values among several elements or attributes
across a document.

 * integrity constraints that are applied across parts of the document
reached by following keyrefs or IDREFs.

Those kinds of constraints go beyond the scope of current XML Schema
identity and referential constraints. Currently, developers need to
check these kinds of business/consistency constraints at the application
level, requiring significant amounts of ad hoc development and testing.


Use case
--------

Here are some examples of such constraints that are abstracted from a
real networking application within our company. The examples refer to a
document which contains information about regions. Each region has an
id, a configurationid, a color, and an accesscode. The id attribute is a
key for a region, while the configurationid is a foreign key into a
configuration element lying elsewhere within the same document. A
configuration element has an id identifier and also a configurationtype
attribute. 

A region contains within it a list of adjacent regions: each adjacent
region element has a regionid attribute that is a foreign key back to
some other
region element.

A fragment of a schema is below. We omit many additional attributes
from the real application, as well as the XML schema constraints that 
guarantee that configurationid points to the id of a configuration
and regionid points to the id of a region.

<element name="region">
   <complexType>
      <element name="AdjacentRegions">
         <complexType>
            <sequence>
               <element name="AdjacentRegion" maxOccurs="unbounded"/>
                  <complexType>
                     <attribute name="regionid" type="xs:string"/>
                  </complexType>
               </element>
            </sequence>
         </complexType>
      </element>
      <attribute name="id" type="xs:string"/>
      <attribute name="configurationid" type="xs:string"/>
      <attribute name="color" type="xs:string"/>
      <attribute name="accesscode" type="xs:string"/>
   </complexType>
</element>

<element name="configuration" >
   <complexType>
      <attribute name="id" type="xs:string"/>
      <attribute name="configurationtype" type="xs:string"/>
   </complexType>
</element>

Here are a number of constraints that need to apply on that schema, on
top of the XML Schema key and keyref constraints:

 * Constraint 1: For any region, no two ajacent regions can have the
same color.

 * Constraint 2:  The accesscode of a region must be unique, when
compared with adjacent regions with configurationids that are different
from that region.

 * Constraint 3: All the regions adjacent to a given region must have
the same configurationtype for their associated configuration.

Analysis
--------

Although the above constraints cannot be expressed as current XML Schema
1.0 constraints, we believe they are representative of many others that
people want to impose in different applications domains (business
constraints, consistency constraints, etc).

All of the above constraints can be expressed as statements about the
return value of a simple kind of XPath or XQuery boolean expression.
Hence one way to support them would be by adding the ability to
associate such assertion on the value of (a possibly limited kind of)
boolean XPath or XQuery expression, or the emptiness/non-emptiness of an
XPath or XQuery expression as constraints to certain types/elements in
the schema. Naturally, other mechanisms could be considered.

Our experience on the above use case within our company shows that such
constraints can be efficiently implemented, and can be supported in a
generic way.

Hence, we believe adding such value constraints to XML Schema would
benefit XML Schema users, and be a natural extension of the current XML
Schema 1.0 specification.
-- 
Jerome Simeon -
Bell Laboratories --- Lucent Technologies
600 Mountain Avenue, Murray Hill, NJ, USA
Tel: +1 908 582 5473 Fax: +1 908 582 7308

Received on Thursday, 11 April 2002 17:03:34 UTC