(no subject)

The following questions were submitted by Judith Slein when she wrote up
a summary of DMA features as they relate to WebDAV. I have included the
original post below. I would like to thank Judith for taking the time to
write out this posting and to apologize for having taken so long to
respond.

Please note that unless specifically stated otherwise all opinions are
my own. When I refer to the opinions of the "authors" I am referring to
decisions reached at the last author's conference. This was a closed
meeting of the draft authors. These decisions are in no way binding upon
the group and strictly reflect the opinion of the authors and the shape
of the draft to be submitted at the end of January. Only the technical
committee, which is meeting at the end of January at UCI, can be
considered a proper polling point for determining consensus.

   1.Do we want to define / reference core sets of attributes or not? 

Absolutely not. We will be defining some attributes but those are only
attributes related to DAV, not documents.

   2.Do we want a mechanism for mapping semantically equivalent
attributes
to each other? 

The design that is currently favored by the authors uses a token to
identify the type of a link. This token is just some series of
characters. Thus it is possible to perform the mapping. Though a spec to
deal w/this should be written up separately.

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

We do provide a discovery mechanism to determine what link types are
supported on a particular URL or on an entire server. As for the
properties of attributes, that is beyond what we are defining in WebDAV.

   1.What sorts of objects can be versioned? 

Anything that can be referred to w/a URI can be, subject to the server's
approval, versioned.

   2.Do we want to support attributes that do not attach to any content
that
is available online? 

I am not sure what this means. In the current spec attributes are
implemented using Links and links must have a source URI and a
destination URI.

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

[Note: DMA supports read, write, and exists locks.] After much
discussion and debate the author's have decided that they will propose
that only a write lock w/partial lock capability will be presented to
the technical group. We came to this decision after examining the
different lock types and realizing that no one at the table had any
serious intention of implementing anything but write lock. Of course
this decision is just our opinion and holds no weight unless it is
approved by the technical committee.

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

The author's consensus is that anything that can be referred to w/a URI
can be locked.

   1.If we decide to specify only linear versioning now, can we
architect to allow for more complicated configurations later? 

The consensus of the technical group was that we must supporting
branching and merging. So the issue is mute.

   2.What kinds of things can be versioned? 

As always, anything w/a URI.

   1.We have assumed referential containment so far. Do we need a notion
of direct containment? 

Such a notion is currently being created using File System Collections
(FSC). In this case direct containment is implicit. When an object is
created in a specified name space the FSC object for that namespace will
"magically" include the new document. We also have a "non-magic"
mechanism called URI Collections but they do not support the concept of
direct containment. This because direct containment (which is defined as
a situation where a document is contained in at most one collection)
does not map well to HTTP where URIs can show up anywhere.

   2.Do we want to allow cycles in our containment model? 

As we do not specify server to server relationships we have no choice
but to allow them. To disallow them would eventually cause us to deal
w/the case where a collection on one server contains a reference to a
container on another server which itself refers back to the first
server.

   3.Do we want a ContainmentRelationship object? 

The authors have already decided to create such an object in the person
of a collection.

   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?

We have and do.

			Yaron

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 Thursday, 9 January 1997 20:54:18 UTC