CSDocs is a set of proposed extensions to DMA 1.0 to support compound/structured documents.

The CSDocs Foundation is the fundamental framework for all further compound-structured document extensions.  It establishes the basic model of DMA compound-structured documents.  It introduces the fundamental elements by which DMA documents are organized in interdependent compound structures. 

This is a draft of in-progress work.  For access to the latest version and related information, visit http://www.infonuovo.com/dma/csdocs/sketch.

---

Authors:

DMA Technical Committee Compound Structured Document Subcommittee.  Dennis E. Hamilton, editor.

Revision History:

This is Version 0.03 of 2003-03-03

Content

1. Functional Overview/Description

1.1 Purpose

1.2 Approach

1.3 Model Overview

1.3.1 CSRelationship

1.3.2 CSRoot Renditions

1.3.3 Identifying Specific Elements in a CSRelationship

2. Glossary/Nomenclature

3. New/Changed Classes and Properties

3.1 DMA Class Changes

3.1.1 Instance Id Introduction

3.1.2 Instance Id Definition

3.2 DocVersion Changes

3.2.1 New DocVersion Properties

3.2.2 CSRoots Usage

3.2.3 CSComponents Usage

3.2.4 CSRoot Style Usage

3.3 New CSRelationship Class

3.3.1 Restricted Relationship Properties

3.3.2 New CSRelationship Properties

3.3.3 Head Rendition Id Usage

3.3.4 Head Content Element Id Usage

3.3.5 Tail Rendition Id Usage

3.3.6 Tail Content Element Id Usage

4. New/Changed Interfaces

5. New/Changed Types, Values, and Macros

6. Architectural Impacts

6.1 Integration Model

6.2 Query

6.2.1 Implementation Considerations for Query of CSDocs

6.2.2 Interoperability Considerations for Query of CSDocs

6.3 Internationalization/Localization

6.4 Content

6.4.1 Usage Considerations for CSDocs Content

6.4.2 CSDocs Content Interoperability and Safety

6.5 Containment

6.6 Versioning

6.6.1 Using Versioning with CSDocs

6.6.2 CSDocs Versioning Interoperability and Safety Considerations

6.7 Security

6.8 Naming

6.9 Locking and Transactions

6.9.1 Lock Usage Considerations for CSDocs Structures

6.9.2 Lock Implementation Considerations for CSDocs Structures

6.9.3 Interoperability of Locking for CSDocs Structures

7. Compliance & Conformance Issues

8. Sample Usage

9. What Requirements Does This Address?

10. Why Is This a Good Solution?

11. Extant Systems with Similar Features and Related Experiences

12. Impact on Existing Systems

13. Backwards Compatibility

14. Performance Impact

15. Failure Modes/Crash Recovery

16. How Is This Incorporated into the Specification?

17. How Is This Incorporated into the Code and Library Configurations?

18. Reference Materials

18.1 Normative Specifications

18.2 Informative References

18.3 Background Materials

Contributors

Change History

---

1. Functional Overview/Description

1.1 Purpose

The Compound/Structured Documents (CSDocs) Foundation extensions to DMA 1.0 provide fundamental capabilities for introducing and managing compound/structured documents in DMA Document Spaces.

CSDocs Foundation establishes a general framework within which multiple compound/structured document families and their implementations may be expressed and used interoperably.

1.2 Approach

CSDocs extensions are introduced entirely by additions to the DMA 1.0 model. There is no change to anything already in DMA 1.0. The CSDocs Foundation employs mechanisms that are already provided under DMA 1.0.

These additions do not conflict with any other well-known DMA practice

Three overall considerations have guided the formulation of CSDocs:

1. Upward Compatibility. CSDocs extensions are completely upward compatible from DMA 1.0.
2. Backward Safety. That CSDocs extensions can be encountered by DMA 1.0 requesters in a way that preserves DMA 1.0 operation where that is meaningful.
3. Interoperability. That CSDocs extensions are usable in a way that provides interoperability among CSDocs structures implemented on different collections and systems

1.3 Model Overview

The CSDocs model introduces a new Relationship subclass, the CSRelationship. There are also two new roles for DocVersions. As part of a CSDocs structure, DocVersions may occur as CSRoot and as CSComponent objects.

1.3.1 CSRelationship

CSDocs introduces CSRelationship, a new subclass of the DMA Relationship class. The relationships between DMA objects representing compound/structured documents (CSRoots) and their components (CSComponents) are expressed using CSRelationship objects (fig. 1).

CSRelationship objects link DMA DocVersions together into CSDocs structures. These structures are used for every variety of compound/structured document represented under the CSDocs extensions. The CSRelationship can be interpreted as establishing that the CSRoot uses or has the specified CSComponent as part of a compound/structured document.

A CSRoot is a DocVersion that has a non-empty CSComponents enumeration property. The CSComponents values are CSRelationships that lead to the components via their Head properties.



Figure 1 Organization of CSDocs Structures

A CSComponent is a DocVersion that has a non-empty CSRoots enumeration property. The CSRoots values are CSRelationships with Tail properties that lead to the CSRoot documents having this component.

The required class of the CSRelationship Tail property is DocVersion. The reflective property of the Tail property is CSComponents. DocVersions at the Tail of a CSRelationship are known as CSRoot objects.

The required class of the CSRelationship Head property is DocVersion. The reflective property of the Head Property is CSRoots. DocVersions at the Head of a CSRelationship are known as CSComponent objects.

As illustrated in the figure, a CSRoot may also serve as a CSComponent.

A CSDocs structure is ordinarily created by first establishing the CSRoot and CSComponent objects and then inserting the CSRelationship objects that reflect how the root and components are related in the structure. CSDocs structures might also be automatically created as a consequence of creating a CSRoot of a particular kind. Some or all CSComponents and CSRelationships might arise spontaneously as the result of requesting that such a CSRoot be created.

This is a structural model. CSDocs Foundation does not specify what the mechanism of compounding or structuring is, nor what the interpretation of the structure is. The presence of CSRelationship linkages is simply the means by which an implementation of CSDocs structures signifies that there is a compound/structured-document interdependency present. There is great freedom in what the specific interpretation of CSRelationships and the semantics of the interdependency.

1.3.1.1 Interoperability Considerations

It is recommended that the dmaClass_CSRelationship always be employed as a virtual class. Providers and requesters can form interoperability agreements about particular kinds of CSDocs structures and make the specific subclasses and their definitions widely known.

In this way, different implementations of CSRelationship can be differentiating by using a definite subclass (or alias) that reflects the defined semantics of the particular CSRelationship implementation(s). Interoperable CSDocs-aware clients can then determine when a recognized case of CSRelationship is supported. This use of the subclass structure also reduces the incidence of inappropriate merging of different CSRelationships implementations in cross-repository queries.

Allowing dmaClass_CSRelationship to be searchable along with the option for returning subclasses in the search result also improves interoperable access to a CSDocs implementation.

The recommended sense of the CSRelationship class itself is as a base class for "some compound/structured-document composition relationship." This is consistent with the DMA Relationship class standing generically for "some relationship."

The CSRoot and CSComponent DocVersion subclasses that are linked by particular CSRelationship subclasses can also be restricted as needed to implement a particular structural mechanism. This is accomplished using existing provisions of the DMA 1.0 Object Model [DMA 1.0: sections 3.1.4 Metadata Spaces, 3.1.7 Required and Optional Features, 3.1.8 Extensibility, and section 4.1.35 dmaClass_PropertyDescriptionObject Required Class and Reflective Property Id descriptions].

1.3.1.2 Backward Compatibility Considerations

A CSDocs structure is opaque to a DMA 1.0 requester. This has several consequences:

1. CSRelationship objects can be recognized but will have no DMA 1.0 interpretation beyond "some relationship" and what can be learned by inspecting the class and property descriptions.
2. CSRoot and CSComponent DocVersions, when accessed by DMA 1.0 requesters, appear simply as DocVersion subclasses that may have additional properties for application-specific, local or proprietary additions beyond the well-known DMA 1.0 properties.
3. Access to objects of CSDocs structures will appear no differently than access to any customized DMA 1.0 DocVersion or Relationship subclass.
4. CSDocs-ignorant alteration of CSDocs-involved objects can lead to severing of CSDocs relationships and their structural integrity. Prevention is by safeguarding against operations that violate an invariant of the implemented CSDocs structure. Such safeguards on the integrity of relationships are optionally available under DMA 1.0 (see [DMA1.0], [RelStrength], and section 13, Backwards Compatibility).
5. It is not expected that a CSDocs-ignorant requester will attempt to create a CSDocs structure or be equipped to succeed at such an attempt. A sufficiently-universal DMA 1.0 requester could be guided through a CSDocs construction by a CSDocs-knowledgeable operator.
6. When CSDocs support is introduced into a DMA repository, the usability of existing clients will be diminished as the use of CSDocs for new and even legacy objects becomes prevalent (see section 13, Backwards Compatibility).

The CSDocs model allows for the possibility of CSDocs structures being automatically generated on the creation of a CSRoot for a suitable type of document. These operations are safe for DMA 1.0 requesters when the resulting CSRoot is successfully usable as the overall document without having to be attentive to the CSDocs structure (e.g., any Renditions are complete renditions).

1.3.2 CSRoot Renditions

In the DMA 1.0 Content Model, any renditions of a DocVersion are expected to be at the same level of abstraction – render what is considered the same document in different presentations or with different stored representations. Also, in the DMA 1.0 Content Model, it is assumed that the Renditions are complete for what the DocVersion is understood to represent.

With the introduction of CSRoot DocVersions, there is greater potential for ambiguity depending on whether the CSRoot is viewed as standing for the overall document or merely a piece of the overall document that happens to be tied to the other pieces.

For CSDocs, the following position is taken:

1. Any renditions of a particular CSRoot are at the same level of abstraction.
2. The default interpretation of any renditions of a CSRoot is that they are complete renditions and the CSRoot represents the overall document determined by the CSDocs structure that it is the root for.
3. Other interpretations of the renditions are selected by explicit presence of a CSRoot Style property on the CSRoot object. (See 3.2.4, Usage of CSRoot Style.)

This approach preserves interoperability with multi-part compound documents stored as single DMA 1.0 documents and with those same documents with their compound structure exposed in the CSDocs model but the CSRoot renditions left intact.

1.3.3 Identifying Specific Elements in a CSRelationship

In the simplest case, the only thing known when a CSRelationship is present is that there is some interdependency between the CSRoot and the CSComponent of that relationship in realizing the overall compound/structured document represented by the particular CSRoot and all of its related components.

Additional properties are provided on the CSRelationship object to allow more-specific identification of those elements of the CSRoot and CSRelationship that are connected by the particular CSRelationship. (See section 3.3, New CSRelationship Class.)

The Head of the Relationship can be refined to a specific rendition or to a specific content element of a specific rendition of the CSComponent.

The Tail of the Relationship can be refined to a specific rendition or to a specific content element of a specific rendition of the CSRoot.

So that there is an interoperable way to identify specific elements in any CSDocs structure in any Document Space implementation, the CSDocs Foundation requires that any specific element (rendition or content element) used in this way have an InstanceId property (section 3.1, DMA Class Changes).

InstanceId properties have DmaId values. A particular rendition is selected by having its InstanceId value for the Head Rendition Id or the Tail Rendition Id value in the CSRelationship. A particular content element of that rendition is selected by having its InstanceId value for the Head or Tail Content Element Id value.

2. Glossary/Nomenclature

Complete Rendition

A rendition which requires no content elements other than its own in order to render the content of the compound document as a whole.

A DMA DocVersion can have complete renditions even though the nature of those renditions is determined by compound/structured-document relationships. The complete rendition might be composed upon access to the rendition or it might be retained in complete form and adjusted as alterations are made to components on which it depends.

Compound Document

A compound document is an organization of two or more documents in which material of all of them is used to determine the complete document. It is common for one of the documents to be viewed as a "root" or "hub" that represents how its material is combined with those of the others, the "component documents", to produce the complete compound document.

A compound document may or may not also be a structured document (which see). Compound documents tend to be viewed as composed from the components that are supplied for them. An implementation may arrange for alteration of a complete rendition to be reflected in corresponding alterations of the differentiated component documents (and vice versa).

CSRoot

A role of a DocVersion: that of having components and being part of a CSDocs structure.

CSComponent

A role of a DocVersion: that of being a component in a compound/structured document, i. e., being used/determined by a CSRoot.

NULL DmaId

Standard value, defined by the UUID specification, written as 00000000-0000-0000-0000-000000000000, signifying a NULL or omitted DmaId [DCE RPC]. This is not a value that will ever be generated as a legitimate DmaId.

Participating Element

A CSRelationship establishes a generic relationship between a CSRoot and a CSComponent. In practice, a specific element of the CSRoot is related to a specific element of the CSComponent. We refer to these as the participating elements of a particular CSRelationship case. In the absence of other information, the participating element must be assumed to be the entire CSRoot or CSComponent. CSDocs provides defined ways to explicitly identify a particular Rendition or Content Element as the participating element.

Structured Document

Structured documents are ones whose logical structure is of independent interest for reuse, access by query, and manipulation as if a separate DMA document. The structural or logical elements of a structured document (pages, paragraphs, illustrations, images, bibliographic notes, and so on) are delivered as the content of separate CSComponent objects. A CSDocs structured document can be viewed as having CSComponents that are extracted or derived in some way from the CSRoot.

The electronic representation of both structured and compound views might be supported by a single underlying implementation, and the direction of derivation may vary on a CSComponent by CSComponent basis. The term compound/structured documents reflects this potential variety of CSDocs application.

3. New/Changed Classes and Properties

Three classes are involved in the CSDocs Foundation:

1. dmaClass_DMA is extended to have the InstanceId property.
2. dmaClass_DocVersion is extended to have two enumerations (CSRoots and CSComponents) and a CSRootStyle property.
3. CSRelationship is introduced as a new subclass of Relationship objects.

3.1 DMA Class Changes

The extensions made to dmaClass_DMA are presented in a separate Web Page, dmaClass_DMA-CSDocs.html.

The single addition is for a new property, InstanceId.

3.1.1 Instance Id {dmaProp_InstanceId} Introduction

Implementation not required
Read-only
System-derived
Value-optional
Data type is scalar DmaId

3.1.2 Instance Id Definition

This optional property is meaningful only on objects that have representations as persistent objects.  The object may be dependently persistent or independently persistent.

If a class description specifies that this property is supported, but an instance of the class is not derived from an already-persistent object, the Instance Id property of the instance will have no value.

When an instance of a class supporting Instance Id is an image of an already-persistent object, the value of Instance Id will be a globally-unique DmaId that applies specifically to that already-persistent object.  An Instance Id value is set when an object is first created as persistent using an Execute Change operation or equivalent.  An Instance Id for a persistent object is never changed, even if the persistent object is updated.  If a persistent object is replaced, the replacement will have a different Instance Id value.

When an independently-persistent object has an Instance Id property, there is a relationship between the value of Instance Id and the OIID property.   When there is an InstanceId, either

1. the <object id> portion of the OIID string contains the Instance Id value in <Textualized Object DmaId> format, or else
2. the optional <object guid> portion of the OIID string is present and contains the Instance id value in <Textualized Object DmaId> format.

3.2 DocVersion Changes

The extensions made to dmaClass_DocVersion are presented in a separate Web Page, dmaClass_DocVersion-CSDocs.html.

Three properties are added.

3.2.1 New DocVersion Properties

3.2.1.1 CSRoots {dmaProp_CSRoots}

Implementation not required
Read-only
System-derived
Value-optional (can be empty)
Data type is enumeration of Object
Required class is dmaClass_CSRelationship
Reflective property is dmaProp_Head

3.2.1.2 CSComponents {dmaProp_CSComponents}

Implementation not required
Read-only
System-derived
Value-optional (can be empty)
Data type is enumeration of Object
Required class is dmaClass_CSRelationship
Reflective property is dmaProp_Tail

3.2.1.3 CSRoot Style {dmaProp_CSRootStyle}

Implementation not required
Value-optional
Data type is scalar DmaId

3.2.2 Usage of CSRoots

This optional property is meaningful only on objects that may be employed as CSComponents in CSDocs structures.  The reflective property of CSRoots is always the dmaProp_Head property of a dmaClass_CSRelationship subclass instance.   The property represents all of the CSRelationships in which this DocVersion occurs in some way as a CSComponent.

3.2.3 Usage of CSComponents

This optional property is meaningful only on objects that may be employed as CSRoots in CSDocs structures.  The reflective property of CSComponents is always the dmaProp_Tail property of a dmaClass_CSRelationship subclass instance.  The property represents all of the CSRelationships in which this DocVersion occurs in some way as a CSRoot.

3.2.4 Usage of CSRoot Style

This optional property is meaningful only on objects that may be employed as CSRoots.   When present, it specifies whether any renditions of the DocVersion are complete documents or whether some style of consolidation must be applied to derive a complete rendition.

If CSRoot Style is not supported or it is supported and has no value, interpretation is the same as when CSRoot Style is supported and the value is the NULL DmaId (DMA_CSR_STYLE_COMPLETE).

When CSRoot Style is supported and it has a value other than DMA_CSR_STYLE_COMPLETE, the value is the DmaId of a registered scheme for how a rendition of the complete document can be obtained or derived.  For any value but DMA_CSR_STYLE_COMPLETE, it must be understood that no CSRoot Renditions is guaranteed to be a complete rendition of the compound/structured document represented by that DocVersion.  

It is anticipated that particular CSRoot DocVersion subclasses may fix the value of CSRoot Style as read-only and system-derived as part of subclass-specific realization of particular CSDoc structures.  Subclasses may also limit the values to selections from a particular set of allowed values.

The following DmaId values are defined for CSRoot Style:

• DMA_CSR_STYLE_COMPLETE

The rendition supplies the content of the entire compound document (as opposed to just part of it).  This is the corresponding default interpretation of any DMA 1.0 DocVersion that has renditions, without regard to the DocVersion's involvement in an explicit or implicit compound/structured document relationship

• DMA_CSR_STYLE_INCOMPLETE

The CSRoot Renditions do not by themselves provide complete renditions.  A complete rendition is obtained by other means specific to the implementation of this CSRoot DocVersion.   The particular means is made known by application agreement.  No particular means is specified with this value of CSRoot Style.

• other values

Other values of CSRoot Style are safely interpreted as DMA_CSR_STYLE_INCOMPLETE if the actual value is not one with a definition that the application is designed to recognize.  These other values are introduced as part of application agreements so that interoperable use can be made of the CSRoot DocVersion and its renditions.

CSRoot Style is implemented with a DmaId so that the definition and advertising of particular CSRoot styles can occur on a decentralized basis without need for a central assignment authority.

3.3 New CSRelationship Class

The new dmaClass_CSRelationship is specified on a separate Web Page, dmaClass_CSRelationship.html. CSRelationship inherits from Relationship.

CSRelationship restricts the Head and Tail properties and introduces four new optional properties.

3.3.1 Restricted Relationship Properties

3.3.1.1 Head {dmaProp_Head}

This object-valued property has its required class restricted to a DocVersion subclass.

The reflective property of Head is CSRoots (dmaProp_CSRoots) for all CSRelationship subclasses.

3.3.1.2 Tail {dmaProp_Tail}

This object-valued property has its required class restricted to a DocVersion subclass.

The reflective property of Tail is CSComponents (dmaProp_CSComponents) for all CSRelationship subclasses.

3.3.2 New CSRelationship Properties

3.3.2.1 Head Rendition Id {dmaProp_HeadRenditionId}

Implementation not required
Value-optional
Data type is scalar DmaId

3.3.2.2 Head Content Element Id {dmaProp_HeadContentElementId}

Implementation not required
Value-optional
Data type is scalar DmaId

3.3.2.3 Tail Rendition Id {dmaProp_TailRenditionId}

Implementation not required
Value-optional
Data type is scalar DmaId

3.3.2.4 Tail Content Element Id {dmaProp_TailContentElementId}

Implementation not required
Value-optional
Data type is scalar DmaId

3.3.3 Usage of Head Rendition Id

If this property is supported and it has a non-NULL DmaId value, then a specific rendition of the CSComponent participates in this CSRelationship.   The Rendition object involved is the one in the CSComponent's dmaProp_Renditions list property having the matching InstanceId property value.  If there is no such Rendition, the CSRelationship has been broken.

If this property is supported, and it has no value (or the value is the NULL DmaId), then the employment of the CSComponent in the compound/structured document via this CSRelationship is not specific to a rendition of the CSComponent.   It must be assumed that changes anywhere in the CSComponent may impact the portion of the CSRoot that is involved in this relationship, and vice versa.

If this property is not supported, the CSComponent is simply the DocVersion at the Head. There is no further CSDocs information on how much of and in what way the CSComponent is employed in the compound/structured document via this CSRelationship.

3.3.4 Usage of Head Content Element Id

If this property is supported, the Head Rendition Id property must also be supported.

If this property is supported and it has a non-NULL DmaId value, then so does the Head Rendition Id property.  A specific content element of the CSComponent participates in the compound/structured document via this CSRelationship.   The Content Element object involved is the one in the identified rendition's dmaProp_ContentElements list property having the matching InstanceId property.  If there is no such Content Element, the CSRelationship has been broken.

If this property is supported, and it has no value (or the value is the NULL DmaId), then the participating element is not a definite content element. The participating element is determined in accordance with the rules for the Head Rendition Id property.

If this property is not supported, the participating element of the CSComponent is determined by the rules for Head Rendition Id.

3.3.5 Usage of Tail Rendition Id

If this property is supported and it has a non-NULL DmaId value, then a specific rendition of the CSRoot participates in the compound/structured document via this CSRelationship.   The Rendition object involved is the one in the CSRoot's dmaProp_Renditions list property having the matching InstanceId property value.  If there is no such Rendition, the CSRelationship has been broken.

If this property is supported, and it has no value (or the value is the NULL DmaId), then this CSRelationship is not specific to a rendition of the CSRoot.   It must be assumed that all of the CSRoot may be impacted through this CSRelationship to the identified CSComponent, and vice versa.

If this property is not supported, the entire CSRoot is involved in this CSRelationship. There is no further CSDocs information on how much of and in what way the CSRoot is involved in the CSRelationship.

3.3.6 Usage of Tail Content Element Id

If this property is supported, the Tail Rendition Id property must also be supported.

If this property is supported and it has a non-NULL DmaId value, then so does the Tail Rendition Id property and a specific content element of the CSRoot is involved in this CSRelationship.  The Content Element object involved is the one in the identified CSRoot Rendition's dmaProp_ContentElements list property having the matching InstanceId property.  If there is no such Content Element, the CSRelationship has been broken.

If this property is supported, and it has no value (or the value is the NULL DmaId), then the portion of the CSRoot involved in this CSRelationship is not a specific content element.  The participating element of the CSRoot is determined by the rules for Tail Rendition Id.

If this property is not supported, the participating element of the CSRoot is determined by the rules for Tail Rendition Id.

4. New/Changed Interfaces

No changes

5. New/Changed Types, Values, and Macros

CSDocs Foundation introduces the following Values and Macros:

dmaClass_CSRelationship

agreed name for the run-time DmaId constant with value dmaClass_CSRelationshipVal

dmaProp_CSComponents

agreed name for the run-time DmaId constant with value dmaProp_CSComponentsVal

dmaProp_CSRoots

agreed name for the run-time DmaId constant with value dmaProp_CSRootsVal

dmaProp_CSRootStyle

agreed name for the run-time DmaId constant with value dmaProp_CSRootStyleVal

dmaProp_HeadContentElementId

agreed name for the run-time DmaId constant with value dmaProp_HeadContentElementIdVal

dmaProp_HeadRenditionId

agreed name for the run-time DmaId constant with value dmaProp_HeadRenditionIdVal

dmaProp_InstanceId

agreed name for the run-time DmaId constant with value dmaProp_InstanceIdVal

dmaProp_TailContentElementId

agreed name for the run-time DmaId constant with value dmaProp_TailContentElementIdVal

dmaProp_TailRenditionId

agreed name for the run-time DmaId constant with value dmaProp_TailRenditionIdVal

 

dmaClass_CSRelationshipVal

macro for the DmaId-valued identification of the DMA CSRelationship class

 

dmaProp_CSComponentsVal

macro for the DmaId-valued identification of the CSComponents property

dmaProp_CSRootsVal

macro for the DmaId-valued identification of the CSRoots property

dmaProp_CSRootStyleVal

macro for the DmaId-valued identification of the CSRoot Style property

dmaProp_HeadContentElementIdVal

macro for the DmaId-valued identification of the Head Content Element Id property

dmaProp_HeadRenditionIdVal

macro for the DmaId-valued identification of the Head Rendition Id property

dmaProp_InstanceIdVal

macro for the DmaId-valued identification of the Instance Id property

dmaProp_TailContentElementId

macro for the DmaId-valued identification of the Tail Content Element id property

dmaProp_TailRenditionIdVal

macro for the DmaId-valued identification of the Tail Rendition Id property

DMA_CSR_STYLE_COMPLETE

macro for the DmaId-valued setting of the CSRoot Style property that identifies the CSRoot DocVersion as having complete renditions

DMA_CSR_STYLE_INCOMPLETE

macro for the DmaId-valued setting of the CSRoot Style property that identifies the CSRoot DocVersion as having incomplete renditions, with no other information available

DMA_ID_NULL

macro for the value of the NULL DmaId

DMAC_CSD_FOUNDATION

reserved macro name for future indication of CSDocs Foundation support in a dmaProp_DocSpaceCapabilities list.  This value is intentionally not defined at this time.  See section 7, Compliance & Conformance Issues.

6. Architectural Impacts

6.1 Integration Model

No impact

6.2 Query

The CSDocs Foundation has no impact on the DMA Query model. The objects employed in CSDocs structures are as amenable to access via Query as any other persistent DMA objects. No new query operators are introduced to support CSDocs-specific conditions.

The occurrence of CSDocs-related classes in the searchable classes of a document space scope, and the identification of properties as query-able, selectable, and orderable, is determined by the DocSpace implementation, the same as for any other objects usable in queries.

CSDocs-related classes and properties do not introduce any exceptions to the rules for merged scopes.

6.2.1 Implementation Considerations for Query of CSDocs

The CSDocs Foundation introduces new well-known properties (InstanceId and related properties on CSRelationship objects) that have DmaId values. If these properties are supported, it is valuable to also support the query operators dmaQueryOperator_EqualId and dmaQueryOperator_UnequalId for those properties. If joins on CSDocs structures are supported, DMA_JOIN_PARTICIPATION_OPERAND can be set as the value of the dmaProp_JoinParticipation property for the dmaQueryOperator_EqualId dmaClass_QueryOperatorDescription instance.

6.2.2 Interoperability Considerations for Query of CSDocs

Interoperability of operation across different document spaces is enhanced by ensuring that when more than one CSRelationship instance extends between the same CSRoot and CSComponent objects, there is sufficient property and subclassing information to differentiate them by a query. The properties defined by the CSDocs model are not sufficient for all applications of CSDocs.

The use of advertised CSRelationship subclasses for particular structuring mechanisms will allow cross-repository search for compound/structured-document structures of the same kind, when that is important for a specialized requester. By having the parent CSRelationship also be a searchable class, with subclass properties supported, general CSDocs provisions can also be discovered by interoperable requesters.

6.3 Internationalization/Localization

No impact

6.4 Content

The CSDocs Foundation does not alter the DMA Content model. CSDocs does depend on the content model being employed in a way that is consistent with the presence of CSDocs structures and the new ways that content may then be viewed.

6.4.1 Usage Considerations for CSDocs Content

Any DMA 1.0 usable rendition type and organization generally remains usable as renditions of CSComponents without further consideration. Many DMA 1.0 usable rendition types and Rendition subclasses may also remain usable as renditions of CSRoots.

CSRoot DocVersion subclasses that can be created with initial Renditions may be more likely than DMA 1.0 DocVersions to restrict the usable Rendition subclasses. There may be similar constraints on renditions of CSComponents that are usable in a particular (type of) CSDocs structure.

These are all factors that apply in the DMA 1.0 applications of the DMA Content model. CSDocs implementations may have the effect of expanding the incidence of such restrictions.

6.4.2 CSDocs Content Interoperability and Safety

For those CSDocs structures that provide for it, a CSRoot can present complete renditions that are indistinguishable from the renditions that its DMA 1.0 counterpart would create and access. This interoperability does not extend to CSDocs structures that necessarily employ incomplete renditions of forms not safely recognized or modified in DMA 1.0 applications.

6.5 Containment

The CSDocs Foundation does not impact the DMA Containment model. CSDocs is neutral to the containment model.

There are no conditions placed on how the containable CSDocs objects are placed in the same or different containers, or whether they are in containers at all

6.6 Versioning

CSDocs is neutral to the versioning model, and no modifications to DMA 1.0 Versioning is proposed for the CSDocs Foundation.

There are no conditions placed on how the versionable CSDocs objects are placed in the same or different versioning configurations, or whether they are versioned at all.

6.6.1 Using Versioning with CSDocs

Checkout of a CSRoot will produce a working copy that is created from the CSRoot, usually without any associated relationship objects of any kind [DMA 1.0: section 4.2.44.1 IdmaVersionSeries::SetCheckOutNext]. That is, the checkout does not apply to the CSRelationships nor to any of the linked CSComponents of the original CSRoot.

It is understood that the cloning operation that occurs on a checkout operation is not required to replicate any object-valued properties (including enumerations) that have independently-persistent objects as values. There is also no requirement to replicate system-derived properties or elements (e.g., automatically-created special renditions or other features, such as OIID and InstanceId properties). The creation of the CSRoot might spontaneously establish CSRelationship and CSComponent objects the same as when any CSRoot of that kind is created (e.g., per section 1.3.1.2, Backward Compatibility Considerations). The SetCheckOutNext operation takes no actions to preserve or clone any CSRelationship in which the original CSRoot is a participant.

The predictable automatic behavior is essentially the same behavior available if an application were to fabricate the copy without anything to go by but the class description of the given CSRoot instance, with no special knowledge of any semantics of properties and elements of the CSRoot.

The cloning of a dependently-persistent element of a CSRoot is straightforward so long as the IdmaVersionSeries::SetCheckOutNext operation is dealing with objects for which it has complete access to the implementation (i.e., objects implemented by the same Document Space, which is always true under DMA 1.0). The implementation knows which renditions, for example, should be cloned and how. (An exception, for example, might be for system-derived renditions. Appropriate operation may include failing the checkout operation. See section 6.6.2, CSDocs Versioning Interoperability and Safety Considerations.)

Checkout of a CSComponent is subject to the same considerations. The SetCheckOutNext operation takes no actions to preserve or clone any CSRelationship in which the original CSComponent is a participant.

6.6.2 CSDocs Versioning Interoperability and Safety Considerations

DMA 1.0 versioning operations do not affect CSDocs structures. CSRelationship objects of the CSDocs Foundation always bind specific instances of DocVersions. The structure anchored on a specific CSRoot is not impacted by versioning of the CSRoot, any CSComponent, or even a CSRelationship (were that admissible). The creation of new DMA 1.0 versions is simply not noticed in the existing CSDocs Foundation structure having a given CSRoot. This is a straightforward, interoperable behavior.

If the checked-out CSRoot has renditions that cannot be represented without the existence of CSRelationships to components, the ExecuteChange operation to create the clone might fail.

The most-interoperable and safe case is to have SetCheckOutNext operation always produces a DMA 1.0 consistent form of the checked out object, whether or not there are any spontaneously-derived CSRelationships and CSComponents. If it is not possible or not safe to produce such an object from the given one, SetCheckOutNext operation should fail.

It may become desirable to extend the Versioning model by operations that go beyond SetCheckOutNext for the checkout of objects that may be CSRoot DocVersions. No such extension is proposed for the CSDocs Foundation.

6.7 Security

Not applicable

6.8 Naming

Not applicable

6.9 Locking and Transactions

The CSDocs Foundation does not impact the architecture of DMA Locking or the Transaction mechanisms of DMA.

6.9.1 Lock Usage Considerations for CSDocs Structures

For CSDocs, the locking and unlocking of a CSRoot or CSComponent might also require locking and unlocking of other portions of the structures in which the locked DocVersion participates. Any such implicit locking is accomplished silently by the implementation. No special provision is required on the part of requesters.

A CSDocs implementation might refuse to provide locks on CSDocs objects for locks that would otherwise be available.

6.9.2 Lock Implementation Considerations for CSDocs Structures

CSDoc implementations that automatically synchronize the participants in a CSRelationship when any of them change are not required to provide multiple or "deep" (or "high") locking, although they are certainly permitted to do so.

The DMA 1.0 requirement is that no lock be granted for which the necessary invariant cannot be delivered by the implementation.

6.9.3 Interoperability of Locking for CSDocs Structures

The greatest level of interoperability for use of CSDocs structures is by

• providing all forms of locking on DocVersions and Relationship objects
• supporting synchronization and ExecuteChange with DMA_MODIFY_PROTECTED, especially if all forms of locking are not supported on non-read-only objects
• limiting the modification of synchronized participants in a CSRelationship to just one of them

1. allowing modification of elements in the CSRoot only where there will be no inconsistency in any CSComponent as a result (perhaps because of automatic side-effects of CSRoot modifications to components)
2. permitting alteration only at the CSComponent when that is the only way to ensure that the alterations will be synchronized (if at all) in the CSRoots that are impacted.

• Providing consistency checks on alterations of CSRoot and CSComponent objects that reject leaving the CSDocs structure in an inconsistent state following completion of a separate atomic action.  This can require that certain synchronized changes must occur within an IdmaDocSpace::ExecuteBatch operation to be completed.

See also section 13, Backwards Compatibility, and section 15, Failure Modes/Crash Recovery for more considerations in providing a backwards-safe and reliable operation beyond the strict provisions of the CSDocs Foundation.

  7. Compliance & Conformance Issues

This proposal does not require any change to the Conformance section of the DMA Specification, and it does not impact the existing mandatory capabilities provisions [DMA 1.0, Section 4.8, Conformance].

As an optional capability beyond DMA 1.0, there is no change to the DMA 1.0 definition for the DMA Document Space dmaProp_DocSpaceCapabilities property.

For a CSDocs-aware requester, support for the CSDocs Foundation is reflected in the support of dmaClass_CSRelationship subclasses in a DocSpace and in Scope dmaProp_SearchableClassDescriptions lists.  Involvement of an existing DocVersion in a CSDocs structure is revealed by the presence of dmaProp_CSRoots and dmaProp_CSComponents enumerations on the DocVersion.

Whether internal elements of DocVersions can be specifically identified in CSRelationships is a function of the dmaClass_CSRelationship subclass descriptions and support for the dmaProp_InstanceId property on the elements of interest.

It is recommended that the capability-value name DMAC_CSD_FOUNDATION be reserved for any future addition to the dmaProp_DocSpaceCapabilities list.  This capability will be set DMA_TRUE when there are CSRelationship subclasses and there are some DocVersion subclasses that can participate in CSDocs structures as CSRoots and/or CSComponents.

 

8. Sample Usage

[Samples illustrating application of the CSDocs Foundation will be incorporated in a future draft of this CSDocs Foundation proposal.]

9. What Requirement Does This Address?

Supporting compound documents is a DMA user requirement.  It was postponed from the scope of DMA 1.0. It, along with content-based search, had the highest priority for work to be taken once DMA 1.0 was completed.  This recognized the increasing importance of document formats having multiple components and/or having internal structure important to document-management functions. 

The CSDocs subcommittee, in order to reconcile seemingly-incompatible proposals, adopted a set of technical requirements that were used to focus the movement toward an agreed solution.  The following table identifies the adopted technical requirements and the level of satisfaction provided by the CSDocs Foundation.

Note: There are gaps in the numbering for adopted requirements because not all originally-proposed technical requirements were adopted by the CSDocs subcommittee.

10. Why is this a good solution?

The approach provides a relatively simple way of constructing documents from other documents, which seems the most critical element of compound / structured document functionality. It is simple in requiring only one new sub-class (of dmaClass_Relationship), no new interfaces, and a small number of new properties in existing classes.  It employs concepts and mechanisms that already exist in the DMA 1.0 model, rather than introduce any dramatically different interfaces or objects.

The most-significant addition is the reliance on the new dmaProp_InstanceId property as a vehicle for providing a counterpart of reference and navigation to internal, dependently-persistent elements of independently-persistent objects.  This simple valuable provision is generalizable for use throughout DMA.  It provides a single trustworthy mechanism in support of several requirements for compound-structured documents.

Alternatives that were discarded include:

• A special kind of content element that is really a pointer to a complex object structure specialized for representing SGML documents. This was the basic idea in the original Hitachi CSDocs proposal. It was discarded because having an object in the content elements list that does not support the interfaces or properties of DMA 1.0 dmaClass_ContentElement subclasses was felt to be too inconsistent with backwards compatibility.
• Modeling compound documents with containers, with or without adding a rendition property to the container class.  Even though it is common to use containers of various kinds to implement interesting compound structures, it was felt even in the original work on the containment model that implementing compound-structured documents by application of containers was inappropriate.  Applications may (and probably do) employ such approaches, but the CSDocs Foundation does not support that case, and containers operate orthogonally to compound-structured documents as far as the CSDocs Foundation goes.

 

11. Extant Systems with Similar Features and Related Experiences

[The extant systems survey is to be distilled down to the elements related to Compound/structured documents as well as similarities at the Foundation versus beyond-Foundation level. The general survey information is inappropriate in this proposal. Also, the use of an annotated table might be more useful with regard to lining up the feature sets along common axes.]

As part of our background research, we reviewed several repository products that have some form of compound document support. We characterized each product by considering the following areas. The approach to compound/structured documents in each of these systems, and the relationship to provisions of CSDocs, is collected in a separate document, CSDocsExisting.doc (click to open in Word or HTML). The current version of that document should be consulted for all details.

The systems currently surveyed are

• Documentum
• InterLeaf
• Lotus Domino.doc
• FileNET IDM

 

[We should add the Hitachi DocBroker to this list, since it establishes the compound/structured-document model for the Digital Library Project in Japan.]

12. Impact on Existing Systems

[The impact on legacy systems of the basic requirements need to be assessed here, along with the conditions for being able to express legacy compound and structured documents features through the CSDocs Foundation.]

Edit this. We need to consider DMA 1.0 as a legacy impacted by these extensions.: This proposal will allow repositories that allow construction of documents from other documents to expose this capability through DMA.

13. Backwards Compatibility

CSDocs extensions are introduced entirely by additions to the DMA 1.0 model. There is no change to anything already in DMA 1.0. The CSDocs Foundation employs mechanisms that are already provided and allowed for under DMA 1.0.  (See Section 1.2, Approach.)

The CSDoc Foundation does not impact any DMA implementations that deliver DMA 1.0-compliant services, as defined in the DMA 1.0 Specification section on Conformance [DMA1.0].

No Automatic Upward Compatibility.  DMA requesters designed for operation with DMA 1.0-compliant services are not automatically able to exercise all functions of a CSDocs implementation (section 1.3.1.2, Backward Compatibility Considerations).  The use of CSRelationship objects and related properties introduced in the CSDocs Foundation will be encountered as if there have been private extensions and introduction of properties.  There is no automatic mechanism by which a DMA 1.0 client can determine the proper usage of private extensions:

• DMA metadata information and property information on objects will make it apparent when objects that involve extensions have been encountered.  Using the principles of DMA 1.0 alone, the client can be designed to confine operation with such objects to those actions that are predictable under DMA 1.0.
• Exploration of the properties and relationship objects is further possible under the guidance of a human operator having access to descriptive information (e.g., in documentation and metadata).
• Creation and modification of CSDocs structures is unlikely to be successful without resort to external information possessed by a human operator.

DMA requesters designed for operation with CSDocs structures can access and navigate a CSDocs organization more successfully:

• exploration of the CSDocs Foundation properties and relationship objects can be carried out by automatic means provided in the implementation of the requester.
• Specific conditions on the relationship between information of components and information of compounds, and how to derive renditions of compounds, requires additional information that is not specified by the CSDocs Foundation. The CSDocs Foundation does not establish a predictable interpretation of a CSDocs structure.
• Creation and modification of CSDocs structures is not assured to be successful without resort to external information about conditions required to be satisfied by a given CSDocs implementation.  CSDocs is intentionally underspecified in this area.

In this CSDocs Foundation specification, some practices are suggested for safeguarding against damage to CSDocs structures by DMA 1.0 requesters and CSDocs requesters designed around different interpretations of the CSDocs structures. (See, for example, section 1.3.1.1, Interoperability Considerations and section 6.9.3 Interoperability of Locking for CSDocs Structures.)

14. Performance Impact

The creation of CSDocs structures has roughly the same cost as creation of DMA 1.0 Containment structures.   There are additional costs related to the mechanical or human-guided effort to populate the CSRoot with correct information derived from the CSComponents.

Depending on the intended interpretation of a family of CSDocs structures, there will be additional costs related to the derivation of any external forms and presentations of the overall compound/structured-document. 

These are generally all additional costs that arise in any use of simpler structures to represent more complex, extensive arrangements of document information.  CSDocs Foundation supports introduction of these complex structures using a single framework.   There is no particular performance optimization available through use of CSDocs that is not available to any private extensions or usage conventions for the same purpose.

15. Failure Modes/Crash Recovery

CSDocs structures, like DMA 1.0 containment and versioning structures, are vulnerable to failures in which the different objects become inconsistent and portions of the structure are damaged, missing, or disconnected.  CSDocs structures have a higher exposure to these kinds of failures because the entire structure must generally be constructed and maintained atomically.  In particular, the CSRoot must be kept consistent with all of its CSComponents (and vice versa) at all times.

Applications can employ referential integrity and atomicity provisions (locking and use of IdmaDocSpace::ExecuteBatch) to minimize structural inconsistency.  To increase the maintenance of referential integrity and structural consistency under deletion, a related proposal has been created for defining the strength of relationships, including ones established with CSRelationship objects  [RelStrength].

An additional source of structural failure in CSDocs structures involves identification of specific elements in a CS Relationship (section 1.3.3, Identifying Specific Elements in a CSRelationship).  These identifications rely on matching InstanceId values of the elements with DmaId-valued properties in the CS Relationship object (section 3.3, New CSRelationship Class).  The integrity of the relationship and correctness of Head and Tail properties might be preserved even when the identification of specific elements is incorrect and the element cannot be found.   Requesters that navigate CSRelationships to specific elements have no assurance that the element will be found, even though the integrity of the connection to the independently-persistent object at dmaProp_Head or dmaProp_Tail is preserved.

It is also possible to experience race conditions in access to and navigation of a CSDocs structure while changes are occurring to some or all of the structure.   Requesters will experience failures in those cases, and inconsistent results can be produced, unless the portions to be visited are successfully locked in a consistent state before the information in the structure is employed.  This will not prevent encounter of inconsistencies that are already present in the structure.

Protection against semantic inconsistency of the information in a CSDocs structure is not specified in the CSDocs Foundation: semantic consistency is not part of the CSDocs model.  (See also section 13, Backwards Compatibility.)

16. How Is This Incorporated into the Specification?

It is proposed to keep the CSDocs extensions separate from the official DMA 1.0 specification.  The CSDocs extensions are to be kept as supplemental documents for confirmation and testing via trial use.

Once stable practices around CSDocs extensions are established, the incorporation in a future specification, or DMA 1.0 supplement, will be addressed.

17. How Is This Incorporated into the Code and Library Configurations?

The new property Id, class Id, and enumeration-value definitions will be incorporated into a separate DMACSDOC.H for specific inclusion during the trial use period.  (See section 5, New/Changed Types, Values, and Macros.)

The different DmaId values introduced by CSDocs extensions are not automatically supplied via DMAIDVAR.H.  The separate file DMACSVAR.H operates under the same model and is used to provide shared storage for these values.

Th CSDocs library files  will be structured so that, whenever CSDocs extensions are incorporated as part of the DMA baseline reference interfaces, programs will compile properly whether they use separate (current) DMACSDOC.H and DMACSVAR.H files or not.   Programs that build the run-time constants for DMAIDVAR.H will always have to request the run-time constants for DMACSVAR.H separately when desired. 

Defined Values for CSDocs Foundation:

dmaClass_CSRelationship

dmaProp_CSComponents
dmaProp_CSRoots
dmaProp_CSRootStyle
dmaProp_HeadContentElementId
dmaProp_HeadRenditionId
dmaProp_InstanceId
dmaProp_TailContentElementId
dmaProp_TailRenditionId

dmaClass_CSRelationshipVal

dmaProp_CSComponentsVal
dmaProp_CSRootsVal
dmaProp_CSRootStyleVal
dmaProp_HeadContentElementIdVal
dmaProp_HeadRenditionIdVal
dmaProp_InstanceIdVal
dmaProp_TailContentElementId
dmaProp_TailRenditionIdVal

DMA_CSR_STYLE_COMPLETE
DMA_CSR_STYLE_INCOMPLETE
DMA_ID_NULL

DMAC_CSD_FOUNDATION

reserved name for introduction of CSDocs Foundation support in some future revision of the dmaProp_DocSpaceCapabilities list.  This macro is not to be defined while CSDocs extensions are in trial usage and not adopted as parts of a baseline DMA specification.

18. Reference Materials

18.1 Normative Specifications

[DCE RPC]

DCE 1.1: Remote Procedure Call.  Open Group Technical Standard.  Document Number C706.   The Open Group (Reading, UK: August, 1997).   737pp.  Electronic edition, $58.00.  HTML edition available on-line.  UUIDs are specified in an Appendix.  Registration is required to access the on-line material.

[DMA1.0]

DMA 1.0 Specification.  AIIM Document Management Alliance.  AIIM International (Silver Spring, MD: 1995, 1996, 1997).  Approved for general use on December 24, 1997.  Corrected version of October 9, 1998 published on the web at http://www.aiim.org/dma/dma10/index.htm.

18.2 Informative References

[CBSearch]

Proposal for Content-Based Search

[RelStrength]

Proposal on Relationship Strength.

[StableCursor]

Proposal for Stable Cursor on Enumerations and Result Sets

[VCE]

Proposal on Virtual Content Elements.

18.3 Background Materials

[CSketch]

Compound-Structured Document Sketch

Edit these with stronger references to sources:

Original Hitachi Proposal

FileNET proposals

Cousins proposal

Documentum Server Reference Manual

Black Forest Group requirements document (April 1999?)

Original DMA Requirements Statement?

Original Statement of Work and Proposal for the Subcommittee

Requirements Documents adopted by the Subcommittee

 

---

Contributors

Mitsuru Akizawa, CSDocs subcommittee member, Hitachi, Ltd.

Alan Babich, CSDocs subcommittee member, FileNET Corporation

Steve Cousins, CSDocs contributor and reviewer, Xerox Corporation

Chuck Fay, CSDocs subcommittee member, FileNET Corporation

Jim Green, CSDocs subcommittee member, FileNET Corporation

Dennis E. Hamilton, CSDocs subcommittee member, InfoNuovo

Katsumi Kanasaki, CSDocs subcommittee member, Ricoh Company, Ltd.

Yoshifumi Sato, CSDocs subcommittee member, Hitachi, Ltd.

Richard Sauvain, CSDocs subcommittee chair, Xerox Corporation

Michael Seaman, CSDocs contributor and reviewer, FileNET Corporation

Change History

Version 0.03, 1999 December 2, Dennis E. Hamilton 

• Adjusted presentation and template styles to avoid unusual bullet characters
• Changed to HTML as the maintainable form and organized to be easily poured into a Word document with appropriate template.
• Reorganized outline to move change history to the back and add acknowledgment of all contributors.  Edited the change history so that cross references to sections apply to the present renumbered sections.
• Corrected cross-references impacted by reorganization, and added text and hyperlinks to let the reader more easily determine the targets of cross references.
• Tightened section 6.6 (Versioning) slightly and affirmed standard SetCheckOutNext behavior.  Reference to any IdmaVersionSeries2 extension is omitted until a worked proposal becomes available.
• Tightened and clarified section 6.9.3 (Interoperability of Locking for CSDocs Structures), tying to backward safety and also protection against damaged structures by limiting operations of requesters and additional integrity mechanisms.
• Added new sections 5 (New/Changed Types, Values, and Macros), 7 (Compliance &  Conformance Issues), 9 (What Requirements Does This Address), 10 (Why Is This a Good Solution), 13 (Backwards Compatibility), 14 (Performance Impact), 15 (Failure Modes/Crash Recovery), 16 (How Is This Incorporated into the Specification), and 17 (How Is This Incorporated into the Code and Library Configurations)
• Reserved DMAC_CSD_FOUNDATION for any future addition to capabilities, without specifying its inclusion at this point, based on
• Added cross-references to the work on Content-Based Search [CBSearch], Relationship Strength [RelStrength], Stable Cursors [StableCursor], and Virtual Content Elements [VCE].
• Ran the FrontPage spell checker.

Version 0.02, 1999 August 31, Dennis E. Hamilton

• Apply editorial corrections collected during the 99-08-31 CSDocs conference call.
• Streamline the definitions of Rendition Id and Content Element Id properties of the CSRelationship object.
• Update the companion class-description HTML files to align with this version. Include reflective property as a column in the property-description tables.

Version 0.01, 1999 August 31, Dennis E. Hamilton

• Improve section 1.3.1.1 to not make subclassing of CSRelationship a requirement and motivate value of always making implementation-specific CSRelationship subclasses.
• Improve section 1.3.1.2 item (6) to be clear what the limitation is.
• Participating Element added to the glossary. Structured Document cleaned up in the glossary. NULL DmaId added to the glossary (and it should be added to the overall DMA glossary).
• Nomenclature of titles in section 3.3.3-3.3.6 changed to avoid ambiguity of "Usage" as part of a property name. The descriptions are reorganized to present the positive case first.
• Page footers with page numbers added to the document.
• A number of editorial corrections provided by Richard Sauvain on 1999-08-16 have been incorporated.

Version 0.00, 1999 July 28, Dennis E. Hamilton

• Initial Foundation draft, incorporating back matter contributions of Richard Sauvain, CSDocs Foundation as described in the current CSDocs sketch, and draft material previously created by Alan Babich. Detailed information on extant systems with related features (section 11) is moved to a separate document, with only a brief summary here.

---

$$Author: Admin $
$$Date: 03-03-03 15:30 $
$$Revision: 20 $

End of Document