- From: Judith Slein <slein@wrc.xerox.com>
- Date: Fri, 8 Nov 1996 15:04:05 PST
- To: w3c-dist-auth@w3.org
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