Identity Constraints
Identity constraints (IDCs) can be defined on global or local element declarations. They specify the uniqueness of nodes and enable correct referencing between unique nodes.
Declaration mechanisms
The following mechanisms are available for defining an IDC (unique, key, keyref):
•In Schema Overview, IDCs can be declared on global elements. Select a global element and define IDCs in the Identity Constraints tab of the Attributes/Assertions/Identity-Constraints (AAIDC) pane (screenshot below).
Add an IDC (unique, key, keyref) using the Insert or Append icon of the Identity Constraints tab. These icon can also be used to add a field to the selected IDC. Use the Delete icon to delete the selected field or IDC.
•In the Content Model View of a global element, IDCs can be defined on the global element or on a local descendant element. In this view, IDCs can be edited either in the Identity Constraints tab (screenshot above) or in an element's Constraints box in the diagram (screenshot below, in which the match element has a uniqueness constraint that has a team selector). The latter alternative can be selected in the Schema Display Configuration dialog (Schema Design | Configure View). Alternatively, you can click the Display Constraints in Diagram icon in the Schema Design toolbar. The diagram provides a graphical representation of IDCs and drag-and-drop editing functionality.
To add an IDC (unique, key, keyref) in the diagram when diagram mode for IDCs is switched on, right-click the element to be constrained and select Add Child | [ IDC ] from the context menu. The field item will be enabled in the context menu only when an IDC is selected in the diagram. Press the Delete key to delete the selected field or IDC.
The XPath expression can be entered in the selector and field boxes in one of three ways: (i) by typing it in, (ii) by selecting the required node from a dropdown list that appears automatically when you click in the selector or field box, or (iii) by dragging the target node into the selector or field box and dropping it when the box becomes highlighted; the XPath expression will be created automatically.
| Note: | Additionally, an overview of all identity constraints in the schema is available in the Identity Constraints tab of the Components entry helper. |
Identity constraint icons
 | Display Constraints in Diagram: Enabled in Content Model View. Toggles the display of IDCs between the diagram (toggled on) and the Identity Constraints tab. |
 | Visualize Identity Constraints: Enabled in Content Model View. Toggles the display of IDC information on and off. |
  | Selector node, Field node: Seen in node boxes in the diagram, these two icons identify, respectively, the node selected (in IDCs) by the XPath expression for selector and for field. |
Visualizing IDCs
When the Visualize Identity Constraints icon is toggled on, IDC information is displayed in the diagram and can be visualized better. When visualization is toggled on, nodes selected by the selector and field XPath expressions are indicated with icons in their boxes (see icons section above), and the IDC box is connected to its selector and field boxes with green lines (see screenshot above).
The Visualize ID Constraints icon also switches on IDC validation functionality in Schema View. If an XPath expression is incorrect or an IDC is otherwise incorrect, errors are indicated with red text, warnings with orange text. On validating the XML Schema document, error or warning messages are displayed in the Messages window.
You can also disable validation by toggling the Visualize ID Constraints icon off.
XML listing
The IDC examples further below in this section are based on the following valid instance document.
<results xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="Scores.xsd">
<!----- Groups ----->
<group id="A">
<team name="Brazil"/>
<team name="Germany"/>
<team name="Italy"/>
<team name="Holland"/>
</group>
<group id="B">
<team name="Argentina"/>
<team name="France"/>
<team name="England"/>
<team name="Spain"/>
</group>
<!----- Matches ----->
<match group="A" date="2012-06-12" location="Munich">
<team name="Brazil" for="2" points="3"/>
<team name="Germany" for="1" points="0"/>
</match>
<match group="A" date="2012-06-12" location="Frankfurt">
<team name="Italy" for="2" points="1"/>
<team name="Holland" for="2" points="1"/>
</match>
<match group="B" date="2012-06-13" location="Munich">
<team name="Argentina" for="2" points="3"/>
<team name="France" for="0" points="0"/>
</match>
<match group="B" date="2012-06-13" location="Berlin">
<team name="England" for="0" points="1"/>
<team name="Spain" for="0" points="1"/>
</match>
</results>
Uniqueness constraints (unique)
A uniqueness constraint specifies that the value of an element or attribute (or of a set of elements and/or attributes) must be unique within a defined scope. In the XML listing shown above, we wish to ensure that the two teams playing a match are not the same team. So, within the scope of each match element, we constrain the values of the team/@name node to be unique. We do this as follows.
1.In Schema Overview, select the match element. The match element will therefore be the scope of the identity constraint definition.
2.In the Identity Constraints tab, click the Add or Insert icon at the top left of the tab, and, in the menu that pops up, click Unique. This adds a row for the uniqueness constraint (see screenshot below).
3.Give the identity constraint a name. (In the screenshot above, MatchTeams is the name.)
4.Enter an XPath expression in the Selector column to select the team element. Note that the match element is the context node. The team element will now be the IDC's selector, that is, the node to which the uniqueness constraint applies.
5.In the Field column, enter the @name node that must be unique. The value of this node is the value that must be unique.
The uniqueness constraint described above specifies that within the scope of each match element, every team element must have a unique @name attribute-value.
You can use additional fields to check for uniqueness. For example, a uniqueness constraint can be defined on the results element to check that all matches have a unique combination of date and location: Not more than one match may occur at one location on the same date. The uniqueness constraint must have, for each match element (the selector), its combination of @date and @location values unique within the scope of the results element.
Define the uniqueness constraint on the results element in a similar way to that described above. The selector will be match, and the fields will be @date and @location (see screenshot below). Add the second field by clicking the Append icon and then Field.
| Note: | The Refer column in the Identity Constraints tab is enabled for keyref constraints only, not for unique or key constraints. |
Key constraints (key)
A key constraint specifies: (i) that the value of an element or attribute (or of a set of elements and/or attributes) must be unique within a defined scope, and (ii) that these field elements and/or attributes must be present in the instance XML document; therefore, optional elements or attributes should not be selected as fields of a key constraint. A key constraint is thus (in point (i) above) exactly the same as a uniqueness constraint. It stipulates one additional constraint: that its field elements/attributes must be present in the XML document.
The screenshot below shows a key constraint defined on a match element that is similar to the first uniqueness constraint described above.
This key constraint specifies that within the scope of each match element, every team element must have a unique @name attribute-value. Additionally, it specifies that the @name attribute must be present on every match/team element.
| Note: | The Refer column in the Identity Constraints tab is enabled for keyref constraints only, not for unique or key constraints. |
Key references (keyref)
Key references check one set of values in an instance document against another. In our XML listing, for example (see listing above), we can use a key reference to check whether the teams playing in matches are among the teams listed in the respective groups. If not, the XML document will be invalid.
First, we create a uniqueness constant or key constraint. The screenshot below shows a uniqueness constraint (unique), TeamsInGroups, created on the results element. This constraint stipulates that each team in group has a unique @name attribute.
Next, we create the key reference (keyref), TeamCheck, which selects the team child of match and checks whether its @name attribute-value is present among the values returned by TeamsInGroups, which it references (in the Refer column).
The screenshot below shows the graphical display of this key reference (highlighted in blue) together with the Details entry helper (in which you can also select the referenced IDC). The relations of the selected IDC are shown with a solid green line, while unselected IDCs are shown with a dotted green line. Also, for each identity constraint the node selected by the XPath expression for selector and field are shown with the icons and respectively. If a node is collapsed, the relationship line to it ends with an ellipsis.
Using xpathDefaultNamespace
A default namespace declared in the XML Schema document is the default namespace of the XML Schema document. It applies to unprefixed element names in the schema document—but not to unprefixed element names in XPath expressions in the schema document.
The xpathDefaultNamespace attribute (a new feature in XSD 1.1) is the mechanism used to specify the namespace to which unprefixed element names in XPath expressions belong. XPath default namespaces are scoped on the XML Schema elements on which they are declared. The xpathDefaultNamespace attribute can occur on the following XML Schema 1.1 elements:
•xs:schema
•xs:assert and xs:assertion
•xs:alternative
•xs:selector and xs:field (in identity constraints)
The xpathDefaultNamespace on xs:schema is set, in XSD 1.1 mode, in the Schema Settings dialog (Schema Design | Schema Settings). For the other elements listed above, the xpathDefaultNamespace attribute is set in their respective Details entry helpers (see screenshot below for example).
Declaring the XPath default namespace on xs:schema, declares the XPath default namespace for the scope of the entire schema. You can override this declaration on elements where the xpathDefaultNamespace attribute is allowed (see list above).
Instead of containing an actual namespace, the xpathDefaultNamespace attribute can contain one of three keywords:
•##targetNamespace: The XPath default namespace will be the same as the target namespace of the schema
•##defaultNamespace: The XPath default namespace will be the same as the default namespace of the schema
•##local: There is no XPath default namespace
If no XPath default namespace is declared in the document, unprefixed elements in XPath expressions will be in no namespace.
| Note: | The XPath default namespace declaration does not apply to attributes. |
IDs of identity constraints
An ID can be assigned to an identity constraint, its selector, and/or field/s. To assign an ID, select the required component and, in the Details entry helper, enter the ID in the id row.
Sorting identity constraints
You can sort the IDCs in the Identity Constraints tab by clicking the Sort icon in the tab's toolbar. In the Sort Components dialog that pops up (screenshot below), you can choose to sort either the selected single component and its siblings, or the set of selected components. You can use click+Shift to select a range and click+Ctrl to add additional components to the selection.
After setting the range you can choose to sort the entire range alphabetically (Name before kind), or organized alphabetically by kind (that is: uniqueness constraints first, then key constraints, then key references).
The sort order is implemented in the text of the schema.