$$Author: Admin $
$$Date: 06-08-29 16:21 $
$$Revision: 12 $The CSDocs proposal includes creation of a new general property that can be used on any persistent element, the InstanceId. This is a structural solution, accomplished entirely within the model, for identifying elements of independently-persistent objects when it is valuable to do so, as in CSDocs compounding relationships.
This position statement is part of the CSDocs Architecture Sketch. It elaborates on proposed rules for InstanceId values and how the property is introduced. This is the basis for further e-mail discussion and arrival at a consensus position in the CSDocs Foundation proposal.
The statement is in two parts:
Having InstanceId be an Optionally-Supported Property of dmaClass_DMA Class
That is discussed on this page.
Having InstanceId values be DmaId values.
That is discussed on a companion page that also addresses use of DmaId values in legacy situations.
Content
Limitations of DMA OIID
Need for Identification of Interior Elements of Objects
What InstanceId Provides
Background on DMA Property Inheritance
Sticking to Optionally-Supported
- There will be a new InstanceId Property for uniquely distinguishing persistent elements in a Document Space, including interior elements of independently-persistent objects. These identifications will be generated automatically by document spaces that support them, on the persistent elements they are supported on.
This is in addition to the DMA OIID, which identifies independently-persistent objects but does not provide identification of anything smaller than that.
There is alignment that we will have this optional capability and rely on it for the CSDocs Compound/Structured Documents extensions to DMA 1.0.
- InstanceId is introduced on the dmaClass_DMA class, the base class of every DMA class hierarchy. Support is not required and the property is read-only, value optional, and system-derived.
This means that the property can be introduced at any lower point in the class hierarchy, including on distinct sub-hierarchies, and is then preserved by inheritance below that. This is not a new principle. The related dmaProp_OIID is introduced into the DMA scheme of things in exactly the same way.
Discussion: There is some objection to this by developers. The alternative is to introduce the property specifically where it is needed for CSDocs and other introductions in a document space would happen, and be documented, on an individual case basis. The effect appears to be identical, the difference is in how the specification is written.
- The dmaProp_InstanceId property has values of type DmaId. That is, the values are globally-unique identifiers.
There is concern that this may be difficult to produce when adding DMA interfaces above a legacy implementation. The alternative is to use some kind of string, and perhaps require only local uniqueness.
In these position papers, use of a DmaId and achievement of global uniqueness and complete unambiguity is proposed to avoid having to worry about degrees of uniqueness, especially in query, cross-repository operations, etc.
There is general alignment on the overall principles of section. The requirement for an InstanceId is recognized. Everything else is eligible for review. Here is further background and positions on the two areas that have been raised for discussion.
There is general agreement on the following analysis. The areas being explored are expanded on in subsequent sections.
In the DMA Model, the only objects that are uniquely and globally identified are what we call independently-persistent objects.
Every independently-persistent object has an OIID (Object Instance Identification) property. The OIID provides a text string (of type DmaString) that is an unambiguous URL for that object. The way to determine whether an object interface delivered by the DMA API is for an independently-persistent object is to check whether there is a dmaProp_OIID property and that property has a value.
No two different DMA documents anytime and anywhere and anytime on the planet are supposed to ever have the same OIID. They can always be distinguished by having different OIIDs. The OIID also provides enough information for a DMA application to locate the object where it can be accessed: The OIID identifies the document space and provides a likely way it can be reached.
An OIID is actually over-specified: It carries advice on how to find the document as well as how to distinguish the document from all others. There can be different OIID strings that locate the same document. OIID strings are not necessarily unique, yet OIIDs unambiguously locate a particular document and never any other document. OIIDs are not supposed to be reused.
These are the limitations: OIID applies only to independently-persistent objects and it provides unambiguity, not uniqueness.
CSDocs and other applications of the DMA 1.0 model have a need to unambiguously identify elements of larger DMA objects.
In DMA 1.0, there is no assured way to unambiguously identify an element of an independently-persistent object without some special convention beyond what DMA 1.0 provides. That is, there is no reliable way to talk about a particular rendition of a DocVersion, or a particular content element of a particular rendition.
In DMA 1.0, renditions and content elements are not independent things. They always occur as parts of larger independently-persistent things, DocVersions. There can also be other elements of this kind.
In short, there is no convention for unambiguously and unalterably labeling the parts of interesting DMA objects, so they can be referred to unambiguously, just like we can unambiguously refer to a DocVersion by an OIID string. That is, there is no structural or well-known feature that one can count on to provide an identification of interior elements of objects.
[There is also a need for authenticated access to elements and independently-persistent objects, as when passing a reference to an element to a third party. The CSDocs proposals do not cover that case, which will need to be addressed separately as a general security and AAA topic for DMA.]
Unambiguous identification of internal elements keeps coming up as a requirement in DMA-based solutions. The CSDocs subcommittee is proposing a single consistent structural solution that provides for identifiable elements without concern for any existing properties or application-specific identifications that might be in use. InstanceId provides a consistent means for navigation to and identification of persistent elements. It can be delivered by any DMA Document Space independent of specialized application properties and structures that are supported, providing a high level of interoperability and consistency for this recurring requirement.
InstanceId can be added to elements of legacy objects and it can be employed on new objects. It will not interfere with any existing DMA 1.0 application. It will provide additional usefulness in those applications that are subsequently designed to take advantage of it.
The dmaProp_InstanceId property is a new property having no conflict with any well-known or custom property used in any DMA 1.0 implementation. Elements that already have a property that satisfies the definition of the dmaProp_InstanceId property can provide dmaProp_InstanceId as an alias for that existing property, exploiting the existing implementation.
The dmaProp_InstanceId property can be implemented as a property of any class having persistent instances (whether independently-persistent or a persistent element). Its definition will show up in the class description as value-optional, read-only, and system-derived. The value is optional on property interfaces delivered through the DMA API because there can be always be working instances that do not yet have any persistent existence.
It is proposed to introduce dmaProp_InstanceId on the base dmaClass_DMA class of the DMA class hierarchy. The property will be specified to have support optional and be read-only, and system-derived with optional value.
The DMA Object Model and definitions of Classes and Properties in the DMA 1.0 specification are actually a schema or template that any DMA 1.0 metadata space satisfies. DMA 1.0 does not specify the metadata space a DMA DocSpace must have. Instead, it specifies the pattern that any DMA 1.0 metadata space must follow. The DMA class hierarchy is a pattern for generating admissible metadata spaces, including ones for DocSpace implementations. Similarly, the DMA class inheritance model is a pattern for the inheritance model of a legitimate DMA 1.0 metadata space.
The DMA inheritance model is also different than the inheritance models of object-oriented programming models. For one thing, the DMA classes do not correspond to implementations, so inheritance has nothing to do with the implementations of classes. Implementations are not visible and there can be any number of implementations of the same DMA class, even in the same metadata space.
A property that is specified in a class description of a metadata space must be specified in descriptions of all subclasses of that class. For DMA, this does not prohibit the property being specified for disjoint classes. Just because a property is defined as well-known and used in one part of the DMA-specified hierarchy, it is not prevented from being independently-introduced elsewhere in the same metadata space. This is a specific provision of the DMA 1.0 object model.
There are some features in the DMA Object model, especially the class descriptions and inheritance model, that apply only to the pattern or scheme. One such case is that of "optionally-supported properties." There is no such thing as an optionally-supported property in a metadata space. A property is defined for a class of the metadata space or it isn't. If it is defined for a class, it will be defined for all subclasses of that class too. That much is certain.
There is an objection around the difficulty of figuring out where support for an optionally-supported property arises, and dealing with the same property being supported on disjoint subtrees of the DMA class hierarchy. There are two things to deal with:
- The introduction of the same property, with the same DmaId for its identification, on disjoint subtrees of the DMA class hierarchy is already allowed, independent of the existence of support-optional well-known properties.
- No matter where a support-optional property is introduced in the DMA metadata space pattern, there is always the prospect of the property arising on disjoint subtrees in an actual metadata space.
There is no particular advantage to specifying a well-known optionally-supported property on different major class-hierarchy subtrees where it might reasonably occur. There is some advantage in specifying properties at a level in the class hierarchy that is at or above the highest point where a property is normally expected to occur.
The precedent for introducing an optionally-supported property at a high level already exists. The DMA class hierarchy pattern even has artificially-introduced classes precisely so such introductions can occur. dmaClass_Containable and dmaClass_Versionable are examples, as is dmaClass_Relationship.
In the case of properties related to the persistent existence of an object, there is no clear single point in the DMA class hierarchy pattern for making such a distinction. It is the precedent in DMA 1.0 to introduce such properties on the overall base class, dmaClass_DMA.
It is proposed that the same practice be employed for the introduction of dmaProp_InstanceId.
This topic is discussed in a companion position paper in a section on DmaId for InstanceId Values.
Provide references on UUIDs, how they can be generated, and provisions for generating/reserving blocks of UUIDs. Blocks of reserved Ids can be used to fabricate UUIDs from locally-unique IDs that are easily mapped to dense integers. This is also discussed in the companion position paper, in the section on references and resources.
updated 2003-03-03 14:30 -0700 (pdt) by Dennis E. Hamilton created 1999-07-06-08:40 -0700 (pdt) by Dennis E. Hamilton