Identity Constraint Support for XML Schema

[Andy Clark <an...@apache.org>]

This message is in regards to adding identity constraint
(unique/key/keyref) support for XML Schema. I volunteer to do
the work for adding this feature but I want to run some ideas
past the Xerces community at large. Please read on...

DISCLAIMER

I ask that any XML Schema experts out there please correct
anything that I get wrong in describing identity constraints
and their problems.

OVERVIEW

For those who don't know, Schema has the ability to specify
unique keys and references to those keys relative to a element
scope in the instance document. It goes beyond what can be
accomplished with the ID/IDREF support in DTD grammars which
requires that keys be unique within the entire document. XML
Schema further allows multiple values to be considered 
together for uniqueness and comparing keys and key references
based on the datatype for the key values.

In case you're too scared of the specification, this is
basically how they work. Identity constraints are defined 
within an element declaration. They are composed of two parts, 
the "selector" and one or more "fields". The selector is 
relative to the element scope in which it is defined and the 
field(s) are relative to the selector.

The selector for an identify constraint must select an element
within the element scope which defines the identity constraint.
(Please note that the element selected by the selector can be 
the start of the element scope.) Each field must select either 
an attribute or an element of simple type.

PROBLEMS

Some of the problems that arise in implementing identity
constraints for XML Schema are the use of XPath to define 
selectors and fields; and the requirement that key values be 
compared in the value space as opposed to the lexical space 
(e.g. "1.0" and "1" are equal in the value space but not in 
the lexical space for decimal types).

The use of XPath is the most onerous because of the need
(depending on the XPath) to buffer large portions of the 
document in order to match the XPath expressions. This 
reduces the advantages of using SAX, for obvious reasons.
I would guess this is precisely the reason why Oracle
chose not to support this Schema feature at all in their
SAX parser.

We also need to compare key values in the value space. This
is made slightly more difficult by the use of XPath because
you have to figure out the datatypes for the fields and store
those datatypes in order to do the comparison later of the
key references encountered in the document. But this part may 
not be that difficult afterall.

PROPOSAL

I propose that we implement a subset of the identity 
constraints in the current XML Schema specification. The
simplication refers directly to the XPath expressions that
can be used to specify selectors and fields.

Even though selectors are limited to selecting elements and
fields are limited to selecting attributes and elements of
simple type, the use of predicates and some path expressions
require look ahead and therefore require buffering of the
document. By simplifying the allowed XPath expressions, it
is easier to implement and can be used regardless of the
resultant API (SAX, DOM, etc). Most implementations of 
Schema identity constraints rely on the DOM or some other
tree-based API where the entire document is buffered.

I have some ideas regarding what the XPath subset would 
look like and other implementation issues but I'd like to
get some from the Xerces community before going further.

-- 
Andy Clark * IBM, JTC - Silicon Valley * andyc@apache.org