XML is the common data format in the exchanges between Business and Operations Support Systems (B/OSS). The exchanges carry  business objects (BO) which are identified by one of more member elements. This article is about how to declare and use object keys in XMLs in the context of an Enterprise Information System (EIS).

The key or identity information of a XML business object (XML-BO) is a "metadata" aspect: it is not explicit in the XML, instead  is defined separately, as meta-data,  known by the components that process the data. XML meta-data can be described in multiple  ways. The one that I will use in this article, and the most common, is the XML Schema Definition (XSD).

XSD does not directly support the concept of object ID but has related constructs. One of them is the ability to declare element identity constraints using the XSD elements: ID/IDREF/IDREFS and KEY/KEYREF. These constructs are used to impose uniqueness and/or referential integrity within an instance of XML. They are not intended as having a cross-instances meaning. But maybe, extending the semantic, we can use these constructs to define object identity in an EIS context.

ID and IDREF(S) are data-types associated to attributes or elements. These are not good candidates to represent an enterprise key. First, there can be only one ID per element and thus we cannot represent composed keys. Second, the ID must be unique across all elements …  but a key is associated with one type and can be the same across different types. Finally, the ID type cannot start with a digit, which is annoying because very often the business objects are identified through numbers.

KEY/KEYREF are extensions of the concepts introduced by ID/IDREF. Using XSD:KEY it is possible to enforce uniqueness inside an instance. XSD:KEYREF enforces key references within an XML document. KEY/KEYREF constructs can be defined only for top-level elements. They cannot be used in global complex-types. At first this may seem a limitation, because one best-practice is to use as much as possible complex types rather than top-level elements. On a second thought, it is likely that all the business-objects that can be identified in an EIS can exist independently and, as such, must have a top-level element.

XSD:KEY construct has meaning at collection level, not individual item (record) level. While it is possible to declare an XSD:KEY for an item, there is no benefit to do that (because there is no benefit to validate uniqueness in a set with one element). To unify the semantics for XSD:KEY defined in the W3C standard with our goal, (i.e object identification in EIS scope), we can create have a top-level element that corresponds to all objects in EIS and to define the key at that level. For example, the right figure shows how to define the key for a Price business object. The key is defined as an identity constraint in the context of the top element BusinessObjectAll which is a virtual collection of all the objects in EIS.

Alternatively, we can have the key defined at the PriceSet level. That will require having PriceSet as top-level element. This is shown in the right figure. This approach can be applied to any entity type <E> using the following conventions:

• for every business entity <E> there will be a definition a XML complex-type <E> and a top-level element <E>Set;
• the top level element <E>Set will have an identity constraint called <E>Key with the selector ./<E> and a number of fields which are forming the key.

Other options for declaring object IDs are:

• define custom annotations in the XSD;
• define the key in XSLT as separate annotations (<xsl:key name="tasks" match="task" use="@id"/>)

Related articles:

• Microsoft .NET uses a combination of xsd:key and custom annotation to convert XML in DataSets (http://msdn.microsoft.com/en-us/library/1ey3xz73(VS.80).aspx)