From: Subject: AIIM Standards Date: Fri, 7 Apr 2000 09:28:42 -0700 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0040_01BFA073.AA5BF660"; type="multipart/alternative" X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 This is a multi-part message in MIME format. ------=_NextPart_000_0040_01BFA073.AA5BF660 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-Location: http://www.aiim.org/images/standards/header_standards1.gif R0lGODlhKgM6APf/AP///yEhIUJCQlpaWmNjY87Ozvf394yEhL2lpZyEhLWMjEIxMSEYGIxaWlo5 OXtKSoxKQoxaUntKQntSSpRza3taUrVjSq1aQoxaSqVaQsacjJxjSqVzWmtKObVzUqVrSsZ7UpRa ObVrQs61pd6UY5RSKd69pWNKOcaljHNSOeecY9aMUueUUpRrSvelY96UUv+lUv/375yUjN7GrZSE c+fGpda1lDEpIb2ce+e9lK2Ma3taOVpCKZRrQmMxAO/n3s7Gvf+tUu/Opd69lLWUa5yEY+e9hHtj QkI5KefGjOe9c5xjAL21pd7Orc61hK2UY9a1c8alY62MSpxrCEoxAGNCAHtSAJRjAK2llLWUSqV7 Ida1Y8alUqWEMZxzEO/nzufevc61UpSMSnNza0pKQqWle4yUUq21lHuUUpS1hHOlWmulY6WtpZyl nHOEc63GrWOlY1J7WoytlFKca3OtjEJ7WkKMazljUnOMhFp7c73GxpytraW9vYylpXuUlFKMjAgQ EDFzcyFraxhrazmEjClrcyljaxhaYylaYzFaYylzhBh7lDGEnCl7lHO91lqElEqEnFqtzimErRBC WhhznFp7jDlrhDmMtSk5QkqUvXOlxjl7pRhahGOUtSFCWjFrlFJzjIStzmuUtXOlzjlrlEJ7rSla hCljlCFSexgpOc7W3py1zikxOVp7nBgxSkprlCFCa4ylxlpzlFJrjDFCWkJaezlajGuErSExSjFK c0JKWoSUtVJjhBgpWkJKa0JKeykxYxghUt7e57W1vXt7hMbG1rW1znNzhJyctaWlxnt7nBgYITk5 Wjk5YxgYMRAQMSkhUhgQQiEYQoyEnHtrlFpKc5yUpTkpSiEYKVIxY0IxSnNKhJx7pWtCc4RzhLWU tSkhKZRjlIRShJRalDkhOWs5a2spY62EpXs5a2sxWlohSmsYUntKa1pKUrWUpVo5SkIhMYRKY2sp QnNaY86ttWtKUsacpb2UnK2EjFoxOWs5QntKUnNCSnM5QmsxOQAAACwAAAAAKgM6AEAI/wB9+FhC sKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJMmMVK1auXCnJsqXLlwIJrpRZcOYS mzhr6qTJ8+ZOnz1zBv0pFKjRokiJKh3K9OhSp02TRn0qFarVqlipap3K9epWr12zhv0qFqzZsmjJ qh3L9uxat21n4jyZUiXQlXh95t2rty/fv34DAx4suDDhw4YTI16sODHNmIUBZMmrJYvly5gzX/4C Jm/fKAVCF5CypIvo0F4M4jV9Wu7pAl1mPjm9hIloPTq9nPaCoLXBLACCB2+SRadKm8KTJy++MsoP 5cKbaKEJXPiSLM+T/+iy00sT6GC6gP8RDoamFycxoAOI4WQKUCfkr6APXvymeOhDvCR3YvcKl+zK sQfXgDk1J9wXpC0Bxg/fTXHFDzZcEQUA7mHXBIQSUrjED0k8aMNN6DXIU4gUPtjhEjbE8AUXS2gB wBAGNMGdFz980UQUGbrnUxc/sOfFFV18EWNqE1YYI4ZLfCGZhyul+AWOJj7IH48+yhVYXG+lheWW BGbppVN40XXcXUoxZmZjZ6aJ5ppqtslmmT5BNpRkesFnE3xO5Knnnk780FletonGBBY2nIHAGTZg gWigonG3EmuiuXZabATNFmlBZbwWGhM1MaHHpXjBd2BqBVUXXAw4JfdFXqYC8CdBXSj/51Or9c2a HHelJReDezN9F98SogbHX0FQJPdqsAAYt0Sxv67khZLCDSseGNQ6egWtNFmJpWc5NYEgg9cCkCcA WlhJHBhN6MSgDR12EUMU8E2HbrjcNQEGcOnO9CwY03krBYTXAdAFcLEt+G+6sXLxXWxc2ACcFl7A OBnBS/gLMHDjTseTtn296VmXXGoJ8sgilzzUX2L2t63HLLvpcsswv3wyVHjJ6RSdoSabc7bi2kSt lYBdWSARBXgxBRNSEMHEE0t4YRsQnC7xxBlOOIo0EU9ocfXSBJ1HNXdSAFEAE0QcPdkSUqBAdmpd IF0G0rA6wQQO0+lWhrJX5p0UX9nC/0lm34AXqOzHRhVeVcd9I+bVx0JpyzG3SwVtVWGJb8zU44NT bvnfggcOp5ohf0my6CZvKTjfV1SRMuShv+x6zLC/rjiYiztlM+Zkol65TZQT1lTHe+dOM95/T857 UZx/njnjykte1prGA+8Y7F/i7hjQ02N+5ubJv85957Rbf/qboZc/uvmlj0/TAlVQoXpddu1Ueu2y x25//c5nPnPwK0GG//0A/J8Ab5I6KhiQAQY0oOoWeJIGWoGBEIygBCdIwQpa8IIYzKAGN8jBDnrw gyAMoQhHSMISmvCEKMQgSlZ4nDEZ7nyjG6AMA4g49YVPeZa7gkAI4AMe+rCHQPyhEP+DSMQhGrGI SDyiEpPIxCU6sYlQ5OEB3cfCFiKuhp5r3OYct8UuJu+LXASjF8NIxjGaUYxoLGMaz6jGNrLxjWuM oxvlCMc5cpF5NBxg5fR3Q77B0GQzDGRj9ofDGxLyMQP5I+kWiT5GKrKRkHykJOdHSUdWMpKXnKQl N4lJTmryeynLoygFScpRws5/ylpSC1fJylb+LClS0FQBgKAjyEEqNDZ5DaWuYClNJYgvsZQlmbyQ HvXoilRA8UIUwOCET5JsPMEpjzOlsp9MXnIl6GkanaKQLm6u5F7AQlVpmsAFAEBBQulSkBOaMKwl cHOdR3lnE1YCgCjchJs2qJC4iNP/NScwE5vi9IkWmiAjgmghCeRUCXq+yYUr3CtIAPhCucCJznze hJnsvMlACwq4aXrSmh8NaQ5vsrrilfKkpkSp93J3u74sySd2OiNBfqYaYJ2GaQYJpmjKRZNbFkBS jZKNb7RwGiIQhFFSWMkZfGMcZTbBAMYEwIf0Uk2/XKEyUNgTgHQWsF/5ZELCqQ+y7GkeY+EESFng k1lBpCtHFQSawcFVqfYjE2idiplRmIzKjrdIyGnvitjDm+4EKzzmGZZ4/EOs8ABr0uyJ1KOdjCxc BlNS8S0vpZhVaWYL2b9Ezuls2ARAXuDzFGoJtAuo7QJP4aSF1KrWPVNwrVyB5FoH/3XNtXyRrY5O m1q+OisL8MoTF6TAq47exAuX2e0VkJunLMy2poWLbpmUKVyNFU+jaXVCFlLju58gTgtZ1S6ptHiF KWS3udbSnFvweMfOgW+kUeHWYa8bON4FZUysA1r87GvI8W0PsgAGqWSxR1mU4Ld1m9WsgqFnyBu2 lCZRjbB6XuVewt4FamiDTYaTOgV6FOAMaBMb3GKZIBwUwEEmjq3YMsWpa4WmCym+ghTeMMsyuIcJ UcPwbICQKRwsgWjI/B4WD+vHIgttj0fuLuF8S8gwsoyPUimj5BrLmMvOTMhUJp8bifzCJjNYwAF+ bPo0p5IFwk9+m1ywmk15yAYDTf8g//BBnOcs5zrT+c52zjOe96znPvP5z34ONKAHLehCE/rQhk40 ohet6EYz+tGOjjSkJy3pSlP60pbONKY3relOc/rTfV6AD6rgAwO7ML9iTrCq69dmG7p6CTHxgQ5n Leta0/rWts41rnet617z+te+Djawhy3sYuOaCgh03/tM3cpmO/vZ0I62tKdN7Wpb+9rYzra2t83t bnv72+AOt7jHHe3GXjnMXl5zKVsN5XZXTiBgjneqBzxvdNtb3vTO973rje9967vfIrtJqeuy6oKr 2+Bvioll/83vhjP84f6OOMAdLnGKTxziFz9fmJh98I4j3OPwVgq1Rk7ykpvc5En/oIoWnhCFJ7C8 bEtRpstbXpOWv5y7pWH5zF1Oms5JYec6V4oW4EVyJ0BhtRVny8AsQymMY0ZjGReLF0beBGR6hptN oyhBsD71WqVlJlgvUBOgEHNwuqXrfgu7xdeOcbaDZeNnHqnH5/5xAPZE4ZV7qctMi8cs3PQ1xd2L T4H6Yp/0sgCZEg3OZwKpQdGGJlNIjgHG29XgfOEudG37yeBanoVPsqpR34oBHJbNJRigmafP0E0E NIRVkfYKApqQ6pnUs5pgqGcTatGS0FWxVQFnMst8zuqbCZTxfIE7Q+gMwWDPn9znvmKdz72LJsN7 2efeoRF9Lh6Tzv3Qt8UvJRUy/93HX/f/Cg6VfNE7sCSz9PYz/f1ZEAFnfHv4pMLqNTgviE/1osuC HH65p9FiNyE2L3YFNsBUMlFOEfYD5/RW1KIdIxcbLnIg03EFzBIcEUIQrRJNTmADW9UZPmFXAGAA eZUFcBVNMgFWwZEfTWMDydFQbBUcW0UnWlBMlscFwDWDzbQSAMIvV2VXl8c6irRkNeVHi9UUXmAD zER5LbiEWYZkr5ZY6uNXHcVkRqZ53ed2UQZ+zIZm6VZ+YEh+UghriSQ4OMNWcERTNpF4nyJLsuRW QPIahKdhlcJUOlUAWZB4iDcTS3UpCbgn1vUoNniGSwB6BIEsAOAn1DKIjLccRv+BLdgXVmTCeXgh ghE1cmslH8nxIzohKzmReSrRBUMwg16lRStjhex2XUwWMNPxBCyCFw9jELESBZyYP0gBBhl4FE9y E65oZZcDXYXlWFjofVnYE4YRfubWR2G4jGuWimTYFHRCQKQFU1w1FHxHEH0YGkblXQRxh6Nxf7SB F/1Xh6BCEFhwG7O0W7XBVHihghHWeUCxgfSxBENgTDHgK8ExE5Cof464EjVoTAZQjyhIEKRoeXYF j8hCYPJ4IHDVTvhoTB8SNF83PLniXDHQUCbQGRl5F03gMIQoBVCgH+fkLShyedN3BRkZLiAZjRpF J7HiXAbAIiawKqY1fSdJLTT/Uh4uogU09QM7uJEv2QUxiZIaKU3b1UVUCDrFuJQXdxjI6Hn+xYxS OUPOmBeo1BNnqIl1Uo2FqIiLKE1ktkc4QWJNUUsMJj0EoSNvEDW7cxCmmEXuVjtiiWRdljdDZpd8 5YVJWYTCmFi/2D1eODzBc5dXyDFoOYZCqEbn9ldKSYyO6XaN8UBdiGXrNZWWuVKv1pZXaRRZ+Xpo SFXE900gSGBHyEW2URoFwDSmoZoFYFRENSmmgQJ1GBuz0QVegALheIDuMRtSoBtEoBK46QUm9iNO UDROIxpAkGE4JZhudllXiEXByF56w1iRo1gvtD2ZSZF3hJbXOZ2oeEhOFp5f//ZGioOYg8SUWshJ SrZsVkSZEymGl3me2fmcm5mXd1kT8eOW09k77qkQ0illX8SX3BiY4sll+dOWtug3VVaXScafMGOd b/eFSCmMCAqhuEOaoFOgnDUVbjKM6RlJYWkFymZqfzmE8Qmf2/ecKhonZUig8EU7xiiR+8lYiUlY W7iFxkVeesmhFBqVK7qYFUqF1qlkD5qMOGqeQVqds1OYzUM+FBmWc8mjjfmh6MkVRSZqClRZO9pJ KCqVVQmdhRFrsDamA1GmZHqmZpqmaLqmatqmbPqmbhqncDqnclqndKpDApFAeqqnPrCnfvqngBqo gjqohFqohnqoiJqoirqojP/aqI76qJAaqZI6qZRaqY1qZhwXjEaaZidacF+aomAqEKzgA6I2qqVK qj5gqqmKqqraqqz6qqcaq6sqq65Kq7A6q7haq7l6q7raq7z6q1iKbAY0asu2QvDDSimRrMa6rMza rM76rNAardI6rdRardZ6rdiardq6rdzard76reAaruI6rsbabJ5DpV26bs0JhXFplQMRWFUar4fT PsnGnqs0SEJqR3W0r3TUr/rqr/z6rwIbsAQLsAY7sAdbsAMLoOS3WD8KpfuWrvbzqfTTpHgnsRjb qRm7sRrbsRz7sR5LPloKsiQ7lRcbsiWbsii7sirbsiz7st6TF0+JrjTroeb/84xJ6rI6C7M8u7M+ 27NAu2B9EUryWrNFyxVy8rNKG7RMu7RO27RQKzMyS6JG+5g2q0kzcbJPu7VR27Vc+7Ve+7JDS6I1 erVWe7QVi6eUc4kn17YnZwCjWRiMIhpPIJH7J46T4n+yBARFNgVuCDlT8JDgUYEry3l1R1fweRO/ hzGoEwUN9TBygYtX5QQ8pZQXNU+BAQAwiDqxWGWQGxi7KCGbG7Zg+z9GEUpCirZnu7o41FmIxZIW YVqGQWOyxDRFcbc3MY5S44ZM4FtA0IZyaBQPGQM2kCeCm4F40QTFNCzkR4k5S0OIa5kXFQMLwh8O NU+8RzG8lzALoyDpIgXi/xIvy/ID+JItUEC+AJAuFOMtFqKJWUUuS9Awsch7cvEDQ8AuQBIDOCC+ 2SswBOMFJhADpLG+X9C+GCO+9ou/qFi6YasTqKupqlu1a2eESbsThNglNBU4HrYpS6CHrelH++cT unt4t7SNaygaUTC3e9Eql9cXfGIlhugZlaEnebV4R9YF8AIFuxQYzOUEUaAxztsXXcAFeoKDazIw NqwFROwEXMCJmddTS+zDO4xSujcZCzV9v7cEG3mTYJCTVUyUWgyC4pLFeTHGdAKU7GcAxVEjBnh5 +sGTOqlK3Xh05nQFJGkDJgkApDGTDiVNPrkSaGyRGFkeGwmSLkJ2hEm6Df/sRw+MoRJstjQ7ZXgX FCypiRI2YVc0BcBLD3x4GtYrxMG7Ev23Eod3HadhfwRBNKGBAleQjQXgF4NIHjbABYF4ExJWH0kg YTEwXq2igOoxW+5ijz1oE5YIHjQRLLi4HAZiTCJIfJVnTA3oyJg5ZQK6igcGJPdiI3chHlKgzQRE QEIIXfulGvaZn3xJXnJhX3sFjAz8s1jUyBUKyfKchQd6sjxBiNP4ECohu57hBQRYAG/gGedYAHpQ DM68GqG8BKO8u6JBEB7MXTrFyUvQGw3tF1EQy9DxBTYcvQa1J2dzUcLxAzKxgfa0ElOwVdzlyyMY eAKJgishBYCIHMIRkev/pxzMRLkGaFbH8SxVVYjRMdJ7ssDU47DRY5jSiWb2WbFVqIxGNmVJ/Z9p q8guaxXwLJ+PHMGNlKDPWGSV7JlitM/wqC+vgQM7hzWvIYDg2NAzsdClvBKMghuviRpHFY6GMxMz XMyU98RgV5CyorjJgSN6QSvfpMx3YbjOMh/vSI3CUdJUlRyA09MqjR+Ut5dTmpdNDZjw6hNdZ4GY 2zX3cnXhoViIAQWYKzmkbc4ySprSkxXtzLNKUdULyrrzHHoJWjPveiXq55mWLGFgaR9u+NubYhMh LMp5S8qPV17/TNGFdxMHqNY+8ZCAnRcnCFo+LSzJpCv1sc+OrYGEDYuE/40s7WTSUOXSKi1R4Gws BYEsgDPdfdEqO7gTWdAwg0i4lD2ewMNNScBdGHXQiktQbqVR/q1RNkBOIBIDF9VQnJ0iecEj4rJ1 TZDfB+5QDcVNpI0rXXAj5rQEU+BPzQRR5g0GCI7fnLjfR+agldnaEjujsG3fWN3iSHpkWktVH71+ W3kY/IyayFlcG3MFcwtivu0bxN0ohkfXTSNLPYeNRK57Nr2IykHTgx3S1JIFkbcflpEifR0uYbXC jjhT2gEFUmCCNu3XwvEuX+6C6B2DwWE4xGQsefUfykF8E7iCqaEFJpAcOh6dVo09N9lNovV8+mIv tTcTxlcvyicwzOdOyf8yfYXIvATBHle1e/PkfMlies0kIN6ilRKyIJNuLwbyxdXX56L11d71nlId smC6Eituflct2yZ62YQT43iBz9UYU4ORwXdIS+vsGXObnHEI5Apd3AwdGjrhd6dRBnvR3MLuF2DO zFBSU1lgiXpl5sbSBeot5vRhJYKt2S1NHhseH85ygnIexNVOOPfR5JHY4M4i7crxA4wdo046WE2i IlACMEjyVfcIBrb1KD8weu4RJEOSI4deMQyiIe2oIShiACuiEllwJBFSTlPg8NfBIBhCIzZCdleg JGucgTaA8AguIBjiIjp+oTFU6hn7dqn+7que8lKayK9+23/R1ZPOVnv/YXJwa6BLrWVdos4yMV/3 Nc6q/aJRiee641uprZ/66aP19Zb8RTjsvNphCe/il6QUekUOaoRTiBCmKPKpu5enSPLxSRWSSXD1 Hdsq7+JPv5+wbsszHlOHGOo+ge5gDapa7xNkiTpqc+pIDV1dAAQJ8gRHLvd+4bc4QITsSvaET4TS fM4z6vSHeYQzWmG13fh4fj3O2ZZLzbByh/f6g/lFD6orj+II9/gE8T7X/LxEOttlj/Tx3DFpfwXR GFrH7PYEge4XBY9mwfg/VjS//nOpiZpn0AVTgANA0AWZ4h4FoApM4FxjA9MaVgY40DY/5QWZIgWt 1fvTHzZ8OxtVMwI//3U0T2AavWsazHGu3gmxGXr5uO/qcImv1Bmh6g/1pbn6TN2dTKqpjrzyawQ+ id/1oA8QV5YIJDjQYEGEBxUmLKhwicGHBK9Y8VHFyhWMDhku5Jgw4kOIIQV+JCkS5EiTJVGuPNlS pcuUMVm+pNnR5MaPCH34sHkFQJQsQbPYACB0aFGjAIZIEfoFDEiHEHGOHMmEyRUpBaQs6aKVa4En S7wUQNGFCAIvWsAKfFJAy5KsXaSokjKFXoGHZQpMwVqgy5ICTLx4AXLVSQGBepfgKJA2cN8uU29O bjg5Z9SGVFuy1PyyskaOoUGLnhmSdE+pJDub9ujR8mXOolOH1ly5dP/s2Z1xs0Zd8zbqjcGBDxde nPhx48lnU7ZCxeLFjJmR95YJ87dv69mxb6/O/Tp14bA/7uwptIvRLOeNql+fPsvbzaBn6lYtdWXs 6OJpZoTaX/r8y1KzDbPqXBuwvvgOxE4ylATUrjbtKINKOfp40w/CBaOSMLzWAuwupQobxIk2m7xL cDoKUVQxRRZXtJCjKpyzArr8IGxxxO9yjFBHE3v8kEfwShRyCfI6rJA3ESckcLUk5XNywNVys9BG B0vsUEgcT8zSs+EI5PJJJWtaDkgX6TMwvjGz+69ALS/0sTQpUwzQuDfLtPPGO/PkcEmDmqviOYwC BRPPM+s09McdEz3/FD8+zxyRSJ6MlHJOJV2LaUPZqFTQyt7oXFM6Bx1VM0guW0R0SFAlrPPTLjXt rklMvXxN0iiBZNRV8Q5UblU9eyXU1+kaXYIVH5wDtMb6fg3vVGZtVbTZZ3/LctrTIF3in2uvwHbb a7vl9ltvwwV3XHHLJfdcc9P9R9ts0T2X3W3hVVded9W1t15879U332/p3fdfd+EVON53CQbY3IEP 5tdffhE2uGF8E14XYnEltvjhi9vVeOKNM+b4Y49Dxnjkjc314R8fiP1zxkCRDRVYZxeNdmaZSxUW ytNG2ulknlH2uWegfxY6aKKHNrpopI9WOmmml3a6aaifljpqqqe2/7pqrK/WOmuut/a6a7C/Fjts ssc2u2y0h17Ah7Wr8IGilqfMFWaaoa3ZbmipFXXvgcjr72/AAxd8cMILN/xwxBNPvDkqGmegccgr +nNyyv+sqCIqioV8c8479/xz0EMXfXTSSzf9dNRTV3111lt3/XXYY5d9dteLrXxGlgXFMFm6C8U7 5t/rljZn4vk2iLwFrkh+eeWbZ/5556OHfnrpq6f+euuzx3577bufnnEqHm+cctzLN/989NNXf332 23f/ffjjl39++uu3/37889d/f/779//+lvGnSsrK092Ad0DhtelWmFogSHa2NgiyTYIRpOAELVhB DF5Qgxnk4AY92P9BEH5QhBl03PhWhrsAplCFK2RhC134QhjGUIYzpGENbXhDHOZQhzvkYQ99+EMg BlFQoyFgEWWFQAMmMEN8wxkTTeM3VxlRir2jIkJiJL4T0ihunxEQQiQykC9GJ4xjBGMZxWhGMp5R jWlkIxrduMY3thGOc5RjHeN4Rzri0Y555OMe/ahHQPYxkH9U46SmOMUBKvBmVcSSEoOXRJs1cZEL nAl5CLCES2byCprkJCY36clOEuCTogzlKE1ZSlSCUpWkXOUpW5lKVsbSlbIkAPgqgsIteihVcjMk gkLkS2D2Upi/HGYwiXlMYyazmMtEJjOV2UxoPlOazqRmNF3CJEdsIpGXuiQVI+X0SHBqk5KKnNs4 A7SzMfggnetUZzvZ+U53xhOe85RnPel5T3vmE5/71Gc/YzS+3OmuUnMb1DSteVCDJrSaCkXoQh3a UIgyVKIPnWhE25RNjNrMTQRl0yGDFc6MBk9vkyRnRwICADs= ------=_NextPart_000_0040_01BFA073.AA5BF660 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0043_01BFA073.AA5BF660" ------=_NextPart_001_0043_01BFA073.AA5BF660 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Content-Location: http://www.aiim.org/industry/standards/index.html AIIM Standards ------=_NextPart_001_0043_01BFA073.AA5BF660 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Content-Location: http://www.aiim.org/industry/standards/index_head.html AIIM Standards
3D"AIIM
------=_NextPart_001_0043_01BFA073.AA5BF660-- ------=_NextPart_000_0040_01BFA073.AA5BF660 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Content-Location: http://www.aiim.org/odma/odma20.htm ODMA 2.0 Specification =20
Open Document=20 Management API

Version 2.0
September 19, 1997

To download the developer's kit, please fill out the registration form = and then=20 download.=20

ODMA HOME = PAGE=20



*Before downloading this file, a registration form = must be=20 submitted.=20


Download ODMA=20 2.0 .zip file -- This updated file (as of = 5/11/98)=20 contains source code of a sample DMS and sample application, header = files and=20 libraries for build apps and the ODMA 2.0 specification. New=20

Download=20 Specification -- MS Word version of the specification.=20

Overview

ODMA = API

  • ODMActivate =
  • ODMCloseDoc =
  • ODMCloseDocEx<= /A>=20
  • ODMGe= tAlternateContent=20
  • ODMGetDMS=20
  • ODMGetDMSCoun= t=20
  • ODMGetDMSInfo =
  • ODMGetDMSList<= /A>=20
  • ODMGetDocInfo =
  • ODMGetDocR= elation=20
  • ODMGetLead= Moniker=20
  • ODMNewDoc=20
  • ODMOpenDoc=20
  • ODMQueryC= apability=20
  • ODMQueryClose<= /A>=20
  • ODMQueryExec= ute=20
  • ODMQueryG= etResults=20
  • ODMQueryIn= terface=20
  • ODMRegisterAp= p=20
  • ODMSaveAs=20
  • ODMSaveAsEx= =20
  • ODMSaveDoc
  • ODMSaveDocEx=20
  • ODMSelectDoc=20
  • ODMSelectDocE= x=20
  • ODMSe= tAlternateContent=20
  • ODMSetDMS=20
  • ODMSetDocEven= t=20
  • ODMSetDocInfo<= /A>=20
  • ODMSetDocR= elation=20
  • ODMUnRegist= erApp=20

DMS=20 Interface

  • ODMGetODM= Interface=20
  • IODMDocMan=20 Interface=20
  • IODMQuery=20 Interface=20
  • IODMDocMan2=20 Interface

Binding to the=20 API

Installing a=20 DMS

  • Windows=20 3.x, Windows 95 and Windows NT

Installing a=20 Client Application

Connection=20 Manager Trace Logging

Appendix=20 A

  • Document=20 Attributes

Appendix=20 B

  • Preferred=20 Call Usage for Initial File Creation

Revision History=20

Version 1.0 - with small BHC-325 at the end of the document Brad = Clements,=20 SoftSolutions. This is the original version.
Version 1.0 - with = small=20 DM1\285 at the end of the document Mike Gardiner, Novell. This = contains=20 additional information for registering ODMA under Windows 95 and NT. = It also=20 adds a new table for document ID constants.
Version 1.0a
Rod = Schiffman,=20 Novell. Additional information on the ODMA spec background, usage of = calls,=20 suggestions on the use of document ID character sets and the addition = of=20 ODM_E_INUSE as a valid return code in ODMActivate.
Version = 1.5
Jerry=20 (Gerald) Willett, PC DOCS, Inc. Added the Query specification. This = included=20 the Query Syntax and Query Examples sections and the ODMQuery* = functions and=20 the IODMQuery COM interface. Also added a clarification to the = expected=20 behavior of an application when calling ODMSaveAs and an empty string = is=20 returned for lpszNewDocId.
Version 2.0
Bob St.Jean, Digital = Equipment=20 Corp. Added additional attributes and functions to improve ODMA = support for=20 popular Document Management System (DMS) features. These are mostly = defined in=20 a new IODMDocMan2 interface. Defined several items to help provide = better=20 out-of-the-box integration between desktop applications and DMS. Also = added=20 clarifications to the existing specification and arranged the = functions=20 alphabetically.

Overview=20

The original impetus for the Open Document Management API (ODMA) = was the=20 recognition that there was no standard method for a client application = to=20 integrate with a Document Management System (DMS). Each DMS vendor = wrote=20 separate integration code for each of the major client applications = they=20 supported. Applications that did not have integrations written for = them by the=20 DMS vendors would have to write and support a separate integration for = each=20 DMS that was supported. This required a complete matrix of = integrations, each=20 with its own set of bugs, limitations and reliability issues. It = seemed=20 obvious that a high level standard for connecting applications and = document=20 management systems was a natural fit.=20

A small group of application and DMS vendors started working = together to=20 create an API that would allow applications and document management = systems to=20 inter-operate through a single high level API. This implied the = creation of a=20 standard, however, the creation of a standard has many pitfalls. = Probably the=20 biggest problem is that a lot of work can be put into the creation of = the=20 standard, and nobody uses it.=20

The industry is filled with examples of standards that were = obsolete by the=20 time they made it through the standardization process. By the time = some=20 standards make it through the standardization process, they are so = large and=20 unwieldy they are almost impossible to implement and maintain. Company = politics and hidden agendas of the participants can play as big a role = in the=20 adoption of a standard as trying to solve the problem in the first = place. The=20 industry is also full of proprietary API=92s that claim to be = standards, but are=20 not. The initial group of vendors that met and formed the ODMA = consortium=20 wanted to avoid as many of these problems as possible.=20

The working rules of the ODMA consortium are fairly = simple.

  1. If the standard does not solve a problem it will not be used.=20
  2. If the creation of the standard takes a long period of time, it = does not=20 solve the problem.=20
  3. If the standard is difficult to implement, it does not solve the = problem.=20
  4. The standard must be vendor independent.=20
  5. The standard must not try to solve all vendors=92 problems, or = it will be=20 big, complex and take a long time to implement. This violates rules = 1, 2 and=20 3 above.=20
  6. It is the customers that lose if there is not a straightforward = way to=20 integrate applications that create documents and applications that = manage=20 documents.=20
  7. Easy integration between applications and document management = systems=20 will grow the industry and increase sales for the entire = marketplace.=20

It is difficult to express the importance the initial members of = the=20 consortium placed on wanting to create a useful API that is vendor and = platform independent while still simple to implement. They recognized = that=20 they could solve 80 percent of the problem easily and were willing to = live=20 with having to solve another 10 percent over time and probably never = being=20 able to solve the final 10 percent.=20

The Open Document Management API (ODMA) is a standardized, = high-level=20 interface between desktop applications and document management systems = (DMSs).=20 Its purposes are:

  1. To make DMS services available to users of desktop applications = in a=20 seamless manner so that these services appear to the user like = extensions of=20 the applications.=20
  2. To reduce the application vendors burden of having to deal with = multiple=20 DMS vendors. By writing to ODMA, an application vendor has = potentially=20 integrated his application with all supporting DMSs.=20
  3. To reduce the DMS vendors burden of integrating with multiple=20 applications. By supporting ODMA a DMS vendor has potentially = integrated=20 with all applications that have written to ODMA.=20
  4. To reduce effort and complexity needed to install and maintain = DMSs.=20

ODMA specifies a set of interfaces that applications can use to = initiate=20 actions within a DMS. The API is intended to be relatively easy for=20 application vendors to incorporate into updates of existing = applications. It=20 should not require major restructuring of an application to integrate = it with=20 ODMA. Note that this version of ODMA does not specify how DMSs may = initiate=20 actions within the applications.=20

The ODMA API is platform-independent. The associated data type = definitions=20 and binding information are platform-specific. Currently, most of the = work has=20 been done in Windows. It makes this document look Windows specific, = but over=20 time, the platform specific entries for other platforms will be added = as they=20 are defined.=20

Document IDs

Many of the ODMA functions accept or return a Document ID = parameter. A=20 document ID is a persistent, portable identifier for a document. It = can be=20 stored and used in a later session, and it can be passed across = platforms via=20 email or other processes.=20

A Document ID is a case insensitive, null-terminated string of = printable=20 characters. Although a document ID is case insensitive, an application = should=20 never change the case of a document ID. The format of a document ID is

::ODMA\DMS_ID\DM_SPECIFIC_INFO

The DMS_ID portion of a document ID will identify which DMS = provided the=20 ID. This information is primarily for the use of ODMA itself; = applications=20 using ODMA should not need to know which DMS provided a particular ID. = The=20 ODMA group members will coordinate these IDs to ensure their = uniqueness. The=20 maximum length of the DMS_ID portion of the document ID is specified = by the=20 constant ODM_DMSID_MAX. The DM_SPECIFIC_INFO portion of the ID = will=20 vary depending on which DMS built the ID. The total length of the = document ID=20 including the terminating Null character cannot exceed = ODM_DOCID_MAX=20 bytes.=20

ODMA-aware applications should be able to handle a document ID = anywhere=20 they handle an externally-generated document filename. For example, if = the=20 application allows a document filename to be passed as a command line = argument=20 then it should allow a document ID to be passed in the same way. If = the=20 application allows document filenames to be used in DDE commands then = it=20 should also support the use of document IDs in the same commands.=20

Although the technical definition of a document ID is a case = insensitive,=20 null-terminated strings of printable characters , there are some = general rules=20 that are more likely to make a DMS and ODMA application work better = together.=20 ODMA was designed so that it would be easy to add to an application = without=20 major modifications in code or structure. If a DMS passes a document = ID that=20 breaks fundamental rules of normal file and path names it will = probably run=20 into problems if it is passed in on a command line. Special characters = like ^,=20 [, ], |, *, -, >, < and ? are processed by the UNIX shell even = before=20 they are seen by the application. It is possible to pass these = characters by=20 using special escape sequences, but that places a burden on the DMS = vendor to=20 process the document ID before giving it to the ODMA application. Some = operating systems require the application to handle the reverse = process of=20 interpreting and removing the escape characters. The application may = be able=20 to support the escape removal on the command line, but not if the = document ID=20 with escape characters is returned in a procedure call. In most cases, = it is=20 easier to generate a document ID that contains a fairly simple set of=20 characters. The following table suggests characters it may be wise to = avoid=20 for different platforms.

Platform Characters to = avoid
Windows 3.x " =91 < > * ? | = and the space=20 character
Windows 95 " =91 < > * ? | =
Other platforms to be = defined

Constants

The following table lists the constants that are defined in the = odma.h=20 header.
CONSTANTS Win 3.x Win32 Mac UNIX Other
ODM_DOCID_MAX
Maximum=20 length of a document ID including the null-terminator.		   80   255   255   255 255
ODM_FILENAME_MAX
Maximum=20 length of a path/filename returned by ODMA including the = terminating=20 Null character. 		  128   255   255   1024 255
ODM_API_VERSION
The=20 version of the ODMA API to which this header file corresponds. = See=20 ODMRegisterApp. 		  200   200   200   200   200
ODM_DMSID_MAX
Maximum=20 length of a DMS ID including the null-terminator.		   9   9   9   9   9
ODM_APPID_MAX
Maximum=20 length of an Application ID including the null-terminator.		   16   16   16   16   16
ODM_FORMAT_MAX
Maximum=20 length of a content format string including the = null-terminator.		   81   81   81   81   81
ODM_QUERYID_MAX
Maximum=20 length of a query ID string including the null-terminator.		 255 255 255 255 255 =

Error Handling

Nearly all of the ODMA functions use the return value to indicate = to the=20 calling application whether the function succeeded, failed because the = user=20 canceled the operation, or failed for other reasons. The DMS is = responsible=20 for displaying informational error messages to the user where = appropriate=20 except when the ODM_SILENT flag is specified. The DMS must take = care to=20 return the appropriate error indication because applications may act=20 differently depending on whether an ODMA call was canceled by the user = or=20 failed for other reasons. The calling application generally should not = display=20 error messages when an error value is returned from ODMA unless the=20 ODM_SILENT flag was specified.

Connections and the ODMA = Connection=20 Manager=20

The ODMA connection manager is a small software module that sits = between=20 applications using ODMA and document management systems implementing = ODMA. It=20 manages the connections between these components and routes ODMA calls = to the=20 appropriate provider. A freely redistributable copy of the ODMA = connection=20 manager will be provided to any vendor wishing to implement or make = use of the=20 ODMA API. This is a place where it would be possible to provide = mapping code=20 that would allow ODMA to have truly platform independent document IDs, = however, it currently only manages connections and does not touch = document=20 IDs.

Document Format Names=20

When new documents are registered with a DMS via ODMA and when an = existing=20 document's format is changed by an application, the application passes = a=20 document format name to ODMA. Document format names are = null-terminated=20 strings defining the format of a document's content. These strings = have a=20 maximum length defined by the ODM_FORMAT_MAX constant.

There are several places in ODMA where a content format name for a = document=20 can be specified or requested. The ODMNewDoc, ODMSaveAs = and=20 ODMSaveAsEx functions each have a lpszFormat parameter where a = format=20 can be specified. The ODMSaveAs also has a callback, which uses = a=20 format string. The ODM_CONTENTFORMAT attribute can be requested = or set=20 using the ODMGetDocInfo and ODMSetDocInfo functions.

The ODMA 1.0 specification did not attempt to standardize the = format names=20 used by DMS and application vendors. This was a significant limitation = in some=20 cases. The DMS would not know in advance what type of file was being = created=20 by the application. Also an application that saved an existing file = back to=20 the DMS using a different format would have no standard format name to = give to=20 the DMS. This model relied on both the DMS and the application being = able to=20 auto-detect all file formats.

ODMA 2.0 defines guidelines to standardize format names. This has = become=20 necessary due to vendors=92 desire to have applications and DMSs more = tightly=20 integrated and because ODMA 2.0 introduces some new functions which = require=20 standardization in order to work. The new = ODMGetAlternateContent and=20 ODMSetAlternateContent functions require the DMS and = application to=20 have a standard way to identify file content. A new document attribute = called=20 ODM_ALTERNATE_RENDERINGS allows an application to find out if a = DMS can=20 provide a document in other formats and make a choice of which to = use.

ODMA has defined the following guidelines to standardize how a DMS = or=20 application might specify a document=92s content format:

  1. MIME Content Type. If a file type does not have a MIME content = type,=20 then a file extension must be used.=20
  2. File Extension (a.k.a. File Type). If a file extension is used = the first=20 character must be a dot. The file extension should be the one = normally used=20 to identify the document on the platform where the client = application is=20 running. Some platforms allow the file extension to contain more = than three=20 characters. ODMA does not define a maximum file extension length.=20
  3. File Extension plus other identifying information. This other=20 information may be useful in cases where a single file extension is = used for=20 different variations or versions of the file type. In this format = the first=20 character must be a dot, followed by the file extension, plus a = single=20 forward slash, plus a string containing the additional information. =

Examples:
application/msword=20

  • .doc=20
  • .doc/MS Word 95 Document=20
  • .doc/MS Word 97 Document

image/tiff=20

  • .TIF=20
  • .TIFF=20
  • .TIF/Tagged Image File Format=20
  • .TIF/Scanned TIFF

A DMS or application can use the Windows Registry or its own = mapping=20 capability to convert a file extension to a MIME code or vice versa. = Note that=20 some file extensions are used by more than one application, some file = types=20 have multiple valid file extensions, and that some MIME content types = are used=20 to define more than one file type within the same application. A DMS = or=20 application may have use whatever format name is most precise.

DMS or Native File System Dialogs = - Which=20 to Display First
ODMA imposes no rules on applications = requiring=20 them to always show the DMS dialogs first in response to filing = commands such=20 as File Open and File Save As. ODMA applications are encouraged to = provide a=20 user preference setting so the user can designate if the = application=92s native=20 file system dialog or the DMS=92s dialog is displayed first. Ideally = the=20 application may provide a push-button or some other control in its = native file=20 system dialog box to allow the user to quickly select the DMS dialog = box.=20

If the application cannot provide one or more of the options = described=20 above then they have no choice but to always display the DMS dialog = box in=20 response to the File Open and File Save As commands. Each ODMA = compliant DMS=20 must provide a way for the user to select the native file system from = dialogs=20 displayed while processing the ODMSelectDoc, = ODMSelectDocEx,=20 ODMNewDoc, ODMSaveAs and ODMSaveAsEx functions. = The DMS=20 returns the ODM_E_APPSELECT status if the user elects to use = the native=20 file system. When this status is returned the application can display = their=20 dialog box. If the user wishes to return to the DMS dialog box they = will have=20 to cancel and re-do the file command.

Character Sets
All strings = passed to or=20 returned from ODMA functions should be null-terminated series of = octets, in=20 the standard character set of the system on where ODMA is being used. = So for=20 example, 8859-1 would be used on English Windows, Shift-JIS would be = used on=20 Japanese Windows, etc. The term "null-terminated" as used in this=20 specification means terminated by the character set's natural Null = character.=20 For most character sets this means a single byte with the value 0x0.=20

If an application obtains an ODMA document ID on one platform and = later=20 uses it on another platform, the application is responsible for = translating=20 the ID to the character set being used on the second platform before = using it=20 there.

Application = Interfaces
An=20 ODMA-aware application can choose to communicate with the ODMA = Connection=20 Manager either through a traditional, function-oriented API or through = Component Object Model (COM) interfaces. Prototypes and constants used = for the=20 function-oriented API are included in the odma.h header file. = Prototypes,=20 constants, and interface definitions for the COM interface are = included in the=20 odmacom.h header file.=20

After calling ODMRegisterApp, applications can obtain one or = more=20 COM interfaces to ODMA through the ODMQueryInterface function. = The=20 IODMDocMan interface provides an alternate entry point to most = of the=20 ODMA functions documented below. Other functions are defined in the=20 IODMDocMan2 and IODMQuery interfaces. These interfaces = and their=20 interface IDs are defined in the odmacom.h header file.=20

Note that IODMDocMan::QueryInterface will only query the = default DMS=20 for the calling application. The application must call = ODMQueryInterface in=20 order to query other DMSs.

Query Syntax
The query syntax = described=20 here is used in the ODMQueryExecute function.=20

<query> :: select <returned_list> = <search_criteria>
<returned_list> :: <returned_item> [, <returned_list>]
<returned_item> :: ODM_DOCID
:: ODM_NAME
<search_criteria> :: <search_clause>
:: <where_clause>
::=20 <search_clause> <where_clause>
:: = <where_clause>=20 <search_clause>
<search_clause> :: search document contains <expression>
<expressioin> :: (<expression>)
:: [not] (<expression>)
:: = <term> [<operator> <expression>]
<term> :: =91<word>=92
:: [not] = =91<word>=92
<operator> :: and
:: or
<word> is a user supplied word. If there is a single quote (=92) = inside this=20 word, it needs to be represented with two consecutive single = quotes=20 (=92=92).
<where_clause> :: where <condition_list>
<condition_list> :: <condition> [<operator> = <condition_list>]
<condition> :: <attribute> <op>
=91<attribute_value>=92<attribute> :: ODM_FORMAT
:: ODM_NAME
:: ODM_AUTHOR
:: = ODM_TYPE
::=20 ODM_DMS_DEFINED:<dms_attribute>
:: * Any other = document=20 attribute listed in Appendix A
<op> :: =3D
:: !=3D
:: <>
:: >
:: <
:: = <=3D
::=20 >=3D
<dms_attribute> is a DMS specific attribute name.
<attribute_value> is a user supplied value for ODM_NAME, etc. If there is a = single=20 quote (=92) inside any of these names, it must be represented = with two=20 consecutive single quotes (=92=92).

Query Examples
Example 1: select ODM_DOCID, ODM_NAME
where ODM_TYPE =3D = =91Memo=92
search=20 document contains =91Internet=92 and not = =91Intranet=92
Example 2: select ODM_DOCID, ODM_NAME
where ODM_AUTHOR =3D =91Mark = Twain=92 and=20 ODM_TYPE =3D =91Story=92
Example 3: select ODM_DOCID, ODM_NAME
search document contains = =91Mary=92=92s=20 Lamb=92
where ODM_NAME =3D =91Mary Has a Little Lamb=92 and=20 ODM_TYPE =3D =91Song=92
Example 4: select ODM_DOCID, ODM_NAME
search document contains = (=91rabbit=92 or=20 =91hare=92) and not =91bunny=92
where ODM_NAME =3D =91Wild = Life=92 and=20 ODM_AUTHOR =3D =91John Doe=92 and ODM_TYPE =3D=20 =91Letter=92

ODMA API
The following = section=20 describes each function in the ODMA API that a typical application = would use.=20 The functions are listed in alphabetical order.

ODMActivate

ODMSTATUS ODMActivate (ODMHANDLE handle, WORD action, LPSTR = lpszDocId)=20

This function causes the DMS to perform actions that do not require = cooperation from the calling application. Control is returned to the = calling=20 application after the specified action has been completed, except = where noted.=20 A DMS is not required to support all of these actions.=20

Parameters:
handle - in - A handle obtained by a = previous=20 ODMRegisterApp call.=20

action - in - One of the following action codes:=20

ODM_NONE - No specific action is requested. The DMS should = simply=20 make itself visible and let the user select the action to be = performed.=20

ODM_DELETE - The DMS should delete the specified document. = Note that=20 most DMSs will not allow a deletion to occur if the document is = currently in=20 use.=20

ODM_SHOWATTRIBUTES - The DMS should display the specified = document's=20 profile or attributes.=20

ODM_EDITATTRIBUTES - The DMS should display the specified = document's=20 profile or attributes, and the user should be put in edit mode. Note = that some=20 DMSs will not allow a document's attributes to be edited while it is = in use.=20

ODM_VIEWDOC - The DMS should display the specified document = in a=20 viewer window. The DMS may return control to the calling application = before=20 displaying the document.=20

ODM_OPENDOC - The DMS should open the specified document in = its=20 native application. The DMS may return control to the calling = application=20 before displaying the document. This function is intended for use by=20 applications other than the document's native application (e-mail, = workflow,=20 annotation, etc.). Applications should use ODMOpenDoc to access their = own=20 documents. If this function fails, the calling application may wish to = retry=20 using the ODM_VIEWDOC action code.=20

ODM_NEWDOC - The DMS should allow the user to create and = save a new=20 document. Optionally the caller can specify a template document in = lpszDocId .=20 If lpszDocId is Null the DMS should allow the user to choose the file = format=20 of the document to be created and the document template. In most cases = it is=20 expected that the DMS will need to launch an application to create the = document. The DMS may return before satisfying this call, in which = case the=20 calling application will not get notification when the new document = has been=20 created. The user is free to cancel this function.=20

ODM_CHECKOUT - The DMS should check-out/reserve the document = for the=20 current user. The DMS can display whatever UI it might use for = document=20 check-out. This action allows the user to explicitly reserve a = document in the=20 DMS in a way that is persistent across ODMA or DMS sessions. = ODMOpenDoc should=20 be used to get the content file. See ODMCloseDoc and ODMCloseDocEx for = recommendations on how to handle closing a document that was = explicitly=20 reserved before it was opened.=20

ODM_CANCELCHECKOUT - The DMS should cancel a previous=20 checkout/reserve on the document, if it has been checked-out by the = current=20 user. The DMS can display whatever UI it might use for canceling a = document=20 check-out.=20

ODM_CHECKIN - The DMS should check-in/unreserve the document = if it=92s=20 checked-out by the current user. The DMS can display whatever UI it = might use=20 for document check-in. ODMSaveDoc or ODMSaveDocEx should already have = been=20 used, if necessary, to save the content to the DMS.=20

ODM_SHOWHISTORY - The DMS should display the specified = document=92s=20 history (i.e. revisions, events, activities, etc.).=20

lpszDocId - in - A document ID specifying the document on which to = perform=20 the requested action. This parameter may be Null if the action is=20 ODM_NONE or ODM_NEWDOC. If action is ODM_NEWDOC = the=20 application can specify the document ID of a template document.=20

Return value:

ODM_SUCCESS if successful.
ODM_E_DOCID if the = document ID=20 is invalid or refers to a document that no longer=20 exists.
ODM_E_INUSE if the document is currently in use or=20 checked-out by another user on actions where this would preclude the = operation=20 from completing correctly. ODM_E_ACCESS if the user doesn=92t = have=20 appropriate access rights to perform the requested action (i.e. = check-out or=20 check-in the document).
ODM_E_OFFLINE if the DMS cannot = currently=20 access the document because the user client is=20 off-line.
ODM_E_ARCHIVED if the DMS cannot currently supply = the=20 document content because it has been archived.
ODM_E_CANCEL = if the=20 action was canceled by the user.
ODM_E_NOSUPPORT if action = is not=20 supported by the DMS.
ODM_E_ITEM if action is invalid or not = supported by the DMS.
ODM_E_FAIL if the action could not be=20 completed by the DMS.
ODM_W_NOACTION if action is = ODM_CHECKOUT and=20 the document is already checked-out/reserved by the current user. This = status=20 can also be returned if action is either ODM_CANCELCHECKOUT or=20 ODM_CHECKIN and the document is not currently = checked-out/reserved by=20 any user.
ODM_E_HANDLE if handle was invalid.

ODMCloseDoc
ODMSTATUS=20 ODMCloseDoc( ODMHANDLE handle, LPSTR lpszDocId, DWORD activeTime, = DWORD=20 pagesPrinted, LPVOID sessionData, WORD dataLen)=20

An application that has opened a document by calling ODMOpenDoc = must call=20 ODMCloseDoc when it is finished using the document. The = application=20 should not call this function until after it has closed the document, = because=20 the DMS may move the document or make it inaccessible as a result of = this=20 call. Note that this function will not cause the document to be saved = into the=20 DMS's persistent repository unless ODMSaveDoc has been called=20 previously.=20

It is possible for a user to explicitly check-out/reserve a = document using=20 either ODMActivate or a command provided by the DMS. If a = document was=20 already reserved by the user before ODMOpenDoc was called, then = when=20 ODMCloseDoc is called it is recommended that the DMS keep the = document=20 reserved. The DMS should only check-in/unreserve the document in=20 ODMCloseDoc if it first displays a dialog box confirming this = with the=20 user.=20

Parameters:
handle - in - A handle obtained by a previous = ODMRegisterApp call.
lpszDocId - in - A null-terminated = document ID.=20 This is typically obtained by a call to ODMSelectDoc or=20 ODMNewDoc. This document must have been previously opened by a = call to=20 ODMOpenDoc.
activeTime - in - If the application tracks time spent = editing=20 the document then it should pass the number of seconds here. Otherwise = it=20 should pass 0xFFFFFFFF.
pagesPrinted - in - If the application = tracks the=20 number of pages printed from this document during the current editing = session;=20 it should pass this number here. Otherwise it should pass=20 0xFFFFFFFF.
sessionData - in - The application may pass other = information=20 regarding the current editing session in this parameter. For example, = an=20 application might pass the number of keystrokes that were entered. The = calling=20 application is free to determine the format of this data, so DMSs that = rely on=20 this information will have to coordinate with each application = supported. Null=20 should be passed if the application has no meaningful information to = pass=20 through this parameter.
dataLen - in - The length of the data = passed in the=20 sessionData parameter. Ignored if sessionData is Null.

Return value:
ODM_SUCCESS if=20 successful.
ODM_E_NOOPEN if the document was not previously=20 opened.
ODM_E_FILELOCKED if the DMS could not complete the = function=20 because the temporary file provided in ODMOpenDoc is still = opened by=20 the calling application.
ODM_E_FAIL if the DMS is unable to = close=20 the document for any other reason.
ODM_E_HANDLE if handle = was=20 invalid.

ODMCloseDocEx

ODMSTATUS ODMCloseDocEx( ODMHANDLE handle, LPSTR lpszDocId, LPDWORD = pdwFlags, DWORD activeTime, DWORD pagesPrinted, LPVOID sessionData, = WORD=20 dataLen)=20

ODMCloseDocEx is the same as ODMCloseDoc except it = has a=20 pwdFlags parameter. There is an ODM_SILENT flag to facilitate=20 unattended document processing. Some DMSs display a user interface = when=20 closing a document. This flag allows the calling application to = suppress this=20 UI.=20

An application that has opened a document by calling = ODMOpenDoc must=20 call ODMCloseDoc or ODMCloseDocEx when it is finished = using the=20 document. The application should not call this function until after it = has=20 closed the document, because the DMS may move the document or make it=20 inaccessible as a result of this call. Note that this function will = not cause=20 the document to be saved into the DMS's persistent repository unless=20 ODMSaveDoc or ODMSaveDocEx has been called previously.=20

It is possible for a user to explicitly check-out/reserve a = document using=20 either ODMActivate or a command provided by the DMS. If a = document was=20 already reserved by the user before ODMOpenDoc was called, then = when=20 ODMCloseDocEx is called it is recommended that the DMS keep the = document reserved. The DMS should only check-in/unreserve the document = in=20 ODMCloseDocEx if the ODM_SILENT flag is not set and it = first=20 displays a dialog box confirming this with the user.

Parameters:
handle - in - A handle obtained by a previous = ODMRegisterApp call.
lpszDocId - in - A null-terminated = document ID.=20 This is typically obtained by a call to ODMSelectDoc,=20 ODMSelectDocEx or ODMNewDoc. This document must have = been=20 previously opened by a call to ODMOpenDoc.
pdwFlags - in/out - A = pointer to=20 a variable containing flags used on both input and output. On input, 0 = or the=20 following flag:=20

ODM_SILENT - The DMS should not require user interaction = while=20 satisfying the call. If the call cannot be satisfied without user = interaction=20 then an error should be returned.
ODMA 2.0 does not define any = output flags=20 at this time.

activeTime - in - If the application tracks time spent editing the = document=20 then it should pass the number of seconds here. Otherwise it should = pass=20 0xFFFFFFFF.
pagesPrinted - in - If the application tracks the = number of=20 pages printed from this document during the current editing session; = it should=20 pass this number here. Otherwise it should pass = 0xFFFFFFFF.
sessionData -=20 in - The application may pass other information regarding the current = editing=20 session in this parameter. For example, an application might pass the = number=20 of keystrokes that were entered. The calling application is free to = determine=20 the format of this data, so DMSs that rely on this information will = have to=20 coordinate with each application supported. Null should be passed if = the=20 application has no meaningful information to pass through this=20 parameter.
dataLen - in - The length of the data passed in the = sessionData=20 parameter. Ignored if sessionData is Null.

Return value:

ODM_SUCCESS if successful.
ODM_E_NOOPEN if the = document=20 was not previously opened.
ODM_E_USERINT if the = ODM_SILENT=20 flag was specified and the DMS could not satisfy the call without user = interaction.
ODM_E_FILELOCKED if the DMS could not complete = the=20 function because the temporary file provided in ODMOpenDoc is = still=20 opened by the calling application.
ODM_E_FAIL if the DMS is = unable=20 to close the document for any other reason.
ODM_E_HANDLE if = handle=20 was invalid.

ODMGetAlternateContent

ODMSTATUS ODMGetAlternateContent(ODMHANDLE handle, LPSTR lpszDocId, = LPDWORD=20 pdwFlags, LPSTR lpszFormat, LPSTR lpszDocLocation)=20

This function causes the DMS to return an alternate content file = for the=20 specified document. The format of the alternate content file should be = one of=20 the formats returned by the ODM_ALTERNATE_RENDERINGS item in a = previous=20 call to ODMGetDocInfo. The application is responsible for = deleting the=20 alternate content file when it is finished using it.

Parameters:

handle - in - A handle obtained by a previous ODMRegisterApp=20 call.
lpszDocId - in - A null-terminated document ID. This is = typically=20 obtained by a call to ODMSelectDoc, ODMSelectDocEx or=20 ODMNewDoc. The specified document may or may not be open when = this=20 function is called. This document ID refers to the main document for = which an=20 alternate content file is being requested.=20

pdwFlags - in/out - A pointer to a variable containing flags used = on both=20 input and output. On input, zero (0) or the following flag:=20

ODM_SILENT - The DMS should not require user interaction = while=20 satisfying the call. If the call cannot be satisfied without user = interaction=20 then an error should be returned.=20

ODMA 2.0 does not define any output flags at this time.=20

lpszFormat - in - A null-terminated string containing the format = name of=20 the alternate format requested. The Document Format Names section has=20 information on how file formats are identified in ODMA. Typically the = calling=20 application would have first obtained the alternate renderings the DMS = has for=20 the specified document then specified one in this parameter. This is = done by=20 requesting the ODM_ALTERNATE_RENDERINGS attribute in=20 ODMGetDocInfo. However, the application is free to simply = specify the=20 MIME Content Type or File Extension for the format it needs. If the = DMS cannot=20 return the requested format, it will return the ODM_E_NOSUPPORT = status.=20

lpszDocLocation - in/out - A pointer to a buffer of at least=20 ODM_FILENAME_MAX bytes in length, into which the DMS will write = a=20 null-terminated string containing a full path and file name of the = alternate=20 content file. If an error occurs then the contents of the buffer will = be=20 undefined. It is the responsibility of the calling application, not = the DMS,=20 to delete this file when it is finished with it.=20

Optionally the calling application can specify a file extension in = this=20 parameter for the DMS to use in the file specification it returns. If=20 specified, the file extension should be preceded by a period. The DMS = may=20 choose to ignore this information and return a file specification = containing a=20 different file extension.=20

Return value:

ODM_SUCCESS if successful.
ODM_E_ACCESS if the = user does=20 not have access rights to the requested alternate content file or the = main=20 document.
ODM_E_INUSE if the user is currently unable to = access the=20 alternate content file because the main document is checked-out by = another=20 user.
ODM_E_DOCID if the document ID is invalid or refers to = a=20 document that no longer exists.
ODM_E_OFFLINE if the DMS = cannot=20 currently access the document because the user client is=20 off-line.
ODM_E_ARCHIVED if the DMS cannot currently supply = the=20 document content because it has been archived.
ODM_E_USERINT = if the=20 ODM_SILENT flag was specified and the DMS could not make the specified = document available without user interaction.
ODM_E_INVARG if = the=20 value in flags is invalid.
ODM_E_REQARG if a required = parameter=20 isn=92t specified (i.e. lpszFormat or lpszDocLocation=20 ).
ODM_E_NOSUPPORT if the DMS does not support the function = or it=20 cannot return the requested alternate content format for the specified = document.
ODM_E_FAIL if the DMS is unable to make the = document=20 accessible for any other reason.
ODM_E_HANDLE if handle was=20 invalid.

ODMGetDMS

WORD ODMGetDMS( LPCSTR lpszAppId, LPSTR lpszDmsId )=20

This function provides an application a programmatic way to get its = default=20 DMS. The DMS ID of the current DMS for the application will be = returned. This=20 can be either the default DMS from the registry or a DMS previously = set by the=20 application using ODMSetDMS.=20

Parameters:

lpszAppId - in - A pointer to a null-terminated string containing = an=20 Application ID.=20

lpszDmsId - out - A pointer to a buffer to receive the DMS ID of = the=20 default DMS. This buffer must be at least ODM_DMSID_MAX bytes = in=20 length. If an error occurs the value in this buffer is undefined.=20

Returns value:

ODM_SUCCESS if successful.
ODM_E_NODMS if there is = no=20 default DMS registered.

ODM_E_REQARG if either parameter is not = specified.

ODMGetDMSCount

WORD ODMGetDMSCount( )=20

This is an informational function. It will count the number of DMSs = currently registered on the system. This information can be used to = determine=20 the minimum size for the buffer in a call to ODMGetDMSList.=20

Parameters: None.=20

Return value: The number of DMSs currently registered on the = system.=20

ODMGetDMSInfo

ODMSTATUS ODMGetDMSInfo( ODMHANDLE handle, LPSTR lpszDmsId, LPWORD = pwVerNo,=20 LPDWORD pdwExtensions )=20

This function returns information to the application about the = currently=20 active DMS. The application if free to only request the information it = needs.=20

Parameters:

handle - in - A handle obtained by a previous ODMRegisterApp = call.

lpszDmsId - out - If specified by the caller, this should be a = pointer to a=20 buffer of at least ODM_DMSID_MAX bytes in length. A = null-terminated ID=20 identifying the DMS is returned here. This is the same ID embedded in = document=20 IDs returned by this DMS.
pwVerNo - out - If specified by the = caller, this=20 should be a pointer to a variable to receive a version number. The = version of=20 the ODMA API supported by this DMS is returned here.

pdwExtensions - out - If specified by the caller, this should be a = pointer=20 to a variable to receive extension information. Indications of = extensions to=20 the base ODMA API that are supported by this DMS are returned here. If = a DMS=20 does not support any currently defined extensions, then 0 will be = returned.=20 The DMS will return flag values for all the extensions it supports. = The=20 currently defined ODMA extensions are:=20

ODM_EXT_WORKFLOW - The DMS supports the ODMA Workflow=20 Extensions.
ODM_EXT_QUERY - The DMS supports the Query = Extensions=20 defined in ODMA 1.5.

Return value:

ODM_SUCCESS if successful.
ODM_E_HANDLE if handle = was=20 invalid.

ODMGetDMSList

WORD ODMGetDMSList( LPSTR buffer, WORD buffer_size )=20

This function gets a list of the DMSs currently registered on the = system.=20

Parameters:=20

buffer - out - A pointer to a buffer which will receive a list of = DMSs. The=20 format of the list is a collection of Null terminated strings. The = list is=20 terminated by an empty string (i.e. "<id#1>\0<id#2>\0\0"). =

buffer_size - in - Size of buffer . It must be at least = ODMGetDMSCount()=20 * ODM_DMSID_MAX + 1 bytes in length.=20

Return value: The number of DMSs returned in buffer.

ODMGetDocInfo

ODMSTATUS ODMGetDocInfo( ODMHANDLE handle, LPSTR lpszDocId, WORD = item,=20 LPSTR lpszData, WORD dataLen )=20

An application can use this function to obtain information about a = document=20 from the DMS. It is recommended that the DMS not display any user = interface=20 while processing this function.=20

Parameters:=20

handle - in - A handle obtained by a previous ODMRegisterApp call.=20

lpszDocId - in - A null-terminated document ID. This is typically = obtained=20 by a call to ODMSelectDoc , ODMSelectDocEx or ODMNewDoc . The = specified=20 document may or may not be open when ODMGetDocInfo is called.=20

item - in - A single Item Id.=20

Refer to Appendix A for a complete list of Item Ids for document = attributes=20 which can be specified in this parameter.=20

ODM_DMS_DEFINED - Can be used for DMS specific attributes not = explicitly=20 defined by ODMA. The lpszData parameter contains a DMS-specific = indication of=20 the data to be returned. Note that an application must know which DMS = it is=20 talking to and must understand the data indications supported by the = DMS in=20 order to use this item id.=20

lpszData - in/out - On input, ignored if item is anything other = than=20 ODM_DMS_DEFINED . If item is ODM_DMS_DEFINED then lpszData contains an = indication of the data to be returned. It is recommended that the DMS = be able=20 to recognize a null-terminated string containing one of its known = attribute=20 names. On output, the requested data is returned in the buffer pointed = to by=20 lpszData . The data is always null-terminated.=20

dataLen - in - The length of the output buffer pointed to by = lpszData . If=20 the data to be returned is longer than dataLen it will be truncated. = The DMS=20 must return ODM_E_TRUNCATED when the requested data cannot be safely=20 truncated; for example when an attribute containing a document ID or = URL is=20 returned. In these cases the application should recall the function = supplying=20 a larger buffer.=20

Return value:

ODM_SUCCESS if successful.
ODM_E_DOCID if the document ID is = invalid or=20 refers to a document that no longer exists.
ODM_E_OFFLINE if the = DMS cannot=20 currently access the document because the user client is=20 off-line.
ODM_E_TRUNCATED if the application supplied buffer is too = small=20 to hold data that cannot be safely truncated. A DMS cannot truncate an = ODM_URL=20 attribute or any attribute containing an ODMA document = ID.
ODM_E_ITEM if=20 item is invalid or unknown to this DMS.
ODM_E_NOSUPPORT if the DMS = does not=20 support the function or does not support the specified document=20 attribute.
ODM_E_HANDLE if handle was invalid.

ODMGetDocRelation

ODMSTATUS ODMGetDocRelation( ODMHANDLE handle, LPSTR lpszDocId, = LPDWORD=20 pdwFlags, LPSTR lpszLinkedId, LPSTR lpszFormat, LPSTR lpszPreviousId ) =

An application can use this function to retrieve pointers to = document=20 versions linked to a particular document ID. This function would be = used=20 typically as part of retrieving a compound document. It could also be = used=20 when saving an updated component document, for the user to verify = which=20 compound documents will be impacted by any changes.=20

Parameters:=20

handle - in - A handle obtained by a previous ODMRegisterApp = call.

lpszDocId - in - A null-terminated document ID. This is typically = obtained=20 by a call to ODMSelectDoc or ODMNewDoc . The specified document may or = may not=20 be open when ODMGetDocRelation is called.=20

pdwFlags - in/out - A pointer to a variable containing flags used = on both=20 input and output. On input, one or more of the following flags:=20

ODM_REL_PARENT - Return the lpszLinkedId that is a parent of = lpszDocId .=20

ODM_REL_CHILD - Return the lpszLinkedId that is a child of = lpszDocId=20 .=20

ODM_SILENT - The DMS should not require user interaction = while=20 satisfying the call. If the call cannot be satisfied without user = interaction=20 then an error should be returned.=20

Upon return one or more of the following flags may be set by the = DMS unless=20 an error occurred:=20

ODM_REL_NOTORDERED - The default is that the DMS maintains = child=20 links as an ordered list, and that it will use lpszPreviousId to = select the=20 appropriate lpszLinkedId to return. If it is returning them in no = particular,=20 logical, meaningful sequence, the DMS will return this value to warn = the=20 application. A DMS could maintain both ordered and unordered lists, an = example=20 of the former being a book with separate chapters, while the latter = might be a=20 collection such as attached to a workflow.=20

ODM_REL_FIXED - The relationship is frozen between the = particular=20 document versions represented by lpszDocId and lpszLinkedId . This may = also be=20 used to signify that the application and/or the user want to retain = control=20 over updating the link, rather than have the DMS do it.=20

ODM_REL_RELEASED - The link should be maintained to the = Current or=20 Released version of the child document. Released is available in some = DMS to=20 distinguish a version that has been approved for release. If the DMS = does not=20 distinguish between Released and Latest, then Latest is used. The = value is=20 called Released and not Current, to avoid confusion with the version = that is=20 already (currently) linked.=20

ODM_REL_LATEST - The link should be maintained to the latest = version=20 of the child document.=20

lpszLinkedId - out - A pointer to a buffer where the DMS will = return the ID=20 of the next document version that is linked to lpszDocId . This buffer = must be=20 at least ODM_DOCID_MAX bytes in length. If successful then a=20 null-terminated document ID will be returned here. Otherwise the = contents of=20 the buffer will be undefined.=20

lpszFormat - in/out - This is an optional parameter. If specified = it must=20 be a pointer to a buffer of at least ODM_FORMAT_MAX characters. = This=20 buffer contains a null-terminated string naming the file format of the = rendition to be retrieved when the link is followed. Refer to the = Document=20 Format Names section for information on how file formats are = identified in=20 ODMA. This parameter allows the caller to identify the best format for = the=20 intended use of the main document. The requested format may or may not = be the=20 one established in ODMSetDocRelation and may or may not be the = primary=20 editing format. For instance, a graphic may be saved in several = resolutions,=20 one for on-line use and another for printing.=20

On input, this is a hint to the DMS of the preferred format of the = child to=20 be retrieved. If the application does not provide a format it should = set the=20 buffer in lpszFormat to a zero length string. In this case the DMS = should use=20 the format established in ODMSetDocRelation or the primary = format of=20 the document.=20

On output, the DMS should write the format name of the rendition = returned.=20 This may be the closest rendition format the DMS could find. If the = DMS does=20 not record rendition formats when relating documents, then it should = return a=20 zero length string in this buffer.=20

If this parameter is Null, then the DMS should use the format = established=20 in ODMSetDocRelation or the primary format of the child = document (the=20 one used in ODMOpenDoc ).=20

lpszPreviousId - in - A null-terminated document ID. This is = typically=20 returned as lpszLinkedId on a previous call to = ODMGetDocRelation. By=20 making repeated calls to ODMGetDocRelation , the application = obtains a=20 logically ordered list of document ID's that make up a compound = document. To=20 get the first document in a list, provide a zero length, = null-terminated=20 document ID. Null should be passed if the application has no = meaningful=20 information to pass through this parameter.=20

Return value:=20

ODM_SUCCESS if successful.
ODM_E_NORELATION if the = specified document has no related parent or = child.
ODM_E_NOMOREDATA=20 if the end of the list has been passed.
ODM_E_DOCID if a = document ID=20 is invalid or refers to a document that no longer=20 exists.
ODM_E_USERINT if the ODM_SILENT flag was specified = and the=20 DMS could not satisfy the call without user=20 interaction.
ODM_E_NOSUPPORT if the DMS does not support the = function.
ODM_E_INVARG if the value specified in pdwFlags = was=20 invalid.
On input either ODM_REL_PARENT or ODM_REL_CHILD must be = set.=20 ODM_E_REQARG if a required parameter (i.e. lpszLinkedId ) is=20 Null.
ODM_E_HANDLE if handle was = invalid.
ODM_E_FAILif the=20 specified data was invalid or the DMS was unable to accept it for = other=20 reasons.

ODMGetLeadMoniker

ODMSTATUS ODMGetLeadMoniker( ODMHANDLE handle, LPSTR lpszDocId, = LPMONIKER=20 FAR *ppMoniker )=20

Applications that are OLE 2 servers typically form composite = monikers for=20 their OLE links by combining a file moniker representing the document = with one=20 or more item monikers representing a particular section of the = document. This=20 approach often does not work in environments where Document Management = Systems=20 are in use because the filename that the application sees is usually = just=20 temporary. This function lets the application obtain a leading moniker = from=20 the DMS that can be used in place of the file moniker.=20

This function will only be available on platforms supporting OLE 2. = This=20 function may not be supported by some DMSs; those DMSs will return=20 ODM_E_FAIL . In this case the application should go ahead and = use the=20 file moniker as though ODMA were not present. Note that this function = is=20 prototyped in odmacom.h instead of odma.h, so that non-OLE-aware = applications=20 do not have to #include the OLE header files.=20

Parameters:

handle - in - A handle obtained by a previous ODMRegisterApp = call.=20

lpszDocId - in - An ODMA document ID.=20

ppMoniker - out - A leading moniker for the specified document ID = will be=20 returned here if successful. Otherwise Null will be returned here.=20

Return value:=20

ODM_SUCCESS if successful.
ODM_E_FAIL if the DMS = that=20 created the specified document ID does not support OLE moniker=20 building.
ODM_E_DOCID if the document ID is invalid or = refers to a=20 document that no longer exists.
ODM_E_HANDLE if handle is=20 invalid.

ODMNewDoc

ODMSTATUS ODMNewDoc( ODMHANDLE handle, LPSTR lpszDocId, DWORD = dwFlags,=20 LPSTR lpszFormat, LPSTR lpszDocLocation )=20

This function causes the DMS to create a new document profile and = return=20 the document ID for the new document to the calling application. The = DMS may=20 create a temporary or pending document profile; it may not have = actually=20 created a document in its data store. If the DMS displays a dialog box = for=20 this function it should be task/application modal.=20

The document ID returned by the DMS in ODMNewDoc provides a = document=20 context for the application. This document ID must be used in = subsequent ODMA=20 function calls which are needed to complete the process of saving a = new=20 document into a DMS. If the user decides to cancel the operation or = save the=20 document to the native file system, then the application should call=20 ODMCloseDoc or ODMCloseDocEx and throw the document ID = away. The=20 document ID returned by ODMNewDoc may be temporary so the application = must be=20 prepared for the possibility that the DMS will later override it in a = call to=20 ODMSaveAs , ODMSaveAsEx or ODMSaveDoc or = ODMSaveDocEx=20 .=20

The calling sequence for creating a new document, which isn=92t = based on=20 another existing document, is as follows: ODMNewDoc , = ODMSaveAs=20 , ODMOpenDoc then ODMSaveDoc . Finally the document must = be=20 closed with ODMCloseDoc . The above sequence will likely involve user=20 interaction with the DMS displaying one or more dialog boxes.=20

It is possible for an application to create a new document without = any user=20 interaction if the DMS supports it. To accomplish this the calling = application=20 should set the ODM_SILENT flag and use the following call = sequence:=20 ODMNewDoc , {ODMSetDocInfo}, ODMSaveAsEx ,=20 ODMOpenDoc , ODMSaveDocEx and ODMCloseDocEx.=20

Optionally, if the application wishes to pre-set some document = attributes=20 in the Save As dialog box it can call ODMSetDocInfo using the = document=20 ID from ODMNewDoc . This should be done before calling = ODMSaveAs=20 or ODMSaveAsEx . Example attributes the DMS might accept and = perhaps=20 show in its Save As dialog are ODM_NAME , ODM_AUTHOR ,=20 ODM_KEYWORDS and others. After ODMSaveAs is called, the=20 application might wish to call ODMGetDocInfo to see if the user = changed=20 the value of any document attribute it is tracking.=20

Parameters:=20

handle - in - A handle obtained by a previous ODMRegisterApp = call.=20

lpszDocId - out - A pointer to a buffer where the DMS will return = the ID of=20 the new document. This buffer must be at least ODM_DOCID_MAX bytes in = length.=20 If successful then a null-terminated document ID will be returned = here.=20 Otherwise the contents of the buffer will be undefined.=20

dwFlags - in - 0 or a combination of 1 or more of the following = values:=20

ODM_SILENT - The DMS should not require user interaction = while=20 satisfying the call. If the call cannot be satisfied without user = interaction=20 then an error should be returned.=20

lpszFormat - in - A null-terminated string naming the format of the = new=20 document's content. Refer to the Document Format Names section for = information=20 on how file formats are identified in ODMA. Note that this may be = changed=20 later via an ODMSaveAs call.=20

lpszDocLocation - in - Normally DMSs select the location for a new=20 document. But if the document already exists and is large or resides = on=20 read-only storage then the calling application can use this parameter = to tell=20 the DMS where the document is currently stored. This is a hint to the = DMS that=20 the document should be left in this location. Note that some DMSs may = ignore=20 this hint and move the document anyway. A DMS may ignore this = parameter. The=20 calling application should not directly access the document in this = location=20 following the call to ODMNewDoc ; it should use = ODMOpenDoc to=20 obtain a location for subsequent access to the document. In most cases = the=20 application should pass Null in this parameter to allow the DMS to = determine=20 the document's storage location.=20

Return value:=20

ODM_SUCCESS if successful.
ODM_E_CANCEL if the = user=20 cancels the new document creation.
ODM_E_FAIL if the DMS = failed to=20 create the new document.
ODM_E_USERINT if the = ODM_SILENT flag=20 was specified and the DMS could not process the function without user=20 interaction.
ODM_E_APPSELECT if the user indicated that he = wants to=20 select the document's filename using the application's regular file = selection=20 facilities rather than using the DMS. The application should just = display its=20 regular selection dialog.
ODM_E_OFFLINE if the DMS has no = local data=20 store and is off-line from its server; generally the caller should = treat this=20 the same as ODM_E_APPSELECT.
ODM_E_HANDLE if handle = was=20 invalid.

ODMOpenDoc

ODMSTATUS ODMOpenDoc( ODMHANDLE handle, DWORD flags, LPSTR = lpszDocId, LPSTR=20 lpszDocLocation )=20

This function causes the DMS to make a document available to the=20 application. It performs any necessary pre-processing (mapping network = drives,=20 checking security, etc.) and then returns to the application a = temporary=20 filename that can be used to access the document during the current = session.=20 Note that this function does not open the document file; it merely = makes the=20 file temporarily available to the calling application. The application = can=20 then open, read, write and close the file as needed.=20

If ODM_MODIFYMODE is requested, the DMS may refuse the = request if=20 the user has view-only rights ( ODM_E_ACCESS ) or if the = document is=20 currently checked-out ( ODM_E_INUSE ) to another user. It is=20 recommended that the application retry the request specifying = ODM_VIEWMODE in=20 both cases so that the user can at least view the document and = possibly save=20 changes to a new document.=20

Applications are encouraged to give the user the same level of = feedback if=20 a DMS based document is opened for read-only access as they would for = a=20 document based in the platform=92s native file system.=20

When the application is finished using a file which was opened with = either=20 ODM_MODIFYMODE or ODM_VIEWMODE it must call = ODMCloseDoc=20 or ODMCloseDocEx . When an application is finished using a file = that=20 was obtained with the ODM_REFCOPY option it does not have to = call=20 ODMCloseDoc or ODMCloseDocEx , however, it must delete = the=20 temporary file.=20

If an application has opened a document in ODM_VIEWMODE and = wishes=20 to switch to ODM_MODIFYMODE, it must first call = ODMCloseDoc or=20 ODMCloseDocEx then call ODMOpenDoc requesting=20 ODM_MODIFYMODE. The same is true if the application wishes to = switch=20 from ODM_MODIFYMODE to ODM_VIEWMODE . The=20 ODM_E_ALREADYOPENED error status is returned by the DMS if the=20 application attempts to re-open a document that it has already opened = in=20 either of these two modes.=20

Parameters:

handle - in - A handle obtained by a previous ODMRegisterApp = call.=20

flags - in - One or more of the following flags:=20

ODM_MODIFYMODE - The DMS should make the document available = in a=20 modifiable mode. This mode is assumed if ODM_VIEWMODE or=20 ODM_REFCOPY is not explicitly requested.=20

ODM_VIEWMODE - The DMS should make the document available in = a=20 view-only mode. Any changes made to the document will not be = transferred back=20 to the document repository. If ODM_VIEWMODE and = ODM_MODIFYMODE=20 are both specified in the same call the ODM_E_INVARG error will = be=20 returned.=20

ODM_REFCOPY - The DMS should make a read-only reference copy = of the=20 document available to the calling application. The DMS must return a = different=20 filespec in lpszDocLocation each time this function is called. It is = invalid=20 to specify ODM_REFCOPY with either ODM_VIEWMODE or=20 ODM_MODIFYMODE . The calling application must delete any = reference copy=20 file obtained using this option and it should not call = ODMCloseDoc or=20 ODMCloseDocEx .=20

ODM_SILENT - The DMS should not require user interaction = while=20 satisfying the call. If the call cannot be satisfied without user = interaction=20 then an error should be returned.=20

lpszDocId - in - A document ID. This is typically obtained by a = call to=20 ODMSelectDoc or ODMNewDoc .=20

lpszDocLocation - out - A pointer to a buffer of at least=20 ODM_FILENAME_MAX bytes in length. The DMS will store in this = buffer a=20 null-terminated string indicating where the caller can access the = document=20 during the current session. Typically, this will be the full path/file = name of=20 the specified document, but some document formats may dictate another = type of=20 location such as a directory name. If an error occurs then the = contents of the=20 buffer will be undefined.=20

Return value:

ODM_SUCCESS if successful.
ODM_E_ACCESS if the = user does=20 not have the access rights requested (for example, modify mode was = requested=20 but the user only has view rights to the = document).
ODM_E_INUSE if=20 the user is currently unable to access the document in modify mode = because it=20 is checked-out by another user. This differs from ODM_E_ACCESS = in that=20 it is expected that the user might be able to access the document in = the=20 specified mode at some point in the future.
ODM_E_DOCID if = the=20 document ID is invalid or refers to a document that no longer=20 exists.
ODM_E_OFFLINE if the DMS cannot currently access the = document because the user client is off-line.
ODM_E_ARCHIVED = if the=20 DMS cannot currently supply the document content because it has been=20 archived.
ODM_E_USERINT if the ODM_SILENT flag was specified = and the=20 DMS could not make the specified document available without user=20 interaction.
ODM_E_INVARG if both ODM_OPENMODE and=20 ODM_VIEWMODE have been specified or if either of those modes = was=20 specified with ODM_REFCOPY .
ODM_E_ALREADYOPENED if = the=20 application attempts to reopen a document with ODM_MODIFYMODE = or=20 ODM_VIEWMODE that it has already opened with either of these = modes. See=20 below for one possible exception.
ODM_E_FAIL if the DMS is = unable to=20 make the document accessible for any other = reason.
ODM_E_HANDLE if=20 handle was invalid.

If the application attempts to open a document for = ODM_VIEWMODE that=20 it already has opened for ODM_VIEWMODE , then the DMS may = either return=20 the ODM_E_ALREADYOPNED error status or ODM_SUCCESS along = with=20 the previously returned temporary file specification. The DMS should = not=20 return ODM_SUCCESS in this case unless it is maintaining a = reference=20 count of the number of times this application has opened the document = for=20 ODM_VIEWMODE access. The application must call = ODMCloseDoc or=20 ODMCloseDocEx once for every time the document was successfully = opened.=20 On the last close call the DMS will delete the temporary file.=20

ODMQueryCapability

ODMSTATUS ODMQueryCapability( ODMHANDLE handle, LPCSTR lpszDmsId, = DWORD=20 function, DWORD item, DWORD flags );=20

This function is used by a client application to determine if a DMS = supports a given ODMA function, or a specific action code in = ODMActivate or a=20 specific event code in ODMSetDocEvent . It can also be used to = determine if=20 the DMS supports getting or setting a given document attribute using=20 ODMGetDocInfo or ODMSetDocInfo .=20

Parameters:=20

handle - in - A handle obtained by a previous ODMRegisterApp call.=20

lpszDmsId - in - A pointer to a null terminated string containing = the DMS=20 ID of the DMS to query. A DMS ID can be obtained by calling = ODMGetDMSList ,=20 ODMGetDMS or ODMGetDMSInfo . If this parameter is set to Null, then = the=20 default DMS is queried (the one opened with ODMRegisterApp ).=20

function - in - One of the following function ids:=20

ODM_QC_ACTIVATE ODM_QC_QUERYEXECUTE
ODM_QC_CLOSEDOC ODM_QC_QUERYGETRESULTS
ODM_QC_CLOSEDOCEX ODM_QC_SAVEAS
ODM_QC_GETALTERNATECONTENT ODM_QC_SAVEASEX
ODM_QC_GETDMSINFO ODM_QC_SAVEDOC
ODM_QC_GETDOCINFO ODM_QC_SAVEDOCEX
ODM_QC_GETDOCRELATION ODM_QC_SELECTDOC
ODM_QC_GETLEADMONIKER ODM_QC_SELECTDOCEX
ODM_QC_NEWDOC ODM_QC_SETALTERNATECONTENT
ODM_QC_OPENDOC ODM_QC_SETDOCEVENT
ODM_QC_QUERYCLOSE ODM_QC_SETDOCRELATION

item - in - Optional item, action code or event, depending on the = function=20 being queried. Specify a value of 0 to query if the DMS supports the = function.=20 If ODM_QC_ACTIVATE is specified in function , then an action value can = be=20 specified in this parameter. If ODM_QC_GETDOCINFO or ODM_QC_SETDOCINFO = is=20 specified in function , then an item code can be specified in this = parameter.=20 If function is ODM_QC_SETDOCEVENT then an event code can be specified = in item=20 . See the individual functions for the constants that can be used in = the item=20 parameter.=20

flags - in - Many ODMA functions have a flags parameter. This = parameter can=20 be used to test if a DMS supports specified input or output flags for = a=20 function. For example an application might test to see if a DMS can = support=20 unattended operations by specifying the ODM_SILENT flag here. It is = ignored if=20 the function specified in the function parameter does not have a flags = parameter. Return value:=20

ODM_SUCCESS if the DMS supports the specified function or = the=20 specified item/action/event.
ODM_E_NODMS if a DMS ID was = specified=20 in lpszDmsId which the ODMA Connection Manager could not=20 find.
ODM_E_NOSUPPORT if the DMS does not support the = function=20 specified in function .
ODM_E_ITEM if the DMS does not = support the=20 item, action code or event code specified in item . =
ODM_E_USERINT=20 if ODM_SILENT was specified in flags and the DMS cannot satisfy = the=20 function specified in function without user=20 interaction.
ODM_E_REQARG if nothing was specified in the = function=20 parameter.
ODM_E_INVARG if flags was invalid for the = function=20 specified in function .
ODM_E_HANDLE if handle was=20 invalid.
ODM_E_FAIL if the DMS was unable to process the = function=20 for other reasons.

ODMQueryClose

ODMSTATUS ODMQueryClose( ODMHANDLE handle, LPCSTR queryId )=20

This function is used by a client application to indicate that it = has=20 finished using the query and that the involved DMS(s) should release = any=20 resources and/or memory for the result set.=20

Parameters:=20

handle - in - A handle obtained by a previous ODMRegisterApp = call.=20

queryId - in - A pointer to a null-terminated string containing a = query id=20 returned by a previous call to ODMQueryExecute.=20

Return value:=20

ODM_SUCCESS on success, where upon the queryId is no longer=20 valid.
ODM_E_HANDLE if handle was = invalid.
ODM_E_FAIL if=20 one or more input values are invalid.

ODMQueryExecute =

ODMSTATUS ODMQueryExecute( ODMHANDLE handle, LPCSTR lpszQuery, = DWORD flags,=20 LPCSTR lpszDMSList, LPSTR queryId )=20

This function will pass the lpszQuery along to each DMS as = specified by the=20 flags parameter. It will return a query ID that can be used in = subsequent=20 calls to ODMQueryGetResults and ODMQueryClose . If this function is=20 successful, the calling application must eventually call ODMQueryClose = to=20 release this query.=20

Parameters:

handle - in - A handle obtained by a previous ODMRegisterApp call.=20

lpszQuery - in - The query to be processed by one or more DMSs. = Refer to=20 the Query Syntax section for the exact syntax specification.=20

flags - in - One of the following:=20

ODM_ALL - All DMS providers on this workstation.
ODM_SPECIFIC - = A set of=20 specific DMSs to run query against.

lpszDMSList - in - Valid only if value of flags is ODM_SPECIFIC . A = buffer=20 containing a list of DMSs. The format for the list is a collection of=20 null-terminated strings. The list is terminated by an empty string = (i.e.=20 "<id#1>\0<id#2>\0\0").=20

queryId - out - An id to be used for search identification to = subsequent=20 calls. This is the query ID a client application uses to communicate = with=20 Connection Manager, which in turn maps the ID to a DMS-specific query = ID. For=20 the case of multiple DMS=92s, this ID is mapped to multiple = DMS-specific query=20 IDs. Such mapping is handled by Connection Manager and is transparent = to the=20 client application. The buffer size for queryId should be at least=20 ODM_QUERYID_MAX bytes.=20

Return value:=20

ODM_SUCCESS if successful.
ODM_E_CANCEL if the user canceled the = query.
ODM_E_PARTIALSUCCESS if one or more DMSs returned a = successful=20 status and one or more DMSs return a failure.
ODM_E_HANDLE if = handle was=20 invalid.
ODM_E_FAIL if invalid data was sent in, or no DMS was = specified or=20 all DMSs failed to process the query.

ODMQueryGetResults
ODMSTATUS=20 ODMQueryGetResults( ODMHANDLE handle, LPCSTR queryId, LPSTR lpszDocId, = LPSTR=20 lpszDocName, WORD docNameLen, LPWORD pwDocCount )=20

This function will fetch pwDocCount number of documents at a time.=20

Parameters:

handle - in - A handle obtained by a previous ODMRegisterApp call.=20

queryId - in - A pointer to a null-terminated string containing a = query id=20 returned by a previous call to ODMQueryExecute.=20

lpszDocId - out - A pointer to a buffer to receive document Ids for = documents that satisfied the search referenced in queryId . This = buffer needs=20 to be at least ( ODM_DOCID_MAX * pwDocCount ) + 1 bytes in length.=20

lpszDocName - out - A pointer to a buffer to receive ODM_NAME = attribute=20 values for documents that satisfied the search referenced in queryId . = This=20 buffer needs to be at least ( docNameLen * pwDocCount ) + 1 bytes in = length.=20

docNameLen - in - The length of a document name including the=20 null-terminator.=20

pwDocCount - in/out - A pointer to a variable used to pass a = document=20 count. On input, pwDocCount contains the number of documents expected = by the=20 client application. On output, pwDocCount contains the actual number = of=20 documents returned by this function.=20

Return value:=20

ODM_SUCCESS if no error and there are more rows=20 available.
ODM_E_NOMOREDATA if there is no more data. The contents = of=20 lpszDocId , lpszDocName and docCount are undefined.
ODM_E_REQARG if = a=20 required parameter is not specified.
ODM_E_HANDLE if handle was=20 invalid.
ODM_E_FAIL if an error occurs.

ODMQueryInterface

HRESULT ODMQueryInterface( ODMHANDLE handle, LPSTR lpszDocId, = REFIID riid,=20 LPVOID FAR *ppvObj )=20

An application can use this function to get a COM interface from an = ODMA=20 provider. All ODMA providers support the IODMDocMan interface and some = support=20 IODMDocMan2 and IODMQuery . Individual DMSs may support other = interfaces as=20 well. Note that this function is prototyped in odmacom.h instead of = odma.h, so=20 that non-COM-aware applications do not have to #include the header = files that=20 define interface IDs.=20

Parameters:=20

handle - in - A handle obtained by a previous ODMRegisterApp call.=20

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

riid - in - The interface to be obtained from the DMS.=20

ppvObj - out - If the requested interface is supported by the DMS = then it=20 is returned here. Otherwise ppvObj is set to Null.=20

Return value:=20

S_OK if successful.
E_INVALIDARG if handle or lpszDocId is=20 invalid.
E_NOINTERFACE if the requested interface is not supported = by the=20 DMS.
E_ACCESSDENIED if the DMS refuses the calling = application.
E_FAIL=20 if the DMS fails to initialize itself or fails for any other reason.=20

ODMRegisterApp

ODMSTATUS ODMRegisterApp( ODMHANDLE FAR *pHandle, WORD version, = LPSTR=20 lpszAppId, DWORD dwEnvData, LPVOID pReserved )=20

ODMRegisterApp registers an application with the appropriate = Document=20 Management System (DMS) and returns a session handle that can be used = in calls=20 to other ODMA functions.=20

An application normally calls this function before calling any = other ODMA=20 function. Some functions such as ODMGetDMSCount , ODMGetDMSList , = ODMGetDMS=20 and ODMSetDMS can be called before ODMRegisterApp . These are used by=20 applications that wish to control which DMS they will access when=20 ODMRegisterApp is called.=20

A task may call ODMRegisterApp more than once. Each call will = return a=20 different handle, each of which must be released with ODMUnRegisterApp = .=20

Parameters:

pHandle - out - If successful, a session handle is returned here = that can=20 be used in calls to other ODMA functions. If the registration fails = then 0 is=20 returned here.=20

version - in - Specifies the version of the API required by the=20 application. 100 should be passed to indicate version 1.0, 150 for = version=20 1.5, 200 for version 2.0, etc. The macro ODM_API_VERSION can be used = to get=20 the current version number at compile time. All versions of the ODMA = API will=20 be downward compatible, so this should be interpreted as the minimum = version=20 number that the calling application expects the DMS to support. If the = DMS=20 does not support the specified version or a higher version then it = should=20 return an error.=20

lpszAppId - in - A unique identifier for the application. The = maximum=20 length for this string is ODM_APPID_MAX , which is 16 characters = including the=20 terminating Null. The application ID cannot begin with a digit. It is=20 recommended that a Windows application use the application class name = it uses=20 in the registry as its ODMA Application ID, but this is not required.=20

dwEnvData - in - Environment data. On Windows platforms this is a = Window=20 handle for a parent window in the calling application. The DMS may use = this=20 window handle as the parent window for any dialogs or other windows it = displays in response to ODMA calls. This handle must remain valid for = the=20 duration of the ODMA session (i.e. until ODMUnRegisterApp is called).=20

pReserved - in - Reserved for future use. Must be set to Null.=20

Return value:=20

ODM_SUCCESS if successful.
ODM_E_NODMS if no Document = Management System=20 has been registered for the calling application.
ODM_E_CANTINIT if = a DMS=20 is registered for the calling application, but it fails to initialize=20 itself.
ODM_E_VERSION if the DMS does not support the requested = version of=20 the API.
ODM_E_REFUSED if the DMS has been configured to refuse = ODMA access=20 for the calling application.

This is not considered an error condition. If this status is = returned, the=20 application should simply act as if ODMA is not on the system.=20

ODMSaveAs

ODMSTATUS ODMSaveAs( ODMHANDLE handle, LPSTR lpszDocId, LPSTR = lpszNewDocId,=20 LPSTR lpszFormat, ODMSAVEASCALLBACK pcbCallBack, LPVOID pInstanceData = )=20

This function causes the DMS to return a new document ID for a = document=20 that is based on an existing document. An application would typically = call=20 this function in response to the user selecting a File Save As menu = option.=20 ODMSaveAs causes the DMS to display options to the user for selecting = the=20 destination for the new document. This might be an entirely new = document or a=20 new version of the current document. Any dialog box displayed by the = DMS=20 should be task/application modal.=20

Often the application will want to present additional options to = the user=20 at this point such as different file formats or encrypting the = document. This=20 is accomplished via the pcbCallBack parameter. ODMA implementers = should=20 provide a method for users to access this function if desired. For = example,=20 the DMS may show a dialog that includes an Options button. If the user = clicks=20 this button, the DMS would call the application's callback function = which=20 would give the application a chance to display other save options.=20

Note that following a successful call to ODMSaveAs the calling = application=20 may have two different document IDs to work with. This is different = than the=20 situation with ODMSaveDoc where the new ID replaces the old one in the = current=20 session. The state of the document specified by the old ID remains the = same=20 after the call. The document specified by the new ID will be in the = closed=20 state following the call. A typical sequence of operations an = application=20 might follow in response to the user selecting File | Save As would = be:=20

  1. Application passes the currently open document's ID to ODMSaveAs = . If an=20 empty string is returned for the new ID, then the application should = call=20 ODMSaveDoc with the current document ID to indicate to the DMS that = document=20 should be saved in the document repository. If a new ID for the = document is=20 returned then continue with the steps below.=20
  2. Application calls ODMOpenDoc on the new ID. This returns a new = filename=20 for the document.=20
  3. Application saves the document to the new filename and then = calls=20 ODMSaveDoc on the new ID to indicate to the DMS that the new = document should=20 be saved in the document repository.=20
  4. Application calls ODMCloseDoc on the old ID.=20
  5. The application can now forget about the old ID and use the new = ID for=20 all subsequent operations on the file. When the current session is = completed=20 it will call ODMCloseDoc on the new ID.

Parameters:=20

handle - in - A handle obtained by a previous ODMRegisterApp call.=20

lpszDocId - in - A null-terminated document ID. This is typically = obtained=20 by a call to ODMSelectDoc , ODMSelectDocEx or ODMNewDoc . This = document may or=20 may not be open at the time that ODMSaveAs is called. Its open status = will=20 remain the same after this call.=20

lpszNewDocId - out - A pointer to a buffer where the DMS will = return the ID=20 of the new document. This buffer must be at least ODM_DOCID_MAX bytes = in=20 length. If successful then a null-terminated document ID will be = returned=20 here, unless the document is saved with the current ID. In this case = the first=20 byte of this buffer will be set to Null and 0 will be returned. = Otherwise the=20 contents of the buffer will be undefined.=20

lpszFormat - in - A null-terminated string naming the format in = which the=20 application expects to save the document. This may be passed as a = parameter to=20 the pcbCallBack function which may return a different format. Refer to = the=20 Document Format Names section for information on how file formats are=20 identified in ODMA.=20

pcbCallBack - in - A pointer to a callback function that can be = used by the=20 application to make other saving options available to the user. Any UI = presented by this callback function should be task modal. The function = should=20 return a pointer to a format string which may or may not be the same = as the=20 original format string. This parameter may be null if the application = does not=20 wish to present any options. Under Microsoft Windows the = procedure-instance=20 address of the callback function (obtained from MakeProcInstance ) = should be=20 used. The callback function's interface is as follows:=20

LPSTR __cdecl SaveAsCallBack(DWORD dwEnvData, LPSTR lpszFormat, = LPVOID=20 pInstanceData)=20

dwEnvData - in - Environment data. On Windows platforms this is a = Window=20 handle for a parent window to associate with the callback function's = display.=20 If the DMS displayed a dialog in response to the ODMSaveAs call then = it should=20 pass the window handle for that dialog. Otherwise it should pass the = window=20 handle obtained from the ODMRegisterApp call. The callback function = may use=20 this window handle as the parent window for any dialogs or other = windows it=20 displays.=20

lpszFormat - The currently selected document format. The DMS should = allocate at least ODM_FORMAT_MAX for this buffer. If the application = handling=20 the callback wishes to update this DMS buffer and return its pointer = back as=20 the value of the callback, then it should take care to not overwrite = the=20 buffer=92s length.=20

pInstanceData - The instance data passed from the calling = application.=20

pInstanceData - in - A pointer to caller context information that = will be=20 passed to the pcbCallBack function. This data will not be accessed by = ODMA.=20

Return value:=20

ODM_SUCCESS if successful.
ODM_E_CANCEL if the user cancels the = creation=20 of the new document.
ODM_E_DOCID if the document ID is invalid or = refers to=20 a document that no longer exists.
ODM_E_APPSELECT if the user = selected to=20 save the document as a non-profiled document.
ODM_E_OFFLINE if the = DMS has=20 no local data store and is off-line from its server; generally the = caller=20 should treat this the same as ODM_E_APPSELECT .
ODM_E_FAIL if the = DMS is=20 unable to display its Save As dialog box or create the new=20 document.
ODM_E_HANDLE if handle was invalid.

ODMSaveAsEx

ODMSTATUS ODMSaveAsEx( ODMHANDLE handle, LPSTR lpszDocId, LPSTR=20 lpszNewDocId, LPSTR lpszFormat, ODMSAVEASCALLBACK pcbCallBack, LPVOID=20 pInstanceData, LPDWORD pdwFlags )=20

The ODMSaveAsEx function extends ODMSaveAs by adding a pdwFlags = parameter=20 to allow for unattended document creation. It also can be called = without first=20 calling ODMNewDoc .=20

This function causes the DMS to return a new document ID for a = document=20 that is based on an existing document. An application would typically = call=20 this function in response to the user selecting a File Save As menu = option.=20 ODMSaveAsEx causes the DMS to display options to the user for = selecting the=20 destination for the new document. This might be an entirely new = document or a=20 new version of the current document. Any dialog box displayed by the = DMS=20 should be task/application modal.=20

Often the application will want to present additional options to = the user=20 at this point such as different file formats or encrypting the = document. This=20 is accomplished via the pcbCallBack parameter. ODMA implementers = should=20 provide a method for users to access this function if desired. For = example,=20 the DMS may show a dialog that includes an Options button. If the user = clicks=20 this button, the DMS would call the application's callback function = which=20 would give the application a chance to display other save options.=20

Note that following a successful call to ODMSaveAsEx the calling=20 application may have two different document IDs to work with. This is=20 different than the situation with ODMSaveDoc or ODMSaveDocEx where the = new ID=20 replaces the old one in the current session. The state of the document = specified by the old ID remains the same after the call. The document=20 specified by the new ID will be in the closed state following the = call. A=20 typical sequence of operations an application might follow in response = to the=20 user selecting File | Save As would be:=20

  1. Application passes the currently open document's ID to = ODMSaveAsEx . If=20 an empty string is returned for the new ID, then the application = should call=20 ODMSaveDoc or ODMSaveDocEx with the current document ID to indicate = to the=20 DMS that document should be saved in the document repository. If a = new ID=20 for the document is returned then continue with the steps below.=20
  2. Application calls ODMOpenDoc on the new ID. This returns a new = filename=20 for the document.=20
  3. Application saves the document to the new filename and then = calls=20 ODMSaveDoc or ODMSaveDocEx on the new ID to indicate to the DMS that = the new=20 document should be saved in the document repository.=20
  4. Application calls ODMCloseDoc or ODMCloseDocEx on the old ID.=20
  5. The application can now forget about the old ID and use the new = ID for=20 all subsequent operations on the file. When the current session is = completed=20 it will call ODMCloseDoc or ODMCloseDocEx on the new ID.

Parameters:

handle - in - A handle obtained by a previous ODMRegisterApp call.=20

lpszDocId - in - A null-terminated document ID. This is typically = obtained=20 by a call to ODMSelectDoc , ODMSelectDocEx or ODMNewDoc . This = document may or=20 may not be open at the time that ODMSaveAsEx is called. Its open = status will=20 remain the same after this call.=20

This lpszDocId parameter can optionally be set to NULL if the = calling=20 application did not first call ODMNewDoc . In this case, the DMS will = return a=20 document ID in the buffer specified in lpszNewDocId .=20

lpszNewDocId - out - A pointer to a buffer where the DMS will = return the ID=20 of the new document. This buffer must be at least ODM_DOCID_MAX bytes = in=20 length. If successful then a null-terminated document ID will be = returned=20 here, unless the document is saved with the current ID. In this case = the first=20 byte of this buffer will be set to Null and 0 will be returned. = Otherwise the=20 contents of the buffer will be undefined.=20

lpszFormat - in - A null-terminated string naming the format in = which the=20 application expects to save the document. This may be passed as a = parameter to=20 the pcbCallBack function which may return a different format. Refer to = the=20 Document Format Names section for information on how file formats are=20 identified in ODMA.=20

pcbCallBack - in - A pointer to a callback function that can be = used by the=20 application to make other saving options available to the user. Any UI = presented by this callback function should be task modal. The function = should=20 return a pointer to a format string which may or may not be the same = as the=20 original format string. This parameter may be null if the application = does not=20 wish to present any options. Under Microsoft Windows the = procedure-instance=20 address of the callback function (obtained from MakeProcInstance) = should be=20 used. The callback function's interface is as follows:=20

LPSTR __cdecl SaveAsCallBack(DWORD dwEnvData, LPSTR lpszFormat, = LPVOID=20 pInstanceData)=20

dwEnvData - in - Environment data. On Windows platforms this is a = Window=20 handle for a parent window to associate with the callback function's = display.=20 If the DMS displayed a dialog in response to the ODMSaveAsEx call then = it=20 should pass the window handle for that dialog. Otherwise it should = pass the=20 window handle obtained from the ODMRegisterApp call. The callback = function may=20 use this window handle as the parent window for any dialogs or other = windows=20 it displays.=20

lpszFormat - The currently selected document format. The DMS should = allocate at least ODM_FORMAT_MAX for this buffer. If the application = handling=20 the callback wishes to update this DMS buffer and return its pointer = back as=20 the value of the callback, then it should take care to not overwrite = the=20 buffer=92s length.=20

pInstanceData - The instance data passed from the calling = application.=20

pInstanceData - in - A pointer to caller context information that = will be=20 passed to the pcbCallBack function. This data will not be accessed by = ODMA.=20

pdwFlags - in/out - A pointer to a variable containing flags used = on both=20 input and output. On input, 0 or the following flag:=20

ODM_SILENT - The DMS should not require user interaction while = satisfying=20 the call. If the call cannot be satisfied without user interaction = then an=20 error should be returned. If the DMS has enough information to create = a new=20 document then it should return ODM_SUCCESS .=20

ODMA 2.0 does not define any output flags at this time.=20

Return value:=20

ODM_SUCCESS if successful.
ODM_E_CANCEL if the user cancels the = creation of the new document.
ODM_E_DOCID if the document ID is = invalid or=20 refers to a document that no longer exists.
ODM_E_APPSELECT if the = user=20 selected to save the document as a non-profiled = document.
ODM_E_OFFLINE if=20 the DMS has no local data store and is off-line from its server; = generally the=20 caller should treat this the same as ODM_E_APPSELECT = .
ODM_E_USERINT if the=20 ODM_SILENT flag was specified and the DMS does not support document = creation=20 without user interaction or the DMS does not have enough information = to create=20 the document without user interaction.
ODM_E_FAIL if the DMS is = unable to=20 display its Save As dialog box or create the new = document.
ODM_E_HANDLE if=20 handle was invalid.

ODMSaveDoc

ODMSTATUS ODMSaveDoc( ODMHANDLE handle, LPSTR lpszDocId, LPSTR = lpszNewDocId=20 )=20

This function tells the DMS that the document should be saved to = the=20 document repository. An application would typically call this function = after=20 saving changes to the temporary file returned by ODMOpenDoc . A new = document=20 ID is returned to the application which should be used for all = subsequent=20 operations on the document. This ID replaces the previous document ID = in the=20 current session. The new ID may or may not be the same as the original = ID. It=20 will usually be the same unless the DMS saved the document as a new = version or=20 as a new document. If the new ID is different from the previous ID = then the=20 previous ID cannot be used subsequently without doing an ODMOpenDoc on = it.=20
Parameters:=20

handle - in - A handle obtained by a previous ODMRegisterApp call.=20

lpszDocId - in - A document ID. This is typically obtained by a = call to=20 ODMSelectDoc or ODMNewDoc . This document must have been previously = opened in=20 modify mode by a call to ODMOpenDoc .=20

lpszNewDocId - out - A pointer to a buffer where the DMS will = return the=20 new ID of the document. This buffer must be at least ODM_DOCID_MAX = bytes in=20 length. If successful then a null-terminated document ID will be = returned=20 here. Otherwise the contents of the buffer will be undefined.=20

Return value:=20

ODM_SUCCESS if successful.
ODM_E_NOOPEN if the document wasn=92t = previously opened with ODMOpenDoc .
ODM_E_OPENMODE if the document = was not=20 previously opened in modifiable mode.
ODM_E_FAIL if the DMS is = unable to=20 save the document to the document repository.
ODM_E_HANDLE if = handle was=20 invalid.

ODMSaveDocEx

ODMSTATUS ODMSaveDocEx( ODMHANDLE handle, LPSTR lpszDocId, LPSTR=20 lpszNewDocId, LPDWORD pdwFlags )=20

This function tells the DMS that the document should be saved to = the=20 document repository. ODMSaveDocEx is basically the same as ODMSaveDoc = , except=20 it has a pwdFlags parameter. This provides the application with more = control=20 during the document creation or save process. There is an ODM_SILENT = flag that=20 facilitates unattended document creation or saving. Some DMSs display = a user=20 interface when saving a document (i.e. to have the user specify = revision or=20 version information). This flag allows the calling application to = suppress=20 this UI if necessary or to influence it, if the DMS should allow that. =

An application would typically call this function after saving = changes to=20 the temporary file returned by ODMOpenDoc . A new document ID is = returned to=20 the application which should be used for all subsequent operations on = the=20 document. This ID replaces the previous document ID in the current = session.=20 The new ID may or may not be the same as the original ID. It will = usually be=20 the same unless the DMS saved the document as a new version or as a = new=20 document. If the new ID is different from the previous ID then the = previous ID=20 cannot be used subsequently without doing an ODMOpenDoc on it.=20

Parameters:=20

handle - in - A handle obtained by a previous ODMRegisterApp call.=20

lpszDocId - in - A document ID. This is typically obtained by a = call to=20 ODMSelectDoc or ODMNewDoc . This document must have been previously = opened in=20 modify mode by a call to ODMOpenDoc .=20

lpszNewDocId - out - A pointer to a buffer where the DMS will = return the=20 new ID of the document. This buffer must be at least ODM_DOCID_MAX = bytes in=20 length. If successful then a null-terminated document ID will be = returned=20 here. Otherwise the contents of the buffer will be undefined.=20

pdwFlags - in/out - A pointer to a variable containing flags used = on both=20 input and output. On input, 0 or one or more of the following flags:=20

ODM_SILENT - The DMS should not require user interaction while = satisfying=20 the call. If the call cannot be satisfied without user interaction = then an=20 error should be returned.=20

ODM_VERSION_SAME - If saving an existing document the DMS should = keep the=20 version information the same. If the DMS does not support versioning = this flag=20 should be ignored.=20

ODM_VERSION_MAJOR - If saving an existing document the DMS should = increment=20 the major version number. If the DMS displays a dialog this flag is an = indication of how the dialog might be initialized. If the DMS does not = support=20 versioning this flag should be ignored.=20

ODM_VERSION_MINOR - If saving an existing document the DMS should = increment=20 the minor version number. A DMS that doesn=92t support minor versions = should=20 just treat this like a major version. If the DMS displays a dialog = this flag=20 is an indication of how the dialog might be initialized.=20

Upon return, one of the following flags must be set by the DMS = unless an=20 error occurred:=20

ODM_VERSION_SAME - The DMS either kept the version the same or it = does not=20 support versioning.=20

ODM_VERSION_CHANGED =96 The DMS changed the version number, = possibly with=20 user interaction.=20

Return value:=20

ODM_SUCCESS if successful.
ODM_E_CANCEL if the DMS displayed a = dialog=20 and the user canceled the save operation.
ODM_E_NOOPEN if the = document=20 wasn=92t previously opened with ODMOpenDoc .
ODM_E_OPENMODE if the = document=20 was not previously opened in modifiable mode.
ODM_E_USERINT if the=20 ODM_SILENT flag was specified and the DMS could not save the document = without=20 user interaction or the DMS does not have enough information to create = a new=20 document without user interaction.
ODM_E_INVARG if the value in = pdwFlags=20 was invalid. More than one of the ODM_VERSION* flags was = set.
ODM_E_OFFLINE=20 if the DMS has no local data store and is off-line from its=20 server.
ODM_E_FAIL if the DMS is unable to save the document to the = document repository.
ODM_E_HANDLE if handle was invalid.

ODMSelectDoc

ODMSTATUS ODMSelectDoc( ODMHANDLE handle, LPSTR lpszDocId, LPDWORD = pdwFlags=20 )=20

This function causes the DMS to return a document ID representing a = document that has been selected for some action. Typically the DMS = will=20 display searching and other dialogs that allow the user to = interactively=20 select a document from among those managed by the DMS. An application = would=20 typically call this function whenever the user needs to select a = document to=20 be opened or imported. Any dialog box displayed by the DMS should be=20 task/application modal.=20

If the user elects to open a document in ODM_VIEWMODE , then the=20 application should open the document with ODMOpenDoc specifying = ODM_VIEWMODE .=20 If a user selects ODM_MODIFYMODE , the application is free to open the = document with either the ODM_VIEWMODE or ODM_REFCOPY options if it = only needs=20 read-only access to it.=20

Parameters:=20

handle - in - A handle obtained by a previous ODMRegisterApp call.=20

lpszDocId - out - A pointer to a buffer where the DMS will return = the ID of=20 the document selected by the user. This buffer must be at least = ODM_DOCID_MAX=20 bytes in length. If successful then a null-terminated document ID will = be=20 returned here. Otherwise the contents of the buffer will be undefined. =

pdwFlags - in/out - A pointer to a variable containing flags used = on both=20 input and output. On input, 0 or one or more of the following flags:=20

ODM_SILENT - The DMS should not require user interaction while = satisfying=20 the call. If the call cannot be satisfied without user interaction = then an=20 error should be returned.=20

ODM_VIEWMODE - On input this is a hint to the DMS that the = application will=20 only be opening the selected document for read-only access. Support = for this=20 input flag is optional for the DMS. A DMS that supports this might = modify its=20 document selection user interface appropriately and set only the = ODM_VIEWMODE=20 flag on output.=20

Upon return, one of the following flags will be set unless an error = occurred:=20

ODM_MODIFYMODE - The user indicated that the selected document = should be=20 opened in a modifiable mode.=20

ODM_VIEWMODE - The user indicated that the selected document should = be=20 opened in a view-only mode.=20

Return value:

ODM_SUCCESS if successful.
ODM_E_CANCEL if the user does not = make a=20 selection.
ODM_E_APPSELECT if the user indicated that he wants to = make a=20 selection using the application's regular file selection facilities = rather=20 than using the DMS. The application should just display its regular = selection=20 dialog.
ODM_E_OTHERAPP if the user selected a document and the DMS = allowed=20 the user to open it with another application or its native = application;=20 generally the caller should treat this the same as ODM_E_CANCEL=20 .
ODM_E_USERINT if the ODM_SILENT flag was specified and the DMS = could not=20 select a document without user interaction.
ODM_E_OFFLINE if the = DMS has no=20 local data store and is off-line from its server; generally the caller = should=20 treat this the same as ODM_E_APPSELECT .
ODM_E_FAIL if the DMS is = unable to=20 select a document for any other reason.
ODM_E_HANDLE if handle was = invalid.=20

In the case that ODM_E_APPSELECT is returned and a document is = opened=20 through the application's regular file selection facilities, the = following=20 behaviors are recommended:=20

  1. File | Save and File | Close should be handled as though the DMS = were=20 not present.=20
  2. File | Save As should he handled through ODMA (specifically = through the=20 ODMSaveAs function). This will allow documents to be imported into = the DMS.=20 The exception to this is if the application allows the user to = select a DMS=20 from within its native file system Save As dialog.

ODMSelectDocEx

ODMSTATUS ODMSelectDocEx( ODMHANDLE handle, LPSTR lpszDocIds, = LPWORD=20 pwDocIdsLen, LPWORD pwDocCount, LPDWORD pdwFlags, LPSTR = lpszFormatFilter )=20

ODMSelectDocEx extends ODMSelectDoc . This function causes the DMS = to=20 return one or more document IDs representing documents that have been = selected=20 for some action. An application may call this function if it allows = the user=20 to open multiple documents in one command. Typically the DMS will = display=20 searching and other dialogs that allow the user to interactively = select=20 documents from among those managed by the DMS. If a DMS does not = support=20 multiple selection, then it is free to limit the user to selecting = only one=20 document. Any dialog box displayed by the DMS should be = task/application=20 modal.=20

The ODMSelectDocEx function has an lpszFormatFilter parameter which = will=20 allow an application to specify to a DMS what file types the user = should=20 select. This can provide for closer integration between the = application and=20 the DMS.=20

If the user elects to open a document in ODM_VIEWMODE , then the=20 application should open the document with ODMOpenDoc specifying = ODM_VIEWMODE .=20 If a user selects ODM_MODIFYMODE , the application is free to open the = document with either the ODM_VIEWMODE or ODM_REFCOPY options if it = only needs=20 read-only access to it.=20

Parameters:=20

handle - in - A handle obtained by a previous ODMRegisterApp call.=20

lpszDocIds - out - A pointer to a buffer where the DMS will return = the IDs=20 of the documents selected by the user. If successful then a series of=20 null-terminated document IDs will be returned here, with the last ID = followed=20 by an extra Null terminator. Otherwise the contents of the buffer will = be=20 undefined. This buffer must be at least ODM_DOCID_MAX * pwDocCount + 1 = bytes=20 in length.=20

pwDocIdsLen - in/out - On input this parameter is a pointer to a = variable=20 that specifies the length of the buffer pointed to by lpszDocIds . If = the call=20 fails because the buffer is not big enough, this variable is updated = by the=20 DMS to contain the required buffer size.=20

pwDocCount - in/out - On input this parameter is a pointer to a = variable=20 that specifies the maximum number of documents the calling application = can=20 handle in the buffer specified in lpszDocIds . The DMS should not = allow the=20 user to select more than this number of documents. On output the DMS = must=20 update this value to contain the actual number of documents returned = in=20 lpszDocIds .=20

pdwFlags - in/out - A pointer to a variable containing flags used = on both=20 input and output. On input, 0 or one or more of the following flags:=20

ODM_SILENT - The DMS should not require user interaction while = satisfying=20 the call. If the call cannot be satisfied without user interaction = then an=20 error should be returned.=20

ODM_VIEWMODE - On input this is a hint to the DMS that the = application will=20 only be opening the selected document for read-only access. Support = for this=20 input flag is optional for the DMS. A DMS that supports this might = modify its=20 document selection user interface appropriately and set only the = ODM_VIEWMODE=20 flag on output.=20

ODM_TEMPLATES - The DMS should, if possible, only show the user = document=20 templates. This option allows the application to access document = templates=20 which the DMS maintains for work-groups or the current user.=20

Upon return, one of the following flags will be set unless an error = occurred:=20

ODM_MODIFYMODE - The user indicated that the selected document(s) = should be=20 opened in a modifiable mode. If the DMS user interface allows the user = to=20 select some documents for modify access and others for view-only = access, then=20 it is recommended that this flag be set.=20

ODM_VIEWMODE - The user indicated that the selected document(s) = should be=20 opened in a view-only mode.=20

lpszFormatFilter - in - If specified, a long pointer to a buffer = containing=20 a sequence of one or more null-terminated format names. The last = sequence must=20 be terminated with two null characters. The information in = lpszFormatFilter is=20 a hint to DMS of which file types or templates the application would = like the=20 user to select. The DMS may use this format list as is, augment it = with other=20 formats, or ignore it altogether. The user is free to select any = document=20 type, so the calling application must be prepared for the possibility = that the=20 user will select a file format that isn=92t specified in the = lpszFormatFilter=20 parameter. Refer to the Document Format Names section for information = on how=20 file formats are identified in ODMA.=20

Return value:=20

ODM_SUCCESS if successful.
ODM_E_CANCEL if the user does not = make a=20 selection. ODM_E_APPSELECT if the user indicated that he wants to make = a=20 selection using the application's regular file selection facilities = rather=20 than using the DMS. The application should just display its regular = selection=20 dialog.
ODM_E_OTHERAPP if the user selected a document and the DMS = allowed=20 the user to open it with another application or its native = application;=20 generally the caller should treat this the same as ODM_E_CANCEL=20 .
ODM_E_USERINT if the ODM_SILENT flag was specified and the DMS = could not=20 select a document without user interaction.
ODM_E_NOSUPPORT if the = DMS does=20 not support the function.
ODM_E_INVARG if the variables pointed to = by=20 pwDocCount or pwDocIdsLen have value of 0.
ODM_E_REQARG if a = required=20 parameter is not specified (i.e. lpszDocIds , pwDocIdsLen or = pwDocCount=20 .
ODM_E_TRUNCATED if the buffer specified in lpszDocIds is too = small to=20 hold the selected document Ids. When this error occurs the pwDocIdsLen = variable contains the required buffer size.
ODM_E_OFFLINE if the = DMS has no=20 local data store and is off-line from its server; generally the caller = should=20 treat this the same as ODM_E_APPSELECT .
ODM_E_HANDLE if handle was = invalid.

ODMSetAlternateContent

ODMSTATUS ODMSetAlternateContent( ODMHANDLE handle, LPSTR = lpszDocId,=20 LPDWORD pdwFlags, LPSTR lpszFormat, LPSTR lpszDocLocation )=20

This function allows an application to create or update an = alternate=20 content file for the specified document in the DMS. The application = can either=20 provide the alternate content file or it can instruct the DMS to = create or=20 update the content file itself. The format of the alternate content = file is=20 specified in the ODMSetAlternateContent function call. The DMS may or = may not=20 accept the specified alternate content file. The application is = responsible=20 for deleting the alternate content file when it is finished using it.=20

Parameters:=20

handle - in - A handle obtained by a previous ODMRegisterApp call.=20

lpszDocId - in - A null-terminated document ID. This is typically = obtained=20 by a call to ODMSelectDoc , ODMSelectDocEx or ODMNewDoc . The = specified=20 document may or may not be open when this function is called. This = document ID=20 refers to the main document for which an alternate content file is = being=20 created or updated.=20

pdwFlags - in/out - A pointer to a variable containing flags used = on both=20 input and output. On input, zero (0) or one or more of following = flags:=20

ODM_SILENT - The DMS should not require user interaction while = satisfying=20 the call. If the call cannot be satisfied without user interaction = then an=20 error should be returned.=20

ODM_ALT_DELETE - The DMS should delete the specified alternate = content file=20 if the user has the appropriate access rights.=20

ODMA 2.0 does not define any output flags at this time.=20

lpszFormat - in - A null-terminated string containing the format = name of=20 the alternate format file which is being created or updated. Refer to = the=20 Document Format Names section for information on how file formats are=20 identified in ODMA. If the DMS cannot accept the specified format it = will=20 return the ODM_E_NOSUPPORT status.=20

lpszDocLocation - in - A pointer to a null-terminated string = containing the=20 file specification of the alternate content file. The file referenced = in this=20 parameter should be in the format indicated in the lpszFormat = parameter. This=20 parameter may be set to Null if the calling application wants the DMS = to=20 create the alternate rendition file itself. If the DMS cannot create = or update=20 the alternate content file then it will return ODM_E_NOSUPPORT . It is = the=20 responsibility of the calling application, not the DMS, to delete this = file=20 when it is finished with it.=20

Return value:

ODM_SUCCESS if successful.
ODM_E_ACCESS if the user does not = have the=20 appropriate access rights to create, update or delete an alternate = content=20 file for the main document.
ODM_E_INUSE if the user is currently = unable to=20 create, update or delete the alternate content file because the main = document=20 is checked-out by another user.
ODM_E_DOCID if the document ID is = invalid=20 or refers to a document that no longer exists.
ODM_E_OFFLINE if the = DMS=20 cannot currently access the document because the user client is=20 off-line.
ODM_E_ARCHIVED if the DMS cannot currently update the = alternate=20 content because the main document has been archived.
ODM_E_USERINT = if the=20 ODM_SILENT flag was specified and the DMS could not make the specified = document available without user interaction.
ODM_E_INVARG if = lpszFormat is=20 Null.
ODM_E_NOSUPPORT if the DMS does not support the function or = it cannot=20 accept or generate the requested alternate content format for the = specified=20 document.
ODM_E_FAIL if the DMS is unable to complete the function = for any=20 other reason.
ODM_E_HANDLE if handle was invalid.

ODMSetDMS

ODMSTATUS ODMSetDMS( LPCSTR lpszAppId, LPCSTR lpszDmsId )=20

This function provides an application a programmatic way to set its = default=20 DMS. ODMSetDMS does not change any default DMS settings in the = registry. The=20 DMS ID set using this function will take effect the next time the = application=20 calls ODMRegisterApp . It will not alter the default DMS in any = existing=20 session the application has already established with ODMRegisterApp .=20

Parameters:=20

lpszAppId - in - A pointer to a null-terminated string containing = an=20 Application ID.=20

lpszDmsId - in - A pointer to a null-terminated string containing a = DMS ID.=20 This is the DMS the application will be connected to when it calls=20 ODMRegisterApp . If this parameter is set to Null the Connection = Manager will=20 set the application to use to the default DMS in the registry.=20

Return value:=20

ODM_SUCCESS if successful.
ODM_E_NODMS if the DMS specified in = lpszDmsId=20 is not valid.
ODM_E_REQARG if the lpszAppId parameter is Null.

ODMSetDocEvent

ODMSTATUS ODMSetDocEvent( ODMHANDLE handle, LPSTR lpszDocId, DWORD = flags,=20 DWORD event, LPVOID lpData, DWORD dwDataLen, LPSTR lpszComment )=20

An application can use this function to pass event information = about the=20 document to the DMS. Events like printing, sending, posting can be = sent by the=20 application to the DMS. The DMS may or may not accept the event = information.=20

Parameters:=20

handle - in - A handle obtained by a previous ODMRegisterApp call.=20

lpszDocId - in - A null-terminated document ID. This is typically = obtained=20 by a call to ODMSelectDoc . The specified document may or may not be = open when=20 ODMSetDocEvent is called.=20

flags - in - 0 or a combination of 1 or more of the following = values:=20

ODM_SILENT - The DMS should not require user interaction while = satisfying=20 the call. If the call cannot be satisfied without user interaction = then an=20 error should be returned.=20

event - in - One of the following:=20

ODM_EVENT_PRINTED - The document was printed.
ODM_EVENT_POSTED - = The=20 document was posted into a discussion group.
ODM_EVENT_SENT - The = document=20 was mailed.
ODM_EVENT_FAXED - The document was = faxed.
ODM_EVENT_ROUTED=20 - The document was routed using a workflow system.
ODM_EVENT_COPIED = - The=20 document was copied or imported into another DMS or=20 application.
ODM_EVENT_CONVERTED - The document was used as source = to a=20 format conversion or scanning (i.e. OCR) operation that resulted in = the=20 creation of a new document or another version or rendition of an = existing=20 document.
ODM_EVENT_DMSDEFINED - The lpData parameter contains a=20 DMS-specific indication of the data being passed as well as the data = itself.=20 Note that an application must know which DMS it is talking to and must = understand the data indications supported by that DMS in order to use = this=20 event name.

lpData - in - The application may pass other information regarding = the=20 event in this parameter. The calling application and the DMS will have = to=20 coordinate on the format of this information. Null should be passed if = the=20 application has no meaningful information to pass through this = parameter.=20

dwDataLen - in - The length of the data passed in the lpData = parameter.=20 Ignored if lpData is Null.=20

lpszComment - in - An optional, null-terminated, string containing = either a=20 user supplied or application generated comment. Set this parameter to = Null if=20 a comment isn=92t specified.=20

Return value:=20

ODM_SUCCESS if successful.
ODM_E_DOCID if the document ID is = invalid or=20 refers to a document that no longer exists.
ODM_E_OFFLINE if the = DMS cannot=20 currently process the event for the document because the user client = is=20 off-line.
ODM_E_ITEM if event is invalid or not supported by the=20 DMS.
ODM_E_NOSUPPORT if the DMS does not support the=20 function.
ODM_E_USERINT if the ODM_SILENT flag was specified and = the DMS=20 could not process the call without user interaction.
ODM_E_REQARG = if lpData=20 is specified and dwDataLen is 0.
ODM_E_HANDLE if handle was=20 invalid.
ODM_E_FAIL if the DMS was unable to process the function = for other=20 reasons.

ODMSetDocInfo =

ODMSTATUS ODMSetDocInfo( ODMHANDLE handle, LPSTR lpszDocId, WORD = item,=20 LPSTR lpszData )=20

An application can use this function to pass information about the = document=20 to the DMS. The DMS may or may not accept the information; most DMSs = validate=20 attributes like document types and authors against predefined tables.=20

It is recommended that the DMS not display any user interface while = processing this function.=20

Parameters:=20

handle - in - A handle obtained by a previous ODMRegisterApp call.=20

lpszDocId - in - A null-terminated document ID. This is typically = obtained=20 by a call to ODMSelectDoc or ODMNewDoc . The specified document may or = may not=20 be open when ODMSetDocInfo is called.=20

item - in - A single Item Id.=20

Refer to Appendix A for a complete list of Item Ids for document = attributes=20 which can be specified in this parameter.=20

ODM_DMS_DEFINED - Can be used for DMS specific attributes not = explicitly=20 defined by ODMA. The lpszData parameter contains a DMS-specific = indication of=20 the data being passed as well as the data itself. Note that an = application=20 must know which DMS it is talking to and must understand the data = indications=20 supported by the DMS in order to use this item id.=20

lpszData - in - Pointer to the data being passed to the DMS. Must = be=20 null-terminated. If item is ODM_DMS_DEFINED then the value in this = parameter=20 must contain both an indication of the attribute to set and the data = value. It=20 is recommended that the DMS be able to recognize a null-terminated = string=20 containing one of its known attribute names, followed by an equal sign = delimiter character, followed by the data value.=20

Return value:

ODM_SUCCESS if successful.
ODM_E_ACCESS if the user does not = have the=20 appropriate access rights to set the specified document=20 attribute.
ODM_E_DOCID if the document ID is invalid or refers to a = document that no longer exists.
ODM_E_OFFLINE if the DMS cannot = currently=20 access the document because the user client is off-line.
ODM_E_ITEM = if item=20 is invalid or unknown to this DMS.
ODM_E_NOSUPPORT if the DMS does = not=20 support the function or does not support setting the specified = document=20 attribute.
ODM_E_HANDLE if handle was invalid.
ODM_E_FAIL if the = specified data was invalid or the DMS was unable to accept it for = other=20 reasons.

ODMSetDocRelation=20

ODMSTATUS ODMSetDocRelation( ODMHANDLE handle, LPSTR lpszDocId, = LPDWORD=20 pdwFlags, LPSTR lpszLinkedId, LPSTR lpszFormat, LPSTR lpszPreviousId)=20

An application can use this function to maintain relationship and = hierarchy=20 information in the DMS about a compound document structure that it is=20 manipulating external to the DMS. This function would typically be = used as=20 part of saving a new or updated version of the master document, or = when the=20 user requests the application to review and update the version that = has been=20 linked to.=20

Parameters:=20

handle - in - A handle obtained by a previous ODMRegisterApp call.=20

lpszDocId - in - A null-terminated document ID. This is typically = obtained=20 by a call to ODMSelectDoc or ODMNewDoc . The specified document may or = may not=20 be open when ODMSetDocRelation is called.=20

pdwFlags - in/out - A pointer to variable containing flags used on = both=20 input and output. On input, one or more of the following flags:=20

ODM_REL_PARENT - Create a link between the documents represented in = lpszDocId and lpszLinkedId with lpszDocId as the parent. This flag = cannot be=20 used in combination with ODM_REL_CHILD or ODM_REL_NONE .=20

ODM_REL_CHILD - Create a link between the documents represented in=20 lpszDocId and lpszLinkedId with lpszDocId as the child. This flag = cannot be=20 used in combination with ODM_REL_PARENT or ODM_REL_NONE .=20

ODM_REL_NONE - If a relationship exists between the documents = represented=20 by lpszDocId and lpszLinkedId then delete it. This flag cannot be used = in=20 combination with ODM_REL_PARENT or ODM_REL_CHILD .=20

ODM_REL_FIXED - The relationship is frozen between the particular = document=20 versions represented by lpszDocId and lpszLinkedId . This may also be = used to=20 signify that the application and/or the user want to retain control = over=20 updating the link, rather than have the DMS do it.=20

ODM_REL_RELEASED - The link should be maintained to the Current or = Released=20 version of the child document. Released is available in some DMS to=20 distinguish a version that has been approved for release. If the DMS = does not=20 distinguish between Released and Latest, then Latest is used. The = value is=20 called Released and not Current, to avoid confusion with the version = that is=20 already (currently) linked.=20

ODM_REL_LATEST - The link should be maintained to the latest = version of the=20 child document.=20

ODM_SILENT - The DMS should not require user interaction while = satisfying=20 the call. If the call cannot be satisfied without user interaction = then an=20 error should be returned.=20

ODMA 2.0 does not define any output flags at this time.=20

lpszLinkedId - in - A null-terminated document ID. This is = typically=20 obtained by a call to ODMSelectDoc , ODMNewDoc , ODMSaveAs , = ODMSaveDoc ,=20 ODMGetDocRelation or ODMGetDocInfo . The specified document may or may = not be=20 open when ODMSetDocRelation is called.=20

lpszFormat - in/out - This is an optional parameter. If specified = it must=20 be a pointer to a buffer of at least ODM_FORMAT_MAX characters. This = buffer=20 contains a null-terminated string naming the file format of the = rendition to=20 be retrieved when the link is followed. Refer to the Document Format = Names=20 section for information on how file formats are identified in ODMA. = This=20 parameter allows the caller to identify the best format for the = intended use=20 of the main document. For instance, a graphic may be saved in several=20 resolutions, one for on-line use and another for printing.=20

On input, this is a hint to the DMS of the preferred format of the = child to=20 be linked to. If the application does not provide a format it should = set the=20 buffer in lpszFormat to a zero length string. In this case the DMS = should use=20 the primary format of the document.=20

On output, the DMS should write the format name of the rendition it = used.=20 This may be the closest rendition format the DMS could find. If the = DMS does=20 not record rendition formats when relating documents, then it should = return a=20 zero length string in this buffer.=20

If this parameter is Null, then the DMS should use the primary = format of=20 the child document (the one used in ODMOpenDoc ).=20

lpszPreviousId - in - A null-terminated document ID. When adding = child=20 documents, if the DMS maintains positional information in a logically = ordered=20 list of linked documents, then the application is requesting the DMS = to add=20 lpszLinkedId after lpszPreviousId and re-link whatever was the "next = Id" now=20 to lpszLinkedId . To add lpszLinkedDocId as the first document in a = list,=20 provide a zero length, null-terminated document ID. Null should be = passed if=20 the application has no meaningful information to pass through this = parameter,=20 or to add lpszLinkedDocId as the last document in the list.=20

Return value:=20

ODM_SUCCESS if successful.
ODM_W_NOACTION if the link already = existed=20 and was configured in the requested manner.
ODM_E_NORELATION if the = application requests deletion of a relationship that does not=20 exist.
ODM_E_ACCESS if the user does not have the appropriate = access rights=20 to create, update or delete this document relationship.
ODM_E_INUSE = if the=20 user is currently unable to create, update or delete this document=20 relationship because one or more of the related documents is = checked-out by=20 another user.
ODM_E_DOCID if a document ID is invalid or refers to = a=20 document that no longer exists.
ODM_E_USERINT if the ODM_SILENT = flag was=20 specified and the DMS could not satisfy the call without user = interaction.=20
ODM_E_NOSUPPORT if the DMS does not support the = function.
ODM_E_INVARG=20 if the value specified in flags was invalid.
ODM_E_REQARG if = lpszDocId or=20 lpszLinkedId is not specified.
ODM_E_HANDLE if handle was invalid. =
ODM_E_FAIL if the specified data was invalid or the DMS was unable = to=20 accept it for other reasons.

ODMUnRegisterApp

void ODMUnRegisterApp( ODMHANDLE handle )=20

An application that previously registered itself with a DMS via=20 ODMRegisterApp should call this function when it is finished using the = DMS.=20 This would typically be done when the application is shutting down. = After this=20 call returns, the DMS session handle is no longer valid and cannot be = used for=20 subsequent calls to ODMA functions.=20

Parameters:=20

handle - in - A handle obtained by a previous ODMRegisterApp call.=20

Return value:=20

None.=20

DMS Interface =

A DMS interfaces with ODMA through a function called = ODMGetODMInterface and=20 through three COM interfaces; IODMDocMan , IODMQuery and IODMDocMan2 . = When an=20 application calls the ODMA connection manager's ODMRegisterApp = function, the=20 connection manager calls the appropriate DMS's ODMGetODMInterface = function to=20 establish a connection with the DMS.=20

The IODMDocMan interface implements all of the basic document = management=20 functionality defined by the ODMA 1.0 specification. The IODMQuery = interface=20 implements the query extension of the ODMA 1.5 specification. The = IODMDocMan2=20 interface implements the extended document management functionality = defined in=20 the ODMA 2.0 specification. The methods of these interfaces each = correspond=20 directly with a function from the ODMA API section of this document. = (For=20 example, the SelectDoc method of the IODMDocMan interface corresponds = to the=20 ODMSelectDoc function.) With only one exception, the functionality of = each=20 method is completely detailed by the description of its corresponding = ODMA API=20 function. For that reason, this section of the document only provides = a list=20 of each method with its prototype and no further details. (The one = exception=20 is the QueryExecute method of the IODMQuery interface. Additional = details,=20 only important to the DMS=92s implementation of this method, are = provided=20 below.)=20

ODMGetODMInterface

HRESULT ODMGetODMInterface( REFIID riid, LPVOID FAR *ppvObj, = LPUNKNOWN=20 pUnkOuter, LPVOID pReserved, LPSTR lpszAppId, DWORD dwEnvData )=20

The ODMA connection manager calls this function to get an interface = from a=20 DMS. This function is not available to ODMA-aware applications. The = DMS=20 returns its status using OLE HRESULT codes which the Connection = Manager then=20 maps to ODMA status codes.=20

Parameters:=20

riid - in - ID of the interface being requested. This will = typically be=20 IID_IODMDocMan , which all ODMA DMS providers must support, or other = ODMA=20 interfaces. The Connection Manager may also pass through calls for = other=20 interfaces from the client.=20

ppvObj - out - The requested interface should be returned here. If = the DMS=20 cannot return the requested interface, ppvObj should be set to Null.=20

pUnkOuter - in - The controlling IUnknown interface for the = aggregate=20 object. ODMA providers must support aggregation.=20

pReserved - in - Reserved for future use. It must always be set to = Null.=20

lpszAppId - in - The ID of the calling application. See = ODMRegisterApp .=20

dwEnvData - in - Environment specific data. On Windows platforms = this will=20 be a window handle from the calling application. See ODMRegisterApp .=20

Return value:=20

S_OK if successful.
E_NOINTERFACE if the requested interface is = not=20 supported.
E_ACCESSDENIED if the DMS refuses the application = specified in=20 lpszAppId . The Connection Manager will return ODM_E_REFUSED to the = calling=20 application.
E_FAIL if the DMS fails to initialize itself. The = Connection=20 Manager will return ODM_E_CANTINIT to the calling=20 application.
E_ODM_VERSION if the DMS does not support the = requested=20 version of the API.

IODMDocMan=20 Interface

SelectDoc
STDMETHOD_( ODMSTATUS, SelectDoc ) ( THIS_ = LPSTR=20 lpszDocId, LPDWORD pdwFlags ) PURE;=20

OpenDoc
STDMETHOD_( ODMSTATUS, OpenDoc ) ( THIS_ DWORD = flags,=20 LPSTR lpszDocId, LPSTR lpszDocLocation) PURE;=20

SaveDoc
STDMETHOD_( ODMSTATUS, SaveDoc ) ( THIS_ LPSTR = lpszDocId,=20 LPSTR lpszNewDocId) PURE;=20

CloseDoc
STDMETHOD_( ODMSTATUS, CloseDoc ) ( THIS_ LPSTR=20 lpszDocId, DWORD activeTime, DWORD pagesPrinted, LPVOID sessionData,=20 WORD dataLen) PURE;=20

NewDoc
STDMETHOD_( ODMSTATUS, NewDoc ) ( THIS_ LPSTR = lpszDocId,=20 DWORD dwFlags, LPSTR lpszFormat, LPSTR lpszDocLocation ) PURE;=20

SaveAs
STDMETHOD_( ODMSTATUS, SaveAs ) ( THIS_ LPSTR = lpszDocId,=20 LPSTR lpszNewDocId, LPSTR lpszFormat, = ODMSAVEASCALLBACK pcbCallBack,=20 LPVOID pInstanceData) PURE;=20

Activate
STDMETHOD_( ODMSTATUS, Activate ) ( THIS_=20 WORD action, LPSTR lpszDocId) PURE;=20

GetDocInfo
STDMETHOD_( ODMSTATUS, GetDocInfo ) ( THIS_ = LPSTR=20 lpszDocId, WORD item, LPSTR lpszData, WORD dataLen ) PURE;=20

SetDocInfo
STDMETHOD_( ODMSTATUS, SetDocInfo ) ( THIS_ = LPSTR=20 lpszDocId, WORD item, LPSTR lpszData ) PURE;=20

GetDMSInfo
STDMETHOD_( ODMSTATUS, GetDMSInfo ) ( THIS_ = LPSTR=20 lpszDmsId, LPWORD pwVerNo, LPDWORD pdwExtensions) PURE;=20

GetLeadMoniker
STDMETHOD_( ODMSTATUS, GetLeadMoniker ) ( = THIS_=20 LPSTR lpszDocId, LPMONIKER FAR *ppMoniker) PURE;=20

IODMQuery=20 Interface

QueryExecute
STDMETHOD_( ODMSTATUS, QueryExecute ) ( = THIS_=20 LPCSTR lpszQuery, LPSTR dmsQueryId ) PURE;=20

Additional Notes: Upon success, the string returned in dmsQueryId = should be=20 of the form: "::ODMA\DM_ID\DMS_SPECIFIC_QUERY_ID>". Note that this = query ID=20 is not necessarily the one returned to the client application. Note = also that=20 multiple query IDs from different DMSs will be mapped to the same = query ID for=20 a single query call from the client application. The dmsQueryId string = may be=20 up to ODM_DOCID_MAX bytes in length.=20

The return value of ODM_E_PARTIALSUCCESS is a valid return value = for=20 ODMQueryExecute but is not a valid return value for this method.=20

QueryGetResults
STDMETHOD_( ODMSTATUS, QueryGetResults ) = ( THIS_=20 LPCSTR queryId, LPSTR lpszDocId, LPSTR lpszDocName, = WORD docNameLen,=20 LPWORD pwDocCount ) PURE;=20

QueryClose
STDMETHOD_( ODMSTATUS, QueryClose )( THIS_=20 LPCSTR dmsQueryId ) PURE;=20

IODMDocMan2=20 Interface

CloseDocEx
STDMETHOD_( ODMSTATUS, CloseDocEx ) ( THIS_ = LPSTR=20 lpszDocId, LPDWORD pdwFlags, DWORD activeTime, DWORD pagesPrinted, = LPVOID=20 sessionData, WORD dataLen) PURE;=20

SaveAsEx
STDMETHOD_( ODMSTATUS, SaveAsEx ) ( THIS_ LPSTR = lpszDocId, LPSTR lpszNewDocId, LPSTR lpszFormat,=20 ODMSAVEASCALLBACK pcbCallBack, LPVOID pInstanceData, LPDWORD = pdwFlags)=20 PURE;=20

SaveDocEx
STDMETHOD_( ODMSTATUS, SaveDocEx ) ( THIS_ = LPSTR=20 lpszDocId, LPSTR lpszNewDocId, LPDWORD pdwFlags) PURE;=20

SelectDocEx
STDMETHOD_( ODMSTATUS, SelectDocEx ) ( THIS_ = LPSTR=20 lpszDocIds, LPWORD pwDocIdsLen, LPWORD pwDocCount, LPDWORD pdwFlags, = LPSTR=20 lpszFormatFilter ) PURE;=20

QueryCapability
STDMETHOD_( ODMSTATUS, QueryCapability ) = ( THIS_=20 LPCSTR lpszDmsId, DWORD function, DWORD item, DWORD flags ) PURE;=20

SetDocEvent
STDMETHOD_( ODMSTATUS SetDocEvent ) ( THIS_ = LPSTR=20 lpszDocId, DWORD flags, DWORD event, LPVOID lpData, DWORD dwDataLen, = LPSTR=20 lpszComment) PURE;=20

GetAlternateContent
STDMETHOD_( ODMSTATUS = GetAlternateContent ) (=20 THIS_ LPSTR lpszDocId, LPDWORD pdwFlags, LPSTR lpszFormat, LPSTR=20 lpszDocLocation ) PURE;=20

SetAlternateContent
STDMETHOD_( ODMSTATUS = SetAlternateContent )=20 ( THIS_ LPSTR lpszDocId, LPDWORD pdwFlags, LPSTR lpszFormat, LPSTR=20 lpszDocLocation ) PURE;=20

GetDocRelation
STDMETHOD_( ODMSTATUS GetDocRelation ) ( = THIS_=20 LPSTR lpszDocId, LPDWORD pdwFlags, LPSTR lpszLinkedId, LPSTR = lpszFormat, LPSTR=20 lpszPreviousId ) PURE;=20

SetDocRelation
STDMETHOD_( ODMSTATUS SetDocRelation ) ( = THIS_=20 LPSTR lpszDocId, LPDWORD pdwFlags, LPSTR lpszLinkedId, LPSTR = lpszFormat, LPSTR=20 lpszPreviousId ) PURE;=20

Binding to the API
Windows 3.x, Windows 95 and Windows NT

The ODMA connection manager, ODMA.DLL (Windows 3.x) or ODMA32.DLL = (Windows=20 95 and NT), and a corresponding link library, ODMA.LIB (Windows 3.x) = or=20 ODMA32.LIB (Windows 95 and NT), will be made freely available to any=20 application vendor wishing to use them. Applications can choose either = of the=20 methods described below to bind to ODMA:=20

1. Link to ODMA.LIB/ODMA32.LIB. Applications choosing this approach = will=20 need to install a copy of ODMA.DLL/ODMA32.DLL into the Windows system=20 directory at the time the application is installed unless a newer copy = of=20 ODMA.DLL/ODMA32.DLL already resides there. At startup time the = application can=20 call ODMRegisterApp to determine whether or not an ODMA provider is = present=20 for the calling application.=20

2. Dynamically load ODMA.DLL/ODMA32.DLL at startup time with a call = to=20 LoadLibrary. With this approach the application has to call = GetProcAddress to=20 get a pointer to each ODMA function it will call, but the application = does not=20 have to do anything related to ODMA at installation time. If=20 ODMA.DLL/ODMA32.DLL doesn't exist or if ODMRegisterApp returns = ODM_E_NODMS=20 then the application knows that no ODMA provider is present for the = calling=20 application.=20

There is currently no thunk layer that exists to allow a 32-bit = application=20 and a 16-bit DMS, or vice versa, to interact with each other.=20

Installing a DMS
Windows 3.x, Windows 95 and = Windows NT=20

The ODMA connection manager, ODMA.DLL for Windows 3.x and = ODMA32.DLL for=20 Windows NT and Windows 95, will be provided to all DMS vendors that = want to=20 support the ODMA specification. These DLLs will serve as a common = entry point=20 for applications that wish to call ODMA functions. Its implementation = of=20 ODMRegisterApp will figure out which DMS is registered for default use = by the=20 calling application. It will then load the appropriate DMS's DLL and = pass=20 through the function call. All other ODMA function calls that do not = include a=20 document ID will be passed to this default DMS.=20

When an ODMA call is made that includes a document ID, the ODMA = connection=20 manager will determine which DMS created the ID. If that DMS has not = been=20 initialized yet by the calling application, the connection manager = will call=20 the provider's ODMGetODMInterface function and will then pass through = the=20 current ODMA function call.=20

As part of its installation, a DMS should check whether a copy of = ODMA.DLL=20 and/or ODMA32.DLL already exists in the Windows System directory. (On = Windows=20 NT the ODMA32.DLL belongs in the System32 directory.) If the DLLs do = not exist=20 or if the DMS has newer versions then it should copy its version of = ODMA.DLL=20 and/or ODMA32.DLL to the Windows System directory. As of ODMA 2.0, the = Connection Manager DLLs will contain version resource information. = Next the=20 DMS should register with the ODMA connection manager by adding one or = more=20 keys to the registration database.=20

Each DMS must add a subkey to the root level ODMA key. This subkey = should=20 be named the same as the DMS's DMS ID, and the subkey's value should = specify=20 the location of the DLL containing the DMS's ODMA entry points. For = example,=20 suppose a DMS with a DMS ID of DDD implemented its ODMA entry points = in=20 H:\ABC\XYZ.DLL. It would add the following key and value to the = registration=20 database under the HKEY_CLASSES_ROOT key:=20

ODMA\DDD =3D H:\ABC\XYZ.DLL for Windows 3.x
ODMA32\DDD =3D = H:\ABC\XYZ.DLL=20 for Win32 (i.e. WinNT & Windows 95)

The DMS ID is limited to 8 characters and is often cryptic. The DMS = must=20 add a FullName subkey under its DMS ID subkey which provides the full = name of=20 the DMS. The DMS is free to include any information necessary in the = FullName=20 (i.e. vendor name, version and platform). For example, our fictional = DMS with=20 the DDD DMS ID would define FullName like this:=20

ODMA\DDD\FullName =3D "Dynamic Document Depot V1.0 for=20 Windows"
ODMA32\DDD\FullName =3D "Dynamic Document Depot V1.0 for=20 Windows"

Applications should never display a DMS ID in a user interface. = These DMS=20 IDs can be obtained using ODMGetDMSList or directly reading the = registration=20 database. Applications should look up the FullName of the DMS and = display that=20 instead.=20

If the DMS wanted to serve as the default ODMA provider to be used = with all=20 ODMA-aware applications that were not registered with a specific DMS, = it would=20 add the DEFAULT subkey to its DMS ID key as shown below:=20

ODMA\DDD\DEFAULT for Windows 3.x
ODMA32\DDD\DEFAULT for Win32 = (i.e.=20 Windows NT and Windows 95)

If the DMS wanted to specifically register itself as the ODMA = provider for=20 one or more applications, it would also add a subkey to the relevant=20 applications' root level keys. Note that this is only necessary if a = different=20 DMS is registered as the default ODMA provider. Each time an = application calls=20 ODMRegisterApp , the connection manager looks in the registration = database for=20 a root-level key that matches the specified application ID. If it = finds such a=20 key then it looks under it for a subkey called ODMA. The value of this = key is=20 the DMS ID of the specifically registered DMS. If the application ID = key is=20 not found or if the subkey ODMA or ODMA32 does not exist under it, the = connection manager looks at the subkeys of the root-level key ODMA or = ODMA32=20 for a default ODMA implementation.=20

For example, suppose a document management system with a DMS ID of = DDD=20 wanted to support only one particular application that used QQQ as its = application ID. It would add the following key and value to the = registration=20 database in addition to the ODMA subkey described above:=20

QQQ\ODMA =3D DDD for Windows 3.x
QQQ\ODMA32 =3D DDD for Win32 = (i.e. Windows=20 NT and Windows 95)

Installing a Client = Application
Windows 3.x, Windows 95 and Windows NT

This section defines the registration database entries ODMA = compliant=20 client applications should make when they are installed. These entries = will=20 help provide improved out-of-the-box integration between applications = and=20 Document Management Systems. They will allow an application to:=20

  1. Enumerate 16-bit and 32-bit ODMA compliant applications on the = system,=20
  2. Enumerate file types whose native applications are ODMA = compliant, and=20
  3. Quickly determine if a given file type=92s native application = supports=20 ODMA and if it expects a 16-bit or 32-bit DMS provider.

Most Document Management and Workflow Management applications have = a=20 function that can push a document to the native application which = supports the=20 document=92s content format. The Windows platform provides several = functions=20 which can be used to launch an application to open a document. = Examples are=20 ShellExecute , WinExec and CreateProcess (Win32 only). However, the = calling=20 application needs to be able to determine in a seamless way if it = should be=20 passing a file specification or an ODMA Document ID to the = application. For=20 this reason, applications which support an ODMA Document ID in their = command=20 line or DDE interface must record this information in the registration = database.=20

In addition to the above, the calling application may need to know = if the=20 ODMA application to be launched is 16-bit or 32-bit. For example, if = the=20 calling DMS application is only 16-bit and the application to be = launched is=20 32-bit, then perhaps the calling application can downgrade to some = other form=20 of application invocation that doesn=92t required a 32-bit DMS.=20

File type entries take the following form, under the = HKEY_CLASSES_ROOT key:=20

ODMA.FileTypes\<FileType> =3D=20 "<AppSubkey>"
ODMA32.FileTypes\<FileType> =3D=20 "<AppSubkey>"

<FileType> is the same value used in the = HKEY_CLASSES_ROOT\.ext entry=20 for the file extension. Sometimes this value is referred to as a file = type=20 class name. This provides a link back to the file type=92s other = registration=20 entries. Note that often applications have more than one file = extension=20 pointing to a single file type class name.=20

<AppSubkey> is the same as the ODMA application=92s AppId, = used in=20 ODMRegisterApp . If the AppId contains spaces they must be removed, = because=20 spaces are not allowed in a subkey.=20

Application entries are as follows (under the HKEY_CLASSES_ROOT = key):=20

ODMA.ClientApps\<AppSubkey> =3D=20 "<AppId>"
ODMA32.ClientApps\<AppSubkey> =3D = "<AppId>"

The <AppSubkey> is the same as above. The <AppId> is = the=20 regular string used by the application in ODMRegisterApp . It can = contain=20 spaces and is limited to 15 characters (see the ODM_APPID_MAX = constant).=20

The FullName of a client application can be provided as follows:=20

ODMA.ClientApps\<AppSubkey>\FullName =3D "The app=20 name"
ODMA32.ClientApps\<AppSubkey>\FullName =3D "The app = name"

Use the following procedure to determine if the application that = supports a=20 given file type can also handle an ODMA document ID in its command = line or DDE=20 interface. First lookup the file extension entry in the Registry to = get the=20 file type class name. If the extension isn=92t found then there is no=20 application supporting the file type on the system. Next append the = file type=20 class name to the ODMA32.FileTypes\ key and see if the key exists in = the=20 registry. If the key exists, then a 32-bit ODMA-aware application that = can=20 accept an ODMA document ID in its command line or DDE interface should = be=20 present on the system. If the key was not found then the = ODMA.FileTypes key=20 can be tested to determine if a 16-bit ODMA-aware application is = present. If a=20 16-bit DMS client is initiating this process, it can avoid launching a = 32-bit=20 application if it doesn=92t have the correct thunking layers installed = on the=20 platform. The reverse is also true, where a 32-bit DMS might avoid = launching a=20 16-bit application if it does not support 16-bit ODMA on the platform. =

Connection Manager Trace = Logging
Windows 3.x, Windows 95 and Windows NT

As of ODMA 2.0, the ODMA Connection Manager is capable of logging = function=20 calls made by any application to any DMS on the system. This trace log = contains information about each function call made, including the App = ID of=20 the calling application and the input values of individual function=20 parameters. It also includes the information returned by the DMS, like = function values and output parameter values. The trace log contains=20 information about function calls that are handled by the Connection = Manager=20 without DMS involvement (i.e. ODMGetDMS , ODMSetDMS , ODMGetDMSList , = etc.).=20

The following Windows Registry sub-keys, under HKEY_CLASSES_ROOT, = control=20 ODMA trace logging:=20 =

ODMA.ConnectionManager\Logging\Enabled
ODMA32.ConnectionManager\Log= ging\Enabled

If the entire sub-key described above is defined then the = Connection=20 Manager will do trace logging. To disable trace logging simply remove = the=20 "Enabled" sub-key. There are no default data names or values assigned = to this=20 sub-key at this time.=20

ODMA.ConnectionManager\Logging\File =3D=20 "fullpath"
ODMA32.ConnectionManager\Logging\File =3D "fullpath"

The default filename for the trace log file is "ODMA.LOG" for the = 16-bit=20 Connection Manager and "ODMA32.LOG" for the 32-bit Connection Manager. = The=20 default path is the Windows System or System32 directory as = appropriate. If=20 the File sub-key does not exist then ODMA uses its defaults. If the = fullpath=20 is specified in the data value it must contain a full path and = filename. If=20 the fullpath is invalid the Connection Manager will revert to its = default log=20 filename and path.=20

ODMA.ConnectionManager\Logging\Options =3D=20 "token1,token2"
ODMA32.ConnectionManager\Logging\Options =3D = "token1,token2"=20

The Options data value is simply a comma separated string of = tokens. There=20 is no default value defined at this time. The various tokens control = trace=20 logging. They are:=20

NEWLOG -- If defined then when the Connection Manager DLL is loaded = into=20 memory it will delete any existing log file and create a new log file. = The=20 default behavior is for the Connection Manager to append to any = existing log=20 file.=20

Appendix A

Document Attributes=20

The following table describes document attributes or properties = defined by=20 ODMA. Applications can get attribute values for a document by using = the=20 ODMGetDocInfo function. Some attribute values can be set using the=20 ODMSetDocInfo function. Not every DMS will support every document = attribute=20 listed here. Applications can use the ODMQueryCapability function to = determine=20 if a DMS supports a given document attribute.=20

Note that the ODMA standard does not currently define maximum = lengths for=20 any specific document attribute. This is DMS specific. In most cases = the DMS=20 will truncate the attribute value returned if it does not fit in the = caller=20 supplied buffer.=20

Attribute/Item ID Description Type Set
ODM_ALTERNATE_RENDERINGS If the DMS supports alternate = renderings for=20 the specified document, then it must return a comma-separated = list of=20 format names representing the alternate formats it can return in = ODMGetAlternateContent . Refer to the Document Format Names = section for=20 information on how file formats are identified in ODMA. String No
ODM_AUTHOR Author of the document. String Yes
ODM_CONTENTFORMAT The format name string indicating = the format=20 of the document=92s contents. Refer to the Document Format Names = section=20 for information on how file formats are identified in ODMA. In=20 ODMGetDocInfo It is recommended that the DMS return either a = MIME=20 Content Type or a Windows file type/extension. Note that when = this item=20 is used in ODMSetDocInfo , it merely informs the DMS of a change = in the=20 document's format; it does not cause a conversion process to = take place=20 within the DMS. String Yes
ODM_CHECKEDOUTBY Username of the person who has the = document=20 checked-out. This username is in the form used by the DMS. If = the=20 document is not currently checked-out a zero length string is = returned.=20 String No
ODM_CHECKOUTCOMMENT The comment, if any, that the user = supplied=20 when they checked-out the document. String No
ODM_CHECKOUTDATE The date/time the document was = checked-out.=20 If the document isn=92t currently checked-out, a zero-length = string is=20 returned. Date No
ODM_CREATEDBY Username of the person who = initially created=20 the document in the DMS. String No
ODM_CREATEDDATE The date/time the document was = created in the=20 DMS. Date No
ODM_DOCID_LATEST A null-terminated document ID for = the Latest=20 version of the document represented by lpszDocId . If lpszDocId = is the=20 Latest version, it will be the same document ID. DocId No
ODM_DOCID_RELEASED A null-terminated document ID for = the=20 Released version of the document represented by lpszDocId . If = lpszDocId=20 is the Released version, it will be the same document ID. If the = DMS=20 does not differentiate Released versions, return the version ID = of the=20 Latest version of the document. A DMS may allow this attribute = to be=20 set. An application such as a workflow can set a version of a = document=20 to be the released version by specifying this attribute in a = call to=20 ODMSetDocInfo . In this case, the lpszData parameter should be = set to=20 Null. DocId Yes
ODM_DOCVERSION A null-terminated string which is = the version=20 ID for lpszDocId . This allows the application to display the = version=20 information explicitly (without doing the impossible and = decoding the=20 document ID), for situations such as where the user is making = the=20 decision to re-link to a different version. It is the DMS = responsibility=20 to consistently translate version information into a string that = can be=20 used for comparison and display. Since it is a string, and = comparisons=20 will not be made between strings from different DMS, the = application=20 does not have to be concerned that different DMS have different = formats,=20 meanings and capabilities for version, sub-version, branching = and so on.=20 String No
ODM_DOCVERSION_LATEST A null-terminated string which is = the version=20 ID for the Latest version of the document represented by = lpszDocId . String No
ODM_DOCVERSION_RELEASED A null-terminated string which is = the version=20 ID for the Released version of the document represented by = lpszDocId .=20 If the DMS does not differentiate Released versions, return the = version=20 ID of the Latest version of the document. String No
ODM_LOCATION A null-terminated string containing = DMS=20 specific information describing the logical location (e.g. = folder) of=20 the document within the data store. The DMS should format the=20 information in this attribute so that it can be safely displayed = in a=20 user-interface. The application should not assume the = information in=20 this attribute is persistent across ODMA sessions. A DMS may = allow an=20 application to set this attribute in ODMSetDocInfo only for = documents=20 that have not been created yet. String Yes
ODM_KEYWORDS A comma separated list of keywords = assigned=20 to the document. String Yes
ODM_LASTCHECKINBY Username of the last person to = modify or=20 check-in the document. String No
ODM_LASTCHECKINDATE The date/time the document was last = modified=20 or checked-in. Date No
ODM_MODIFYDATE The data/time the document was last = modified.=20 Date No
ODM_MODIFYDATE_LATEST The date/time that the Latest = version of the=20 document was last modified. Date No
ODM_MODIFYDATE_RELEASED The date/time that the version of = the=20 document that is Released was last modified. If the DMS does not = differentiate Released versions, return the date/time that the = Latest=20 version of the document was last modified. Date No
ODM_NAME Name of the document. This is a = descriptive=20 name for the document, not the filename. String Yes
ODM_OWNER The owner of the document. String No
ODM_SUBJECT The subject matter of the document. = String Yes
ODM_TITLETEXT Suggested text to display in the = document=20 window's title bar. This may include one or more fields from the = document's profile and possibly other information as well. String No
ODM_TITLETEXT_RO Same as ODM_TITLETEXT, except if = the document=20 is currently opened by the calling application in ODM_VIEWMODE , = the DMS=20 should append " (Read-Only)" to the text. String No
ODM_TYPE Type of the document. This is = typically an=20 indication of the format or content of the document, i.e.=20 correspondence, memo, contract, etc. String Yes
ODM_URL Uniform Resource Locator (URL) = which provides=20 an alternative way to access the document. Note that a DMS can = never=20 truncate a URL if it is too long to fit into the caller supplied = buffer.=20 String No

String =3D A null-terminated string containing the document = attribute value.=20

Date =3D A null-terminated string containing a date and time in the = following=20 format: "YYYYMMDDhhmmsscc +hhmm". The "YYYYMMDD" section contains a 4 = digit=20 year, 2 digit month and 2 digit day. The "hhmmsscc" section contains = the time=20 in 24 hour format (hours, minutes, seconds, hundredths of seconds). A = DMS=20 should return zeros for any part of a time it doesn=92t support. The = "+hhmm"=20 section is an optional Greenwich Mean Time (GMT) offset. If the GMT = string is=20 included in a date/time string it is preceded by a space, followed by = either a=20 + (plus) or - (minus) character, then a 2 digit hour value and a 2 = digit=20 minute value. A DMS should only return the GMT offset if it knows the = offset=20 for the data store containing the specified document. If the GMT = offset is not=20 included, then the date/time value is the local date and time for the = document=20 in the DMS.=20

DocId =3D A null-terminated string containing an ODMA document ID.=20

The "Set" column indicates if the attribute can be set with = ODMSetDocInfo .=20 It is possible that a DMS may not allow certain document attributes to = be set.=20

Appendix B

Preferred Call Usage for = Initial File=20 Creation=20

There has been some misunderstandings among both DMS and = application=20 vendors on the correct use of the ODMA 1.0 calls to initially create a = file.=20 This appendix is basically from a proposal made in October 1994 by Rod = Schiffman of Novell. There has been no dissension on the issue since = the=20 original proposal was made. Until the standard is modified to provide = other=20 methods for the initial creation of a new document in a DMS, this = provides a=20 sequence for the calls that will work with all major DMS vendors.=20

From Rod Schiffman:=20

It is probably useful for me to describe the terminology and = concepts I=20 will use in this discussion. A DMS is fundamentally more complex than = my=20 description, but it will suffice for my purposes. A DMS is a black box = that=20 manages documents. My Local System is the particular machine and = Operating=20 System, or environment, that I use. It has its own file system, = applications=20 and interfaces. When I need to do something to a existing document in = the DMS,=20 I select it using tools the DMS provides and retrieve it into my local = system.=20 I use an application to perform operations on the document. I may want = to=20 create a new document with my application. The new document will be = stored on=20 my local system until I save it into the DMS. The DMS may want to tell = me=20 where I should save it on the Local System until I eventually save it = into the=20 DMS. I may also want to update the copy in the DMS while I am still = working on=20 it. I call this writing the document through to the DMS. When I am = finally=20 done working on the document, I can save it to the DMS. It is then = closed. At=20 some point in the process of creating a new document, the DMS will = require me=20 to give it a profile. When I have saved the document to the DMS, it is = closed=20 and the document no longer has a presence on my local machine. ODMA = has a=20 vaguely defined concept of formats that are attached to a document, = and while=20 the timing of when and how formats are defined plays a central role in = this=20 discussion, formats, conversions and their association to documents = does not=20 play a role in this discussion.=20

ODMSaveDoc is the only ODMA function that actually saves a document = into a=20 DMS. It uses a Document ID (DocID) supplied by the DMS. The initial = creation=20 of the first DocID for the document can only be supplied by ODMNewDoc = .=20 ODMSaveAs and ODMSaveDoc can return a new DocID, but they must already = have an=20 initial DocID to start with. ODMSelectDoc only returns a DocID that = already=20 exists. This means that ODMNewDoc must be called to generate the = initial=20 DocID. After the application has a DocID, it can call ODMOpenDoc to = get a=20 local file name to save the document to and ODMSaveDoc to write the = document=20 through to the DMS. This would imply that it is not necessary to call=20 ODMSaveAs in the process of saving the document the first time. This = has=20 caused a number of people to assume that the usage of ODMNewDoc was = synonymous=20 with the initial "Save" function in most applications. However, the = spec says=20 that the format specified in ODMNewDoc "may be changed later via an = ODMSaveAs=20 call." This implies that it is OK to call ODMSaveAs after calling = ODMNewDoc .=20 ODMSaveAs is the only call that allows an application to interact with = the DMS=20 and supply application specific information such as formats and = passwords. If=20 an app only calls ODMNewDoc and does not call ODMSaveAs , it loses the = ability=20 to provide application specific information. ODMSaveAs requires that a = user=20 interface is supplied to the user. If ODMNewDoc also supplies a user=20 interface, then the user interface comes up twice for each document = creation.=20 Once in ODMNewDoc and again in ODMSaveAs . This is probably not = something that=20 the user wants. Also, how do we reconcile the ability to call = ODMNewDoc=20 without a user interface. If ODMNewDoc is called with no user = interface and a=20 DocID is returned, then when is the profile filled in? ODMOpenDoc and=20 ODMSaveDoc and ODMCloseDoc have no obvious provisions for providing a = user=20 interface.=20

ODMNewDoc was originally intended to be synonymous with the "New" = menu=20 choice, not the "Save" menu choice, in most applications. For example, = although SoftSolutions and PC Docs do not care about a document until = it is=20 time to save it to the DMS the first time, DEC TeamLinks does have the = concept=20 of letting the DMS know a document is going through initial creation. = There is=20 nothing in the spec that indicates whether ODMNewDoc should be called = at=20 document creation or just before saving the document the first time. = This is=20 not an accident according to Brad Clements, the original author of the = ODMA=20 spec. It can be done at whatever time makes sense for the DMS and = application.=20 ODMNewDoc does not have provisions for the callback routine because it = notifies the DMS about the creation of a document not the saving of a=20 document. At document creation time, the user is probably not worried = about=20 the what the final format will be or if there will be a password. The = user may=20 not, and this is crucial, even save the document to the DMS. It is = possible=20 that if ODMNewDoc is called without a user interface, that the DocID = returned=20 to the application may not eventually be used, if the user is allowed = to have=20 the file saved to the local file system in a later call to ODMSaveAs . =

It turns out that many applications and Document Management Systems = do not=20 have or need a concept of providing application and DMS interaction = until the=20 document is ready to be saved in the DMS for the first time. Certainly = a DMS=20 must deal with applications that will not provide any interaction with = the DMS=20 until the document is already created in the edit buffer and is ready = to be=20 saved. At this point I would like to point out a scenario that follows = the=20 spec, and still works with major applications that may not have = followed the=20 spec according to the interpretation given here.=20

At the time of initial document creation, or when it is time to = save the=20 document the application should call ODMNewDoc with the ODM_SILENT = flag. This=20 will return a temporary DocID that the application can use. = Technically, the=20 application could call ODMOpenDoc to have a local temporary file to = use until=20 the document is finally saved into the DMS, but I know that every DMS = vendor I=20 have talked to would frown on this idea. They prefer the idea that all = saves=20 are written through to the DMS and that there is a full profile for = anything=20 that exists in the DMS. It is OK for the DMS vendor require this by = returning=20 an ODM_E_USERINT error to indicate that ODMOpenDoc cannot be called = until the=20 app makes a call to ODMNewDoc or ODMSaveAs that brings up an user = interface.=20 This implies that the application would be better to avoid the = situation and=20 not call ODMOpenDoc until after an user interface is provided to the = user.=20 After calling ODMNewDoc in silent mode, take the DocID that is = returned and=20 call ODMSaveAs to have the profile created, and allow access to the = callback=20 routines. If the ODMNewDoc returns an ODM_E_USERINT error because it = does not=20 support the silent mode, then call ODMNewDoc with a user interface and = skip=20 calling ODMSaveAs . This performs the same functionality, but does not = provide=20 access to the callback routines. If the application still wants the = user to=20 see the callback dialog, then it can call the callback dialog itself = after=20 calling the ODMNewDoc call. This is not optimal, but does work. In = either case=20 the user interface is only presented to the user one time.=20

There are a couple caveats for DMS vendors. The DocID returned by = ODMNewDoc=20 must be a temporary ID. It is possible that the user will throw away = the file=20 before it is saved, or that it will be saved to the native OS through = the=20 options button in the SaveAs dialog. This could be easily handled by = returning=20 a well known dummy value like ::ODMA\<app id>\NULL. When = ODMSaveAs sees=20 this null value as the DocID, it can know that it is creating the = document for=20 the first time and take appropriate action as opposed to the normal = SaveAs=20 action. It does not matter if there are multiple documents using this = DocID at=20 the same time as long as the DMS returns ODM_E_USERINT to the = ODMOpenDoc call=20 that passed in the null DocID.=20

Basically, this turns the ODMNewDoc into a fancy NOP routine. There = may be=20 situations where this may not be the best action, but since there is = no=20 compelling reason for the existence of the ODMNewDoc call in the 1.0 = spec, it=20 seems to solve more problems than it creates. It would probably be a = good idea=20 to add an extension to the 1.0 spec in ODMA 1.1 where the ODMSaveAs = call can=20 allow a NULL to be passed in as the lpszDocID parameter to indicate = that the=20 document is being saved for the first time. This would free the = application=20 from having to use the ODMNewDoc call. Of course, that is what the = addition of=20 a dummy DocID value returned from ODMNewDoc accomplishes. In the ODMA = 1.1=20 time-frame a new ODMNewDoc call can be created if someone comes up = with a=20 compelling reason for its existence. Simply using the ODMSaveAs call = when an=20 application is creating a new file in the DMS, whether it is the first = save or=20 an actual SaveAs, matches the way most applications work today.=20

Additional information from Bob St.Jean:=20

ODMA 2.0 introduces an ODMSaveAsEx function that extends ODMSaveAs = . This=20 addresses the specification change Rod Schiffman had envisioned. The = lpszDocId=20 parameter in ODMSaveAsEx can optionally be set to Null by the calling=20 application. This frees the application from calling ODMNewDoc during = a Save=20 As sequence for a new document. If the application calls ODMSaveAsEx = without=20 first calling ODMNewDoc , then the DMS will return a DocID in the = lpszNewDocId=20 parameter. This may be a temporary DocID that will later be replaced = by a new=20 DocID when ODMSaveDoc or ODMSaveDocEx is called.=20

Note that there is a purpose for the ODMNewDoc call in the Save As=20 sequence. The temporary DocID returned by the DMS in ODMNewDoc will = provide a=20 document context which the application can use to pre-set some = document=20 attributes for the new document before calling ODMSaveAs or = ODMSaveAsEx . This=20 is the only way for an application to pre-set items that might appear = in the=20 DMS=92s Save As dialog box. Examples of such attributes are = ODM_AUTHOR,=20 ODM_NAME, ODM_TYPE, ODM_KEYWORDS, ODM_SUBJECT and perhaps others. The=20 application can set these attributes by calling ODMSetDocInfo using = the DocID=20 returned by ODMNewDoc . The application can call ODMQueryCapability to = find=20 out if the DMS will accept the attributes in ODMSetDocInfo . However, = there is=20 no way for an application to know if the attributes will be visible in = the=20 DMS=92s Save As dialog box.=20

The ODMA 2.0 specification also introduces a way to create = documents=20 without user interaction. The new ODMSaveAsEx , ODMSaveDocEx and = ODMCloseDocEx=20 functions all have an ODM_SILENT flag for this purpose. As outlined = above,=20 ODMNewDoc is used to create a temporary document context and = ODMSetDocInfo is=20 used to set document attributes.=20

Additionally, ODMA 2.0 recommends a standard for applications and = DMSs to=20 use to identify file format types.=20

Back to ODMA home=20 page
------=_NextPart_000_0040_01BFA073.AA5BF660 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-Location: http://www.aiim.org/nav_aiim.gif R0lGODlhfAAgAMQAAP/////M/8z//8zM/8zMzJnM/5nMzJmZ/5mZzGaZ/2aZzGZm/2ZmzDOZzDNm zDNmmTMzZjMzMwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAA fAAgAEAF/2AkjmRpnmiqrmzrvqQjy4Ay33guD4YuK4CgIBi06Yi1GfIwGyCJTBzwCRj4rtgELvkD 3BTgsFgh6N2c1HQQcUMaHcsm0Ygg8uayetCK7fe5DkBtb4JNZn5/bEeKiFdADD+NOUBvkpaXmJma mAkPEVuEVQOjpKWlAIc3B0QCM3prOW5KUHJFcEQ3QwCtr3ybWICFNJU4PLVBfWhBUbI0tDt4M7pB BTe9v39q2k+pmoIFATs9QAMKCDyjcIoDBMMMoqgOTtXsgVVDYF4OBq0CAQND9rXCRrCgQU0LHCRY qAXCiC3bIgKo5ogKsTbRbi07ZsfHq44FE0AApcmYjmsfL/9qBBQHWhEkjJxNNADy4KAZwvwMoHiD Jq4bBWBCtCUTQBR5eKYACIcUmYNrNm92aXNgjBiTLtcUQLC16zmhRd+0bApIGRFGUKMOw6lv7QwD B7giEMBTrd27Uu3lzYl1E6VVbNJRetqKkhMbddhMDLRVQKsCfAhYCQpJQLkq+7wwKGDAydO2eEOL DsmwtOnTqFOrXs26tevXqwM5eOCpxOjbuH0srC3Fqu/fKnHI3Xr0ZFdrXd8gOAC3efCnXrcWXPBg ZN5LA2LGouJrO9GVh8xmzMXd4EVA2IsPraGsO8bvSMITCfoTKJSaBLVcjz68f2P1s8DiwDTuhRVg PFmZg9//KwqssgdewYCWjHZFxYTEQO+xRIR8tihDkVJs0IfZXRFKkp13uzCnok9CrCfWhscYMY0N 88kgYoEHlXigGupJ9ASGK70YBIdcvENEAC3aiF9UOrqlwwDFjZVDA08cKCSCZIVS5Qw3QhjKdcUw 0lxVfvSXB3HIcaWcXFKsCAlOzCFAYY5fKhEKQKMAMCcmcOGmAI6NlANMnU7yBWAmNdQRlAAKGGnU nwAF5g9XE+0CyTlOLDfHKnkMISg81UC62GBXNAkHoQ4QcOglj/BDQ6j6eJrOYvIMVM8oNFlBk428 6DOrDZxG6hmnWCwnl4rHJsuffr8wYAMYP7zprAzOGkHIGZuNRsIAtpBUkq0D04JrbSCQhJvbuej6 EAIAOw== ------=_NextPart_000_0040_01BFA073.AA5BF660 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-Location: http://www.aiim.org/nav_join.gif R0lGODlhRAATAMQAAP/////M/8z//8z/zMzM/8zMzJnM/5nMzJmZ/5mZzGaZ/2aZzGZmzDOZzDNm /zNmzDNmmTNmZjMzZjMzMzMzADMAMzMAAAAzmQAzMwAzAAAAMwAAAAAAAAAAAAAAAAAAACwAAAAA RAATAEAF/+AkjmRpnmiqrqOiPHD8IAC8AASQwAQB4wKdDJaoCX+Gx23xIAwISR0gKbtcRC6rdsvt er/gcBj7GprP6LR6PbSSZcXcTok7On+Ipk8m2DcFeHRMPQ9FSG1XEy6LjI2Oj5CRkpJuimVDNGmE bE1TMp5LnTUPDACeVYkuMkwzo0KhmwB5fUOlfUExsoJ6D0C9VDGVqpzExcbBiSzKy8zLk8/Q0dKp l8fW14hvZ6zbDMUL3jHcrAvg4tzI2kMHozZq4Wd1nzuwOUwGctmWZ+w8STc8Bvw4wGsIvj+56AEY RMCQkTnp9sUIkKQAoCZJDBUEQLCAHyI6DhSZw5HUwgcWOxntOBJx2Coz6LDJbFltpk1OwsTo3Mmz 54QQADs= ------=_NextPart_000_0040_01BFA073.AA5BF660 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-Location: http://www.aiim.org/nav_events.gif R0lGODlhNQAXALMAAP/////M/8zMzMyZzJmZmZlmmZkzmWZmZmYzZjMzMzMAMwAAAAAAAAAAAAAA AAAAACwAAAAANQAXAEAE0HDJSau9OOtSkEcEwHXIAHgiUgBCugpBCsyEyqafUnFK7//AoHBI1FE4 n6RyyWw6czuSxzQD1BAGQODzOtk6gIGn1TGRk0aNes3ejN7wuHxOh0eToar0+dwz0xJIHyFLAoZi CFUsX4mIVh4FLTgegAuCfJiZf22cnZ6foGt1o6SlI0d+mqp8lZeQI6uxUKhJJpqpe49cS617VDMe ByKECAJixoy6YWMBrgi9eCKXeSTLBB0rYFfLCAcFB4Zod7IqmN+7StDk6+k7oe/w8fLz7xEAOw== ------=_NextPart_000_0040_01BFA073.AA5BF660 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-Location: http://www.aiim.org/nav_infoservices.gif R0lGODlhUwAXAPcAAP////7///7+/v3+/vz+/vz9/fv+/vv9/fr9/fr8/Pn9/fn8/Pj8/Pf8/Pf7 +/b7+/X7+/T7+/P6+vL6+vH6+vH5+fD5+e/5+e/4+O74+O34+Oz4+Oz39+v39+n29uj29uj19ef2 9ub19eX19eX09OT09OP09OPz8+Hz8+Dz8+Dy8t7y8tzx8drw8Nfv79bv79bu7tXu7tPu7tLt7dHt 7c/s7M3r68rq6sfp6cbo6MXn58Pn58Hm5rzk5Lvk5Lnj4z6ysjPMzDPLyzPKyjPJyTPIyDPHxzPG xjPFxTPExDPDwzPCwjM5OTM4ODM3NzM2NjM1NTM0NDMzMzLLyzHKyjGtrTDJyS/IyC2rqyuqqiqp qSipqSioqCWoqCSoqCSnpyOnpyKmpiGmph+mph+lpR6mph6lpR2lpRylpRykpBukpBqkpBmjoxij oxeiohaiohWiohWhoRShoROhoROgoBKhoRKgoBGgoBCgoBCfnw+goA+fnw6fnw6eng2fnw2engye ngydnQudnQqdnQmdnQmcnAidnQicnAecnAebmwafnwacnAabmwWengWbmwWamgSdnQSbmwSamgOc nAObmwOamgKbmwKamgKZmQGamgGZmQCamgCZmQCYmABnZwBmZgAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAUwAXAAAI/wClCBQY pSAUKE8SJixYcKBDhwwjSmn4sOLAKBMxOoTC8ImTJiCZOHnCUePAIChRDiFCxMgRl0ZYDhGSsmZN ITiH6CQyEydNm0CD+Ow5M6UQnUWOJFGyJAkSI0V6ohQIdAoVK1ixUqEyJciUrkFrWt269StKsGHF fjV79uvVK3CvWCkL9hPVKZwy6bU0aRKkv5AmWdLLqbDhwpny6s1kqbHjxYcjJ57MeDFkxY0hNWqk qFHgwZk0fbIrBWXk06hTq17NurXq0VSDRJZUB42ZN4xOa0J9SdIhQIAcGZaE6JLrw5IKSVqdaM8h 1LBLyzZcyc6NHDx8qHl0WkBkTQgeZP8wUQOQ4Tsxnh8vnGeHndV2frw53Sm6acOHWoRZc+ZLj0GS LOLIJZtoAkBklyBAyCB67JHIIW6ckUUKe0Sy2266UcKIIH8IsoUMWgg4CCGRWMLJJYfkAQYMbUBH GkoYcjKICXUwUocZbAB3QQMIZBIAAAcalgkCI/KBhx9j+IADCyPEoUElnBhYGJACZHIJBBWI4EIX NqSwgxxxrLCBBZJcskgHIXxAwhwuxnYYIh3wQcgMKqBgRwZ/LBJJAJwEadglBDRwAQkzpKEDF214 cUIcEkDZ56O7DaBJJH+4sYULQNCAxRoviEFHIAws8sAhhszRgXmn2TddYY5QUEglhcD/oUEeDyhg wABV+lmYJgQgwsggg7jxQhyc4CFCHhBAmcmBfmqiSSUUdPBBClXcoMYbJXCQwQMLSJLAcotUgAhq nry46omjInLIIBYgwsCAxj0aGQGOOKKuHyu40YccFgzSQCWhASBlYQNcwsAgeJQRwhYtkFFHCW78 cYgkmhwQySWMMLBcquYe9qwCDDjwwMWABiAAAMvqyskABYSHwSKDeKDBBBFcXMCPfPYJpCaZYNKA BBaAAAcKKwBrwQMIHGAcAUwr3aZ0p1l5SbzOsrZYJQD3Vq9xF6pmpSSM1ItIIphcgvUlGFq5mqrr te3226yxDXdrnXQCd92G2W33YXunR6bqaIAHLvjghBduuOHlHq444FQt7vjjkEd+uEWUV2755Zhn rjkonHfu+eeghy766KSXbvrpqKeu+uqst+7667DHLvvsoQcEADs= ------=_NextPart_000_0040_01BFA073.AA5BF660 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-Location: http://www.aiim.org/nav_standards.gif R0lGODlhSgAXAMQAAP//////zP/MzP/Mmcz/zMzMzMzMmczMZsyZmcyZZsyZM8xmM5mZM5lmM5lm AGYzADMzMwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAA SgAXAEAF/2AkjmRpnmiqrqqiOLAjBEjsFAAgwIJg7A4EwKCDNQABAeDFGC4dTUMBRlTujsqE7XFy Pb7gsHhMLpvP5+7Lxm673/C4PMY1uWwJQCEQYFCHMEg4L0JQT1iDQToFO00NMUSMOwo6ADV0LJma m5wrLp+goaKjpKWmpwp1JXcxeQdKfjBac22Ua7QyQG+qJKxseQYwBLqMRIQAhi8CU00vlAhJhrFN fox/ALMwvCO+uN7f39ud4+Tl5ufoLajr7O2oauDx8nHiEd1QCAeP8zax3gz7dsGLYclBAwOzlvXz F4OhQWoNA7bxIyUim3rdGOAAxCMYDAYKhPg5gCwPxR0mDVIqYKCQkoE12BwEmJInAQOGGG854OgD xoAp0lKSdECJYgAHKQtMmUn0icGYAQg8dEBky0AbK9kwWNCQlkOHbSR+bJOTn1l+GNOpXcu2rdu3 b0MAADs= ------=_NextPart_000_0040_01BFA073.AA5BF660 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-Location: http://www.aiim.org/nav_go_gray.gif R0lGODlhKAAYAKIAAP///8zMzJmZmWZmZsDAwAAAAAAAAAAAACH5BAEAAAQALAAAAAAoABgAQAOc SLrc/jCSASkDr5CAJSnaF0JAaXYbNoBe+5SuAgSpoM0FJxLYCOmxYKmw8gWPyOQl5eJQYKnBACBY 9CJAhyDwBIA0FA2L98GqxsrFt+DVFdMxNHxOf9WF2bv1BMuhIlMBHAAWHHk9a2N5DYEyATc0AlQh V2YVAQKSRYaEZWRGDRxyCoNVaGtWng5uo2pfLiMdrKB3M2e0egqvuWkJADs= ------=_NextPart_000_0040_01BFA073.AA5BF660 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Content-Location: http://www.aiim.org/global_nav.html AIIM navigation bar ------=_NextPart_000_0040_01BFA073.AA5BF660--
3D"Join 3Devents 3DinfoServices
= =20 =