Table of contents

Appendices

3.11 Identity-constraint Definitions

Identity-constraint definition components provide for uniqueness and reference constraints with respect to the contents of multiple elements and attributes.

NOTE: 

<xs:key name="fullName">
 <xs:selector xpath=".//person"/>
 <xs:field xpath="forename"/>
 <xs:field xpath="surname"/>
</xs:key>

<xs:keyref name="personRef" refer="fullName">
 <xs:selector xpath=".//personPointer"/>
 <xs:field xpath="@first"/>
 <xs:field xpath="@last"/>
</xs:keyref>

<xs:unique name="nearlyID">
 <xs:selector xpath=".//*"/>
 <xs:field xpath="@id"/>
</xs:unique>

XML representations for the three kinds of identity-constraint definitions.

The Identity-constraint Definition Schema Component[top]

The identity-constraint definition schema component has the following properties:

Identity-constraint definitions are identified by their [c-name] and [c-target_namespace]; Identity-constraint definition identities must be unique within an XML Schema. See [References to schema components across namespaces] for the use of component identifiers when importing one schema into another.

Informally, [identity-constraint_name] identifies the Identity-constraint definition as playing one of three roles:

• (unique) the Identity-constraint definition asserts uniqueness, with respect to the content identified by [selector], of the tuples resulting from evaluation of the [fields] XPath expression(s).

• (key) the Identity-constraint definition asserts uniqueness as for unique. key further asserts that all selected content actually has such tuples.

• (keyref) the Identity-constraint definition asserts a correspondence, with respect to the content identified by [selector], of the tuples resulting from evaluation of the [fields] XPath expression(s), with those of the [referenced_key].

These constraints are specified along side the specification of types for the attributes and elements involved, i.e. something declared as of type integer may also serve as a key. Each constraint declaration has a name, which exists in a single symbol space for constraints. The equality and inequality conditions appealed to in checking these constraints apply to the value of the fields selected, so that for example 3.0 and 3 would be conflicting keys if they were both number, but non-conflicting if they were both strings, or one was a string and one a number. Values of differing type can only be equal if one type is derived from the other, and the value is in the value space of both.

Overall the augmentations to XML's ID/IDREF mechanism are:

• Functioning as a part of an identity-constraint is in addition to, not instead of, having a type;

• Not just attribute values, but also element content and combinations of values and content can be declared to be unique;

• Identity-constraints are specified to hold within the scope of particular elements;

• (Combinations of) attribute values and/or element content can be declared to be keys, that is, not only unique, but always present and non-nillable;

• The comparison between keyref [fields] and key or unique [fields] is by value equality, not by string equality.

[selector] specifies a restricted XPath ([bib-xpath]) expression relative to instances of the element being declared. This must identify a node set of subordinate elements (i.e. contained within the declared element) to which the constraint applies.

[fields] specifies XPath expressions relative to each element selected by a [selector]. This must identify a single node (element or attribute) whose content or value, which must be of a simple type, is used in the constraint. It is possible to specify an ordered list of [fields]s, to cater to multi-field keys, keyrefs, and uniqueness constraints.

In order to reduce the burden on implementers, in particular implementers of streaming processors, only restricted subsets of XPath expressions are allowed in [selector] and [fields]. The details are given in [Constraints on Identity-constraint Definition Schema Components].

NOTE: 

Provision for multi-field keys etc. goes beyond what is supported by xsl:key.

See [Annotations] for information on the role of the [rc-annotation] property.

XML Representation of Identity-constraint Definition Schema Components[top]

The XML representation for an identity-constraint definition schema component is either a [key], a [keyref] or a [unique] element information item. The correspondences between the properties of those information items and properties of the component they correspond to are as follows:

NOTE: 

<xs:element name="vehicle">
 <xs:complexType>
  . . .
  <xs:attribute name="plateNumber" type="xs:integer"/>
  <xs:attribute name="state" type="twoLetterCode"/>
 </xs:complexType>
</xs:element>

<xs:element name="state">
 <xs:complexType>
  <xs:sequence>
   <xs:element name="code" type="twoLetterCode"/>
   <xs:element ref="vehicle" maxOccurs="unbounded"/>
   <xs:element ref="person" maxOccurs="unbounded"/>
  </xs:sequence>
 </xs:complexType>

 <xs:key name="reg"> <!-- vehicles are keyed by their plate within states -->
  <xs:selector xpath=".//vehicle"/>
  <xs:field xpath="@plateNumber"/>
 </xs:key>
</xs:element>

<xs:element name="root">
 <xs:complexType>
  <xs:sequence>
   . . .
   <xs:element ref="state" maxOccurs="unbounded"/>
   . . .
  </xs:sequence>
 </xs:complexType>

 <xs:key name="state"> <!-- states are keyed by their code -->
  <xs:selector xpath=".//state"/>
  <xs:field xpath="code"/>
 </xs:key>

 <xs:keyref name="vehicleState" refer="state">
  <!-- every vehicle refers to its state -->
  <xs:selector xpath=".//vehicle"/>
  <xs:field xpath="@state"/>
 </xs:keyref>

 <xs:key name="regKey"> <!-- vehicles are keyed by a pair of state and plate -->
  <xs:selector xpath=".//vehicle"/>
  <xs:field xpath="@state"/>
  <xs:field xpath="@plateNumber"/>
 </xs:key>

 <xs:keyref name="carRef" refer="regKey"> <!-- people's cars are a reference -->
  <xs:selector xpath=".//car"/>
  <xs:field xpath="@regState"/>
  <xs:field xpath="@regPlate"/>
 </xs:keyref>

</xs:element>

<xs:element name="person">
 <xs:complexType>
  <xs:sequence>
   . . .
   <xs:element name="car">
    <xs:complexType>
     <xs:attribute name="regState" type="twoLetterCode"/>
     <xs:attribute name="regPlate" type="xs:integer"/>
    </xs:complexType>
   </xs:element>
  </xs:sequence>
 </xs:complexType>
</xs:element>

A state element is defined, which contains a code child and some vehicle and person children. A vehicle in turn has a plateNumber attribute, which is an integer, and a state attribute. State's codes are a key for them within the document. Vehicle's plateNumbers are a key for them within states, and state and plateNumber is asserted to be a key for vehicle within the document as a whole. Furthermore, a person element has an empty car child, with regState and regPlate attributes, which are then asserted together to refer to vehicles via the carRef constraint. The requirement that a vehicle's state match its containing state's code is not expressed here.

Constraints on XML Representations of Identity-constraint Definitions[top]

In addition to the conditions imposed on [key], [keyref] and [unique] element information items by the schema for schemas, the corresponding identity-constraint definition must satisfy the conditions set out in [Constraints on Identity-constraint Definition Schema Components].

Identity-constraint Definition Validation Rules[top]

For an element information item to be locally valid with respect to an identity-constraint

1. The [selector], with the element information item as the context node, evaluates to a node-set (as defined in [bib-xpath]). Call this the target node set.

2. Each node in the target node set is an element node among the descendants of the context node.

3. For each node in the target node set all of the [fields], with that node as the context node, evaluate to either an empty node-set or a node-set with exactly one member, which must have a simple type. Call the sequence of the type-determined values (as defined in [ref-xsp2]) of the [schema normalized value] of the element and/or attribute information items in those node-sets in order the key-sequence of the node.

4. Call the subset of the target node set for which all the [fields] evaluate to a node-set with exactly one member which is an element or attribute node with a simple type the qualified node set.

   1. ifthe [identity-constraint_name] is unique

      thenno two members of the qualified node set have key-sequence whose members are pairwise equal, as defined by Equal in [ref-xsp2].

   2. ifthe [identity-constraint_name] is key

      then

      1. The target node set and the qualified node set are equal, that is, every member of the target node set is also a member of the qualified node set and vice versa.

      2. No two members of the qualified node set have key-sequence whose members are pairwise equal, as defined by Equal in [ref-xsp2].

      3. No element member of the key-sequence of any member of the qualified node set was assessed as valid by reference to an element declaration whose [nillable] is true.

   3. ifthe [identity-constraint_name] is keyref

      thenfor each member of the qualified node set (call this the keyref member), there must be a node table associated with the [referenced_key] in the [e-id_constraint_table] of the element information item (see [Identity-constraint Table], which must be understood as logically prior to this clause of this constraint, below) and there must be an entry in that table whose key-sequence is equal to the keyref member's key-sequence member for member, as defined by Equal in [ref-xsp2].

NOTE: 

The use of [schema normalized value] in the definition of key-sequence above means that default or fixed value constraints may play a part in key-sequences.

NOTE: 

Although this specification defines a post-schema-validation infoset contribution which would enable schema-aware processors to implement [c-nlbl] above ([Element Declaration]), processors are not required to provide it. This clause can be read as if in the absence of this infoset contribution, the value of the relevant [nillable] property must be available.

Identity-constraint Definition Information Set Contributions[top]

An eligible identity-constraint of an element information item is one such that [c-u] or [c-k] of [Identity-constraint Satisfied] is satisfied with respect to that item and that constraint, or such that any of the element information item [children] of that item have an [e-id_constraint_table] property whose value has an entry for that constraint.

A node table is a set of pairs each consisting of a key-sequence and an element node.

Whenever an element information item has one or more eligible identity-constraint, in the post-schema-validation infoset that element information item has a property as follows:

1. There is an entry in one of the node table associated with the [cb-definition] in an Identity-constraint Binding information item in at least one of the [e-id_constraint_table]s of the element information item [children] of the element information item whose key-sequence is k and whose node is n;

2. n appears with key-sequence k in the qualified node set for the [cb-definition].

NOTE: 

The complexity of the above arises from the fact that keyref identity-constraints may be defined on domains distinct from the embedded domain of the identity-constraint they reference, or the domains may be the same but self-embedding at some depth. In either case the node table for the referenced identity-constraint needs to propagate upwards, with conflict resolution.

The Identity-constraint Binding information item, unlike others in this specification, is essentially an internal bookkeeping mechanism. It is introduced to support the definition of [Identity-constraint Satisfied] above. Accordingly, conformant processors may, but are not required to, expose them via [e-id_constraint_table] properties in the post-schema-validation infoset. In other words, the above constraints may be read as saying valid of identity-constraints proceeds as if such infoset items existed.

Constraints on Identity-constraint Definition Schema Components[top]

All identity-constraint definitions (see [Identity-constraint Definitions]) must satisfy the following constraint.

1. The values of the properties of an identity-constraint definition must be as described in the property tableau in [The Identity-constraint Definition Schema Component], modulo the impact of [Missing Sub-components].

2. If the [identity-constraint_name] is keyref, the cardinality of the [fields] must equal that of the [fields] of the [referenced_key].

1. The [selector] must be a valid XPath expression, as defined in [bib-xpath].

2. 1. It must conform to the following extended BNF: Selector XPath expressions

      3.11.6	Selector	::=	Path ( '|' Path )*
      3.11.6	Path	::=	('.//')? Step ( '/' Step )*
      3.11.6	Step	::=	'.' | NameTest
      3.11.6	NameTest	::=	QName | '*' | NCName ':' '*'

   2. It must be an XPath expression involving the child axis whose abbreviated form is as given above.

1. Each member of the [fields] must be a valid XPath expression, as defined in [bib-xpath].

2. 1. It must conform to the extended BNF given above for Selector, with the following modification: Path in Field XPath expressions

      3.11.6

      Path

      ::=

      ('.//')? ( Step '/' )* ( Step | '@' NameTest )

      This production differs from the one above in allowing the final step to match an attribute node.

   2. It must be an XPath expression involving the child and/or attribute axes whose abbreviated form is as given above.