- From: Yaron Goland <yarong@microsoft.com>
- Date: Thu, 9 Jan 1997 17:53:51 -0800
- To: "'w3c-dist-auth@w3.org'" <w3c-dist-auth@www10.w3.org>, "'Judith Slein'" <slein@wrc.xerox.com>
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