Open Document Management API

Item

1.1¶2 on case insensitivity of Document IDs

The case insensitivity of Document IDs has implications on the use of DMS IDs in registry entries and on the formatting of other DocId information that might also appear in registries, profile files, and other material.  There is no assurance that two separate occurrences of a DMS ID, for example, will be in the same single case.  Software that examines and compares DMS IDs should take this into account.

1.1¶3 on DMS IDs

The statement "The ODMA group members will coordinate these IDs to ensure their uniqueness." is inaccurate.  There is no formal coordination mechanism and there is no longer an "ODMA group."  The new AIIM DMware clearinghouse will provide a registry for ODMA DMS IDs.  Contribution of already-used DMS IDs and reservations of DMS IDs is and will continue to be entirely voluntary.

<condition> :: <attribute> <op> ‘<attribute_value>’

and the ‘<attribute_value>’ element should be deleted from the front of the <attribute> rule.

0 1 2 3 4 5 6 7 8 9
a b c d e f g h i j k l m n o p q r s t u v w x y z
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
= < ! > ( ) ' _ ‘ ’ + - : \ , / .
and at least the space character

including characters required for attribute values that are ODMA Document IDs, date-time values, format names, and lists of keywords.  This is another condition requiring consistent availability of a simple character set that is translatable among all acceptable code pages.

The description of lpszDocId in many of the sections overlooks the fact that the parameter is a pointer to the first byte of a document ID.  It is *lpszDocId (better yet, lpszDocId[]) that carries the document ID.  Accomplished C/C++ programmers will completely overlook this careless language, automatically understanding what is meant.  People who do not use C/C++ and who want to understand these interfaces are supported by more rigorous ways of speaking.  It is recommended that the use of a pointer and the use of pointed-to material always be clearly differentiated.

Definitions such as

lpszDocId - in - 

A null-terminated document ID. This is typically obtained by a call to ODMSelectDoc, ODMSelectDocEx or ODMNewDoc. 

are perhaps better expressed as 

lpszDocId - in - 

Pointer to the beginning of a null-terminated document ID. lpszDocId[] is typically obtained by a call to ODMSelectDoc, ODMSelectDocEx or ODMNewDoc. 

It would appear that the only possible responses, depending on the operation, is one of ODM_E_DOCID and ODM_E_FAIL.  For ODMQueryInterface, the prospects are E_INVALIDARG and E_FAIL.

Inspection of the ODMA 2.0.0 versions of ODMA Connection Managers confirms that these are indeed the possible responses.  If the particular operation has only one of ODM_E_DOCID and ODM_E_FAIL as a valid ODMSTATUS value, then the one permitted value is used.  Otherwise, either response is possible and the implementations have ways of producing both.

Generally, this function is underspecified and much more information is required before it is clear how the Moniker can be used.

The description

lpszDocId - in - 

An ODMA document ID or Null. If Null then the application's default DMS is queried for the interface. Otherwise the DMS that created this document ID is queried.

is more rigorous when put in the form

lpszDocId - in - 

Pointer to the beginning of an ODMA document ID or Null. If Null then the application's default DMS is queried for the interface. Otherwise the DMS specified in the lpszDocId[] document ID is queried for a COM interface.

2.19 ODMRegisterApp ODMSTATUS values

ODM_E_NODMS 

ODMA has no default DMS for this application

ODM_E_CANTINIT 

ODMA initialization failed

ODM_E_VERSION 

ODMA configurationdoes not support the requested version of the API

ODM_E_REFUSED 

(deprecated)
Operation with the available default DMS has been refused by the DMS.  This should be treated the same as ODM_E_NODMS.

3.1 ODMGetODMInterface HRESULT E_ODM_VERSION

B.1¶2 on when documents are saved into a DMS

2000-07-09
tbd