Metadata Update

This page contains examples supporting the Metadata Update profile.

OASIS ebXML Registry 3.0 support for Metadata Versioning

This work is enabled by new metadata management features introduced into version 3.0 of the ebXML Registry standard (ebRIM and ebRS). The key new concept is the ability to maintain multiple copies or versions of a metadata object, such as an ExtrinsicObject, which represents in metadata a single real document in a repository. In terminology of the standard, all objects stored in the registry are called Registry Objects. A new concept is the Registry Object Instance, a specific version of a Registry Object. Collectively, all the versions of a Registry Object are called a Logical Registry Object.

All Registry Objects are identifiable by their id attribute. All objects in the registry must have a unique value for their id attribute. This sense of identity is maintained when metadata versioning is introduced. To allow a collection of registry objects to be grouped together and be identified as versions of the same object, two new attributes are introduced: the Logical ID and the VersionInfo element. While all objects must have unique value for their id attribute to maintain their identity, all objects that are versions of the same logical object have the same logical id or lid attribute.

The simplest form of an ExtrinsicObject, as specified in ebRIM 2.1, looks like:

<ExtrinsicObject id=”urn:uuid:123...”>     
</ExtrinsicObject>

containing only an id attribute giving it its identity. Note that we use a shortened format for UUIDs to improve readability. In ebRIM 3.0 this same object could be coded as:

<ExtrinsicObject id=”urn:uuid:123...” lid=”urn:uuid:123...”>     
</ExtrinsicObject>

In this version of the standard, the registry object still maintains its identity by having a unique value for the id attribute. The presence of the lid attribute having the same value as the id attribute indicates that this is the first, the original, version of the object. Current XDS, XDS.a and XDS.b, return this format from a Stored Query since that transaction is coded in ebRIM 3.0. Future versions of an object, that is version 2..n of an object, will have new values for the id attribute but the original value for the lid attribute. The value of the lid attribute is always equal to the value of the id attribute of the first version of the registry object. To query, in SQL, for all versions of this ExtrinsicObject one would use an SQL clause of

	lid='urn:uuid:123...'

and each ExtrinsicObject returned would have the same value for the lid attribute but a different value for its id attribute.

Note that while the lid attribute labels the various versions of a registry object and the id attribute allows each version to be addressable by being unique, these two attributes are inadequate for determining which is the first version, the second version, etc. For this the standard introduces the VersionInfo element which looks like:

<VersionInfo versionName=”2” comment=””/>

This element is required in all registry objects. In XDS, this means it is required in ExtrinsicObject, RegistryPackage (submission set and folder), and Association. It is also required on Classification and ExternalIdentifier objects.

The ebRIM 3.0 specification introduces rules on the behavior of versions of registry objects. All versions of an ExtrinsicObject reference the same document in the repository. For XDS.b this implies that all versions of a DocumentEntry/ExtrinsicObject must carry the same value for the XDSDocumentEntry.uniqueId attribute since it is used to reference the actual document in the repository. An Association always references a specific version of a registry object through its id attribute. Its attributes sourceObject and targetObject hold the id attribute of the object being pointed at.

The lid attribute is not required in the submission of a registry object. The value of the lid attribute defaults to the value of the id attribute thus creating the first version of a registry object by default.

The VersionInfo attribute is never submitted to the registry, it is generated by the registry and always returned from a query. The versionName portion of the VersionInfo attribute is automatically allocated and set by the registry. It defaults, in the standard, to versionName=”1.1” but the registry implementation is not constrained in what numbering scheme it uses. The comment portion of the VersionInfo attribute is set by the comment attribute of the <rim:Request/> element. In XDS.b this corresponds to the <rim:SubmitObjectsRequest/> element that is coded in the Provide And Register Document Set and Register Document Set transactions. Note that this comment applies to all objects submitted in the request.

The ebRS 3.0 standard includes the request/verb, UpdateObjectsRequest, for submitting updates to a Registry Object. A traditional update in ebRS is to update or add a single attribute, such as a Slot, to an existing Registry Object. Creating a new version of an object is a separate operation. Note that updates can be carried in either UpdateObjectsRequest or SubmitObjectsRequest requests according to ebRS 3.0.

When a registry object (such as an ExtrinsicObject) is updated, the submitter must query the registry for the previous version, update the parts of the object as needed and resubmit the entire registry object. Individual attributes cannot be updated.

The ebRIM 3.0 standard allows for the creation of new status attribute values.