DMA 1.0 as It Relates to the Draft webdav Specification

I intended to get this reviewed by someone on the DMA technical committee
before distributing it. But it has taken me so long to finish this draft
that I decided to send it out now and count on the DMA TC members who watch
this list to correct my mistakes.

So here's my cut at the relevant parts of the DMA 1.0 spec:

In DMA 1.0 the Document Version is the primary class of objects managed by
document repositories. It is expected that users will derive classes from
this one, for the sorts of documents they care about (memos, annual reports,
etc.). Repositories can also manage other sorts of objects, such as containers. 

Attributes 

For each class of object a repository manages, it keeps a list of the
properties (read: attributes) that may attach to objects of that class. So
it is not possible to attach any arbitrary property to an object: an object
can have only those properties that are valid for its class in the
repository where it resides. 

Each managed object is also capable of responding to queries about what
properties (read: attributes) it has, what class it belongs to, and what its
parent and child classes are. 

A property has metadata of its own, and defining a property involves setting
values for its metadata: type, size, is list, display name,
descriptive text, property supported, searchable, selectable, query term
description list, order by list, default value, min/max, valid values. 

DMA does not attempt to define a core set of properties for documents. A key
part of DMA's functionality, however, is its ability to coordinate queries
across repositories with differing property sets. In order to do this, it
does provide mechanisms for mapping semantically equivalent properties to
common GUIDs. Although the common GUIDs are administered by DMA,
responsibility for setting appropriate mappings lies with system
administrators. 

Each property has two GUIDs: the local GUID (meaningful only in the context
of a given repository), and the alias GUID. It is the alias GUID that
normalizes references to a property made from a context where the local GUID
may be meaningless (across repositories, for example). The GUID for an alias
is provided by DMA after approval of a petition from the vendor originating
the local GUID. The resulting Alias Property GUID would then ensure that the
property is identified across disparate repositories (implemented by
different vendors). 

Operations that make sense in the DMA world are getting / setting property
values, asking what properties a repository allows to be attached to a given
class of object, asking what properties a given object actually has, getting
/ setting values for metadata of properties, searching for documents based
on property values. 

Issues for webdav: 

   1.Do we want to define / reference core sets of attributes or not? 
   2.Do we want a mechanism for mapping semantically equivalent attributes
to each other? 
   3.Do we want to support some of the document management operations, like
finding out what attributes can legitimately attach to a resource, finding
out the properties of attributes, etc.? 

Documents 

A DMA Document Version consists of properties and (optionally) content. 

If the Document Version has content, it exist in the form of one or more
Renditions (read: variants), each in a different format and each
representing the entire content of the Document Version. Renditions cannot
persist outside a Document Version. Each Rendition is a sequence of Transfer
Elements, each representing a file that is a component of the Rendition.
Transfer Elements cannot persist except within Renditions. 

In DMA 1.0 only relatively simple documents are considered. There is no
provision for Renditions whose content is in a mix of formats, for multiple
Renditions of individual Transfer Elements, for documents that reference
content rather than containing it directly, for any more complicated
structure than a simple sequence of files, or for components of renditions
that are not files. 

Neither renditions nor transfer elements can be versioned. The most basic
object that can be versioned is the Document Version. 
                                                                       
Issues for webdav: 

   1.What sorts of objects can be versioned? 
   2.Do we want to support attributes that do not attach to any content that
is available online? 

Locking 

The Lock method belongs to the Connection interface, and so lasts only
during a session. The types of locks that are supported are:

     Read Lock: Prevents any other connection from putting a write lock on
the object 
     Write Lock: Prevents any other connection from putting a read lock or a
write lock on the object 
     Exist Lock: Prevents anyone from deleting the object, no matter what
kind of lock he holds. Can coexist with other locks. 

There is no requirement that an object be locked in order to be modified. 

All sorts of objects can be locked: Configuration History, Version Series,
Version Description, Document Version, Container 

Locks that persist across session boundaries can only be obtained by
checking out or reserving versionable objects (see below).
The set of versionable objects is much smaller than the set of objects that
can be locked within a session. 

Issues for webdav: 

Do we want to reconsider our lock types? Is an existence lock useful for us? 

What sorts of objects should be lockable: Attributes? Containers? Versions?
Version Series? . . . 

Versioning 

DMA 1.0 supports only linear versioning. The different versions of a
document are maintained as a series of individual document versions. Each
presents a state of the document at some point. There is at most one current
version, which represents the current state of the conceptual entity. In
this view, the versions constitute a possibly-incomplete history of states
of the conceptual entity. 

The classes and interfaces that support versioning have been carefully
designed to allow extension to configuration-management of document
organizations, including branched versioning. The design allows for
different configurations of the same objects for different purposes. For
example, there might be a special version series of only official releases
of a publication, and other version series might include intermediate
internal revisions and proposals. Alternatively, the same object might
appear more than once in a single version series that represents the stages
of a workflow that the object is taken through, and the various reviews,
approvals and transmittals in the series might all refer to the same object. 

In the DMA 1.0 specification only Document Version objects are versionable,
but the concepts can be generalized to allow versioning of additional
objects in the future. The addition of application-specific versionable
objects via subclassing is available immediately. 

The DMA 1.0 specification does not require that Document Spaces support
versioning, it merely specifies how versioning is expressed for those
Document Spaces which do support versioning. 

The following classes embody versioning in DMA 1.0: 
                                                                              
     The Configuration History is the top-level object that "holds" the
configuration of versions. It provides a unique entry into the overall
configuration. The entire configuration can be navigated via entry at the
Configuration History object. 

     The Version Series carries the configuration of a single "line" of
versions that are viewed as generally having a progressive history. There is
a Primary Version Series representing the top-level version sequence of the
configuration. In linear versioning, there is exactly one Version Series. In
more complex configurations, additional Version Series are used to provide
branches and subordinate configuration progressions beneath the Primary
Version Series.
 
     The Version Description is the connection from a place in a Version
Series to a particular versionable object. In the DMA model, there is
specific allowance for the possibility that a versionable object might exist
as a constituent of more than one Configuration History, or might occur in
the same Configuration History in more than one way. Because a versionable
object may potentially occur in configurations in more than one way, the
data that is specific to each occurrence is kept separate
from the versionable object in a Version Description object. For example,
the Version Description subclass used will usually provide a label e.g.,
("5" or "2" or "C" or "draft 5" or "final") by which the object is known
relative to the containing series. In addition, there may be information
about the authority under which the Version Description was added and when
it was done. The Version Description can be subclassed to add more
version-related application information.
 
     The Versionable Object is some instance of an object (e.g., a Document
Version object) that represents the conceptual entity at a particular point. 

One Version Description is flagged as current, and the Version Series knows
which it is. A checkin always sets current to point to the new version, but
it is possible to change the value of current, so that a version other than
the newest can be checked out. ReserveNext and CheckOutNext always operate
on the current Version Description. The system creates a Version Description
and assigns it to Reservation when checkout or reservation operations are
invoked. 

When a Document Version is checked out (or reserved), a new Version
Description is created and its ReservedFor property is set to the version
Series of which it will become a part; when the Document Version is checked
in, ReservedFor becomes null and the VersionSeries property is set to the
Version Series to which the Document Version now belongs. The
IsCurrentVersion property tells whether this Version Description is the
current one for its Version Series. The Version property is the Versionable
Object corresponding to this Version Description. In addition, the DMA
Version Description provides for one or more branches being taken from that
point in a series. For future releases of DMA, the DMA Version Description
also provides for one or more Version Series branching from or merging into
the current series at the Version Description point. 

Operations related to versioning: 

Checkout: Creates a new copy of the "current" Version Description and its
Versionable Object, and reserves the right to check in the next version of
the version series. The Reservation attaches to the Version Series, so that
only one reservation can be made against the version series at a time.
Checkout always operates on the Version Description / Versionable Object
that are flagged as "current". This is normally the tip version, since
Checkin always creates a new tip version and always flags it "current". It
is, however, possible to flag any version as "current". 

Reserve: The same as Checkout except that it does not copy the Versionable
Object. 

Effectively, a checkout or reservation puts a write lock on the version
series that persists across sessions until it is revoked
or a new version is checked in. 

Revoke: Cancels a checkout or reservation. 

Checkin: Adds the new version to the version series, releases all
reservations, and flags the new version as "current". 

A version topology is obtained by navigating the Configuration History, its
Version Series, and Version Descriptions. 

Information about a reservation can be obtained by examining the properties
of the Reservation object on a Version Series. 

Issues for webdav: 

   1.If we decide to specify only linear versioning now, can we architect to
allow for more complicated configurations later? 
   2.What kinds of things can be versioned? 

Containment 

Two types of containment are defined: 

     Direct containment. This models a 1:N relationship. A containing object
may contain multiple objects, but an object is directly contained within at
most one containing object. A containing object that directly contains
another object is called the parent of that object. An object that is
directly contained within a containing object is called a child of that
containing object. Direct containment defines a strict hierarchy of objects
with no cycles. DMA does not limit the depth of the direct containment
hierarchy, but a document space may choose to impose a limit.
 
     Referential containment. This models an N:M relationship. Objects that
are referentially contained within a containing object are referred to as
containees. A containing object that referentially contains another object
is referred to as a container of that object. A container may contain
multiple containees. A containee may be contained within multiple
containers. Cycles in referential containment relationships are not
disallowed by DMA. 

The relationship between a container and a contained object is modeled
explicitly in DMA with the introduction of a third object, the
ContainmentRelationship object. This object provides a home for "edge data",
data which can be thought of as belonging to the edge between two vertices,
the container object and the contained object. Edge data can include both
user- and system-defined properties that describe the relationship between
the container and the contained object. For example, the relationship of a
folder and a document contained in that folder (Figure 2) could have
properties such as: 

filer (who filed this document in this folder?), and 

filing date (when was this document filed in this folder?). 
                                              
These properties logically belong to the relationship between the container
and contained object, rather than to either of the related
objects alone. In referential containment, neither the container nor
contained object is a good home for these properties, as the container may
have many contained objects, and an object may be referentially contained in
many containers. 

The current DMA containment model is intended to be sufficiently general and
expressive to allow DMA providers to support a number of specialized
containment metaphors, such as libraries, electronic file cabinets,
electronic file drawers, folders, and so on. 

Operations related to containment: 

Updating containers to insert and remove children and containees. 

Navigating containment hierarchies. This is accomplished through traversal
of properties using the IdmaProperties interface. 

Expressing queries that include containment properties. Using the standard
DMA query mechanism, it is possible to include the properties of containers
in queries. For example, we could search for all documents filed by
reference having the value three for their "age" property, that are
contained in containers (e.g., folders) having the property "color" equal to
blue. We could retrieve the "name" properties of these documents and also
the "filer" properties, telling us who entered them into their folders. 

Issues for webdav: 

   1.We have assumed referential containment so far. Do we need a notion of
direct containment? 
   2.Do we want to allow cycles in our containment model? 
   3.Do we want a ContainmentRelationship object? 
   4.Can our model support queries like the one above? Can we constrain a
search to find only documents in a given container or set of containers?

--Judy
 

Name:		Judith A. Slein
E-Mail:		slein@wrc.xerox.com
Phone:  	8*222-5169
Fax:		(716) 265-7133
MailStop:	128-29E

Received on Friday, 8 November 1996 18:02:27 UTC