RE: DMA 1.0 as It Relates to the Draft webdav Specification

My comments as a DMA TC member.  Surprising that someone who hasn't
participated in the TC has this good an understanding of the model.

Bernard Chester
Saros / FileNet
bernardc@saros.com

>----------
>From: 	Judith Slein[SMTP:slein@wrc.xerox.com]
>Sent: 	Friday, November 08, 1996 3:04 PM
>To: 	Pat Allain; Bernard Chester; Eric Edeen; Bob Kennewick; Corprew
>Reed
>Subject: 	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. 

Else we could not have metadata to permit us to specify valid searches
and permit consolidating 
information across collections.  Properties may all be optional, or some
may be required.

>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. 

More properly, the metadata is available for any class or instance.
>
>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
Not true -- there is a core, only that to eliminate prejudicing any
implementation, its just the properties needed to 
make the model work.

>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. 

There is the vision of a set of well-known (i.e., agreed upon
definitions and assigned GUIDs)
properties, which eliminates the needs for aliasing.

>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. 

Not so! With DCE GUIDs there is no petitioning.  The user /vendor may
assign aliases to 
indicate knowledge / desire to equivalence properties in 2 systems.

>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 
or stream or reference
>					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, 

You can get there, but remember, Renditions are atomic formats.  You
don't
subdivide a GIF or a JPEG.  Instead, this is designed to handle things
like a graphic
which is available in GIF, JPEG, and PNG.  What you are asking for we
see as
a compound document.
>						for documents that reference
>content rather than containing it directly, 
No, this is defined and permitted.
>					for any more complicated
>structure than a simple sequence of files, or for components of
>renditions
>that are not files. 
Sorry, you've mis-read this.

>Neither renditions nor transfer elements can be versioned. The most
>basic
>object that can be versioned is the Document Version. 
In the basic model.  May be provided by extension, using existing
mechanisms.
>                                                                       
>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. 
Locking is an issue for synchronization of object property views, not
modification.
We distinguish between property sets, which all objects have, and
content, which a 
few objects have.

>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. 
Because versionable objects are the only ones with content; all objects
have properties.
>
>Issues for webdav: 
>
>Do we want to reconsider our lock types? Is an existence lock useful
>for us? 
Don't you care that the references in a page stay valid during an
editing session?  Wouldn;t
you want to prevent them from being deleted from under you?
>What sorts of objects should be lockable: Attributes? Containers?
>Versions?
>Version Series? . . . 
I don't see the concept of a version series in your current document.
>
>Versioning 
>
>DMA 1.0 supports only linear versioning. 
I think that you'll find that the model supports branched and threaded
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. 
Excuse me, but I don't see how you came to this conclusion.  Would you
explain?
>
>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. 
This is not correct.  The Versionable Class is the parent class (in
inheritance) of
the DocVer. 
>
>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. 
No, it doesn't put a write lock (unless the implementation requires it).
 It designates
an intent to modify.  Potentially, others could also indicate that
intent, and work in parallel
or to generate a branch.
>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". 
I don't believe it removes all reservations.  It shouldn't
>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.
This most closely matches directory hierarchies in a file system.  No
loops!
> 
>     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. 
Links and Shortcuts and references.

>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? 
How will you prevent them?
>   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 Monday, 11 November 1996 22:24:41 UTC