Document Management Alliance (DMA)

Overview DMA is a coalition of users and developers of document management system software. Goal of the coalition: to improve interoperability between DMS products. Towards this, DMA developed DMA 1.0, a standard API for document management.

Background DMA is a task force comprised of members of AIIM (Association for Information and Image Mgmt), a consortium of document management people. Began by synthesizing 2 earlier DM standards: DEN and Shamrock. Very much rooted in a workflow management problem space.

Some Members of DMA Hitachi Xerox FileNET Ricoh

Related Projects ODMA (Open Document Management API) –Allows many-to-many relations between client apps and DMS servers. –But the client does all the work: must know everything about the server. –ODMA is very lean, but doesn’t do a lot.

Related Projects WebDAV (Web Distributed Authoring and Versioning) –Allows multiple authors to work on a single document (web page) via extensions to HTTP. –Developed in conjunction with DMA

Chronology April 1995: AIIM DMA Task force created Nov. 1995: DEM/Shamrock combined, scope of DMA 1.0 specified. Sept. 1996: DMA.75 published. Feb. 1997: DMA.9 published. Nov. 1997: DMA 1.0 published. Dec. 1997: DMA 1.0 approved by DMA committees. (source

Motivation The DMA 1.0 specification offers 5 goals for the standard: –Uniform access to any doc, anywhere in an enterprise (transparent access to docs across DM systems) –Self-describing systems and docs (run-time discovery of system/document properties) –Scalable doc management (useful under a variety of DM scenarios) –Easy collaboration (islands of information problem…using networks for documents) –High-level integration of services/applications (integrate workflow functionality with DM functionality) (

The Concept The spec authors liken a DMA system to a library system (think of UNC’s libraries) Like a library, DMA provides well-defined methods for storing and finding its information. Other similarities…

The Concept Library system contains multiple libraries. DMA system contains multiple “document spaces.” A document space is like a single library/collection. Like a library’s card catalog, the document space has a description of its available resources and services. DMA also provides high-level searching across document spaces.

The Concept An item is the basic unit in libraries, for DMA, we trade in document version objects. Just as a library might have the same title in several formats (book, audio), document version objects can have multiple document rendition objects (html, pdf)

The Concept Library materials have attributes (format, date, author). DMA documents’ attributes are called property values.

The Concept Analogous to circulating books, DMA tracks document management state information for each item. i.e DMA allows users to check documents out/in in order to permit collaboration and versioning.

Analysis The DMA architecture is composed of 3 parts: –Client Applications (e.g. authoring) –DMA middleware –DMA service providers (DMS servers)

desktop Document Repositories DMA API DMA Middleware Other client applications Mapping to DMA DMA client application DMA API Document Management Services

DMA Object Model The DMA object model abstracts data and services to provide high-level access to documents. Insulates clients from implementation; allows cross-platform interfacing. A DMA class is a definition for a set of objects having the same supported methods and properties.

DMA Object Hierarchy DMA Document Author: “Miles” Title: “DMA” ClassDescription: ClassDescription Describes: Document Properties: ClassDescription: ClassDescription Describes:ClassDesc. Properties: ClassDesc: NULL Properties, String Property: Author Type: String Cardinality: Single Properties, String Property: Title Type: String Cardinality: Single Properties, Object Property: ClassDesc Type: Object Cardinality: Single Properties, Object Property: Prop Descs. Type: Object Cardinality: List Properties, ID Property: Class desc’d Type: ID Cardinality: Single Properties, Object Property: Class Desc Type: Object Cardinality: Single ListofObject Count: 3 Elements 0, 1, 2, 3 ListofObject Count: 3 Elements 0, 1, 2, 3

Using DMA Classes It’s all about Properties Objects expose their state via GetProp methods Objects can be manipulated via PutProp methods Properties may be standard datatypes (int, string, etc.) or object-valued

Property Metadata Each class stores a list of its properties. Actually…stores an object of type ClassDescription, which stores an ordered list of PropertyDescription objects for its parent class. So any DMA-compliant application can find out about an object

What does this enable? Metadata Spaces: Developers can define domains where given class relationships hold. But searching, editing, viewing can still go on between spaces. Concurrency Control: DMA supports locking for robust versioning, etc. Extensibility: Developers can extend the functionality of DMA-enabled software.

DMA’s Strengths Benefit for large, complex projects that use DMA-compliant document management software is big: –Collaboration –Integration with workflow software –Integration across document management applications

DMA’s Strengths Benefits for Digital Libraries: –A document model that accommodates complex documents. i.e. Versions, renditions, multi-part docs. –Detailed administrative metadata capabilities. i.e. access privileges can be coordinated at a very fine level.

DMA’s Weaknesses DM software vendors have no incentive to comply…it’s unclear how fully they have done so. Integration into distributed-object system (DCOM or CORBA) not demonstrated. Security model limited to authentication interface. No authorization mechanism and no administration in the model. There are no commercial, fully-compliant products that can be assessed and with which interoperability can be verified.