《文檔處理系統》是北京書生國際信息技術有限公司於2005年12月5日申請的發明專利，該專利申請號為200510126683，公布號為CN1979472，專利公布日為2007年6月13日，發明人是王東臨、劉昌偉、郭旭、鄒開紅、陸小青、姜海峰。該發明涉及一種對文檔進行處理的系統，特別涉及一種能處理多個文檔構成的文檔庫的系統，並能使不同套用軟體對同一文檔進行互操作。
該發明提供一種對文檔進行處理的系統，其包括存儲器，文檔庫系統，和套用軟體。其中，文檔庫的數據存儲在存儲器中，文檔庫系統和套用軟體通過一種標準調用接口連線起來。套用軟體對文檔的操作都統一成對一種預定義的通用文檔模型進行的操作，並通過該標準調用接口向文檔庫系統發出指令，文檔庫系統按照套用軟體的指令，對存儲在存儲器中的文檔庫執行相應的操作。
2010年11月15日，《文檔處理系統》獲得第十二屆中國專利獎優秀獎。
（概述圖為《文檔處理系統》的摘要附圖）
基本介紹
- 中文名：文檔處理系統
- 公布號：CN1979472
- 公布日：2007年6月13日
- 申請號：200510126683
- 申請日：2005年12月5日
- 申請人：北京書生國際信息技術有限公司
- 地址：北京市海淀區學院路35號世寧大廈1301室
- 發明人：王東臨、劉昌偉、郭旭、鄒開紅、陸小青、姜海峰
- 代理機構：北京銀龍智慧財產權代理有限公司
- 代理人：郝慶芬
- Int.Cl.：G06F17/30（2006.01）I
- 類別：發明專利
專利背景,發明內容,專利目的,技術方案,改善效果,附圖說明,權利要求,實施方式,榮譽表彰,
專利背景
2005年12月之前關於各種非結構化文檔的軟體已經比較普及，形成了多種文檔格式林立的狀況。例如，一個內容管理軟體往往要處理二三百種文檔格式，而且這些格式還在不斷更新，給軟體開發商帶來了巨大的困難。如何解決文檔通用性、進行數字內容提取、格式兼容越來越成為人們的關注點，人們迫切希望解決以下問題：
1）文檔不通用
基本上只能用同一種軟體在不同的人之間交換文檔，但不能在不同的軟體之間互相交換文檔，形成信息封閉。
2）文檔信息提取困難
文檔描述信息豐富，數據結構複雜，實現難度較大。每一家公司都把自己的書面文檔描述作為獨家特有技術、基本上不提供開放接口。
3）訪問接口不統一、數據兼容困難或代價太高
不同的文檔處理軟體之間，檔案格式互不兼容，在處理過程中要么利用對方組件解析（前提是對方提供相應接口），要么自己投入研發力量從頭到尾的解析對方的格式。
4）信息安全較差
2005年12月之前針對書面文檔的許可權控制手段單一，主要是數據加密、口令認證。因為信息泄露，每年造成巨大損失的公司案例層出不窮。
5）都是針對單個文檔的處理，缺乏多文檔管理手段
每個人電腦中都有大量文檔，但多個文檔之間缺乏有效的組織管理，而且資源共享很難。如，字型檔/字型檔、全文數據檢索等
6）行業競爭層次還停留在各自格式描述之爭上
由於書面文檔數據結構複雜、數據描述豐富、文檔數據長度不確定，每一個文檔都千差萬別。長期以來，大家都在關注文檔格式標準，各大公司都努力將自己特有的文檔格式發展為市場標準，各標準組織也致力於制訂通用的文檔格式標準。但不管是專有的文檔格式（如.doc）還是開放的文檔格式（如PDF），只要是以文檔格式為標準，就不可避免產生以下問題：
a）重複開發，效果不統一
使用同一標準的不同軟體都需要自己去解釋、生成該格式的文檔，造成大量重複開發，而且會因為各家解釋程式不同，有的完善有的相對簡單，有的支持新版本有的只支持舊版本數據，同一文檔在不同軟體下顯現出不同的版式，甚至出現解釋錯誤無法打開。
b）阻礙創新
軟體是不斷創新的行業，但由於每增加一個新功能就需要增加描述該功能的信息，但只有等到標準修訂的時候才能增加新的格式，因此把存儲格式固定死之後，將會妨礙技術創新的競爭。
c）影響性能
對海量信息，需要增加大量的檢索信息以提高檢索性能，但固定死的存儲格式難以增加檢索信息
d）影響可移植性和可伸縮性
在不同的系統環境下，不同的套用需求，可能會有不同的存儲要求。例如，存儲在硬碟上就需要考慮如何減少磁頭尋道的次數以提高性能，而在嵌入式套用中數據都相當於存儲在記憶體中的，就不存在這個問題。事實上，資料庫軟體也往往都是這樣設計的，同一個廠商的資料庫軟體在不同平台上就可能會使用不同的存儲格式。因此，設定文檔存儲標準將會影響系統的可移植性和可伸縮性。
7）頁面分層的技術不完善
2005年12月之前一些軟體，如Adobe的photoshop，Microsoft的word，多多少少已經有層的概念，但層的功能還比較單一，管理手段比較簡單，不能滿足套用需求
8）檢索手段還不夠豐富
隨著信息的海量化，用任何一個關鍵字來搜尋都會得到數量龐大的檢索結果，全文檢索技術基本解決了查全率的問題，但查準率迅速上升為首要問題。2005年12月之前技術還沒有很充分地利用全部信息來解決查準率問題，例如每個文字的字型、字號完全可以用來判斷該文字的重要性，但都在檢索時被忽略了。
事實上，一種文檔格式不管是否開放，最後結果往往都是被特定軟體所壟斷。商業實踐的結果證明，不管是.doc這種已經被無數的同行研究得比較透、大家都花了巨大的精力和人力物力去兼容的文檔格式，還是PDF這種完全公開的文檔格式，在實際套用中用戶還是會選擇用原廠商的軟體（即MSWord和Adobe Acrobat）來處理，而不太願意用第三方的軟體。一種文檔格式被特定軟體所壟斷會造成信息流不暢通，非常不利於進行信息化建設，而且還會造成用戶過分集中到大軟體公司的軟體上，形成對用戶不利的壟斷。例如，MSOffice的表格功能不夠好，但即使有人開發了非常好用的表格編輯軟體，也很難在市場上生存，因為基本上沒有哪個文檔通篇只有表格，這樣用戶還只能使用那些功能比較全的軟體，儘管其中的表格功能並不好用，因此市場就被MSOffice這種全能軟體所壟斷，大量中小軟體公司開發的“專而不全”的軟體缺乏市場空間。
2005年12月之前技術中最開放、可交換性最好的是Adobe Acrobat採用的PDF。PDF已經成為全球分檔分發、交換的事實標準，但也只能在不同的人之間交換文檔，不能在不同的軟體之間交換文檔，即不能實現文檔的互操作性。而且不管是Acrobat，還是Office，都只能對單文檔進行處理，缺乏對多文檔的管理功能，不具備對文檔庫進行操作的功能。
在文檔信息安全方面，2005年12月之前技術也存在較多缺陷。Word和PDF這些套用最廣泛的文檔，都是採用對數據加密或者口令認證等進行數據安全控制，沒有提供系統的身份認證機制，對許可權的控制都是整個文檔範圍的，不能細化到文檔內的任意區域，對邏輯數據指定加密和簽名是受限的，無法對任意邏輯數據設定加密和簽名。內容管理系統雖然能夠提供很好的身份認證機制，但由於與文檔處理系統是分離的，不能在核心層集成，不僅管理粒度只能做到文檔級，而且在文檔使用過程中就脫離了內容管理系統的安全控制，難以 進行必要的安全管理。通常情況下，安全機制與文檔處理是分離的模組，容易出現安全縫隙。
下面介紹該發明中會涉及到的一些2005年12月之前技術：
非對稱密鑰加密算法也叫公開密鑰體系（Public Key Infrastructure，PKI）算法，由美國史丹福大學赫爾曼教授於1977年提出。它主要指加密密鑰和解密密鑰不相同，而且相互之間不存在推導關係，用戶公開其中一個密鑰不會泄漏另一把密鑰。這樣其他人可以用公鑰對傳送的信息進行加密，安全地傳送到該用戶，然後由該用戶用自己的私鑰進行解密。PKI技術解決了密鑰的發布和管理問題，是2005年12月之前常用的密碼技術。使用PKI技術，進行數據通信的雙方可以安全地確認對方身份和公開密鑰，提供通信的可鑑別性。2005年12月之前，常用的PKI算法有橢圓曲線密碼加密算法（EllipticCurves Cryptography，ECC），RSA加密算法（RonRivest，AdiShamir，Len Adleman公私鑰算法）等。
RSA算法描述如下：
公鑰：n＝pq，（p，q為兩個不同的很大的質數，p和q必須保密）
將（p-1）和（q-1）相乘得到φ（n）
選擇一個整數e（1＜e＜φ（n））與φ（n）互質
私鑰：d＝e-1modφ（n），即計算一個數字d，使得它滿足公式de＝1modφ（n）
加密：c＝mc（modn）
解密：m＝cd（modn），m為明文，c為密文。
橢圓曲線密碼加密算法（ECC）是另一種非對稱密鑰加密算法，橢圓曲線用於密碼算法，於1985年由Koblitz和VictorMiller分別獨立地提出。它問世以來一直是密碼分析學的研究對象。現在，在商業和政府的用途中，橢圓曲線密碼系統（ECC）都被認為是安全的。根據已知的密碼分析學知識，橢圓曲線密碼系統相比於傳統的密碼系統來說提供了更高的安全性。
ECC加密算法描述如下：
大素數域上的橢圓曲線可通過同構映射將一般的曲線方程變換為特別簡單的形式：y2＝x3+ax+b，其中曲線參數a，b∈Fp並且滿足4a3+27b2≠0（modp）。
因此，滿足下列方程的所有點（x，y），再加上無窮遠點O∞，構成一條定義在大素數域Fp上的橢圓曲線。
Y2＝x3+ax+b（modp）
其中x，y屬於0到p-1間的大素數，並將這條橢圓曲線記為Ep（a，b）。
考慮如下等式：
K＝kG[其中K，G為Ep（a，b）上的點，k為小於n（n是點G的階）的整數，不難發現，給定k和G，根據加法法則，計算K很容易；但給定K和G，求k就相當困難了。
這就是橢圓曲線密碼系統基於的數學難題。把點G稱為基點（basepoint），k（k＜n，n為基點G的階）稱為私有密鑰（privatekey），K稱為公開密鑰（publickey）。
加密算法還可以是公知的對稱算法，對稱算法就是指加密和解密過程均採用同一把密鑰。如AES算法。
AES算法是1997年1月由NIST提出的，其目的是開發一種新的能保證政府信息安全的編碼算法。最後經過多方評估從15種算法中選出Rijndael算法作為AES編碼標準算法。AES算法是對稱加密的疊代分組密碼。它把數據塊分成比特陣列，每一項密碼操作都是面向比特的。Rijndael算法分為四層，第一層是8×8比特置換（即輸入8比特，輸出8比特）；第二、三層是線性混合層（陣列的行移位、列混合）；第四層是子密鑰與陣列的每比特異或。
AES的分組長度為128比特，密鑰長度為128/192/256比特，相對應的輪數r為10/12/14，相應的密鑰方案為：在加密的過程中，需要r+1個子密鑰，需要構造4（r+1）個32比特字。當種子密鑰為128和192比特時，構造4（r+1）個32比特字的過程是一樣的。但當種子密鑰為256比特時，構造4（r+1）個32比特字的過程是不同的。
發明內容
專利目的
該發明的目的在於提供創新的對文檔進行處理的方法、系統和部件，從而實現文檔的互操作、對多文檔的管理、更好的文檔安全性以及更好的查詢檢索。
技術方案
依照該發明的對文檔庫進行處理的系統，其包括存儲器，文檔庫系統，和套用軟體。其中，文檔庫的數據存儲在存儲器中，文檔庫系統和套用軟體通過一種標準調用接口連線起來。套用軟體對文檔的操作都統一成對一種預定義的通用文檔模型進行的操作，並通過該標準調用接口向文檔庫系統發出指令，文檔庫系統按照套用軟體的指令，對存儲在存儲器中的文檔庫執行相應的操作。
該發明改變了從用戶界面到文檔存儲都由一個軟體來完成的現狀，將其劃分為套用軟體和文檔庫系統兩層，並定義了一個接口標準。文檔庫系統是具備各種文檔操作功能的通用技術平台，並具有符合該標準的接口部，套用軟體要對文檔進行操作時就通過該接口部來向文檔庫系統發出相應指令，文檔庫系統根據該指令執行相應操作。這樣，只要各套用軟體和各文檔庫系統都遵循同樣的標準，不同套用軟體就可以通過同一個文檔庫系統對同一文檔操作，即可實現對文檔的互操作。同樣，同一個套用軟體也可以通過不同文檔庫系統對不同文檔進行操作，而不用分別對每種文檔格式都進行單獨開發。
該發明還包括一個通用文檔模型，該模型能與各套用軟體所需要處理的文檔相符合。接口標準就是基於該文檔模型來設計的，這樣才能實現不同的套用軟體都可以通過同一個接口部來對文檔進行操作。該通用文檔模型也適用於各種文檔格式，這樣同一個套用軟體才可以通過同一個接口部來對不同文檔格式進行操作。該通用文檔模型的具體內容請參見後面的實施例。
接口標準定義了基於該通用文檔模型對文檔進行操作的各種指令，以及套用軟體向文檔庫系統傳送指令的方式。文檔庫系統具備實現這些指令的功能，以供套用軟體調用。接口標準可以用命令串
該通用文檔模型還包括由多個文檔組成的文檔集、文檔庫和文檔倉庫等層次，接口標準中也包含對多文檔的組織管理、查詢檢索、安全控制等指令。
該通用模型還包括將頁由具有上下順序的層組成，接口標準中也包含對層的各種操作指令，以及對一個文檔某一層所對應源檔案的存儲和提取。
文檔庫系統還具備對文檔的信息安全管理控制功能，如基於角色的細粒度許可權管理，並在接口標準中定義了相關的操作指令。
依照該發明的系統由存儲器、文檔庫系統和套用軟體組成。其中，文檔 數據存儲在存儲器中，文檔庫系統有一個下接口部，套用軟體有一個上接口部。當套用軟體需要對文檔庫進行操作時，通過其上接口部向文檔庫系統的下接口部發出指令，文檔庫系統按照套用軟體發出的指令，對存儲在存儲器中的文檔數據執行相應的操作。
改善效果
依照該發明，使得套用層和數據處理層分離。這樣套用軟體不再直接跟具體的文檔格式打交道，文檔也不再與特定套用軟體綁定，從而使得同一文檔能在不同的套用軟體之間通用，同一套用軟體也能對不同文檔進行操作，實現了文檔的互操作；整個文檔處理系統還具備多文檔處理功能，而不局限在單文檔處理；將頁分成多層後，可以實現對不同層實施不同管理和控制，更便於不同套用軟體對同一頁的操作（可以設計成不同套用軟體管理和維護不同層），為以源檔案方式進行編輯提供了便利，也是一種很好的保留歷史痕跡的方式；通過將信息安全集成在文檔處理的核心層，可以消滅安全縫隙，還能使安全機制與文檔操作緊密地結合為一體，而不是可以分離的兩個模組，同時有更多的空間部署安全管理技術，相關代碼也能隱藏得更深，能更有效地防禦非法攻擊，提高安全可靠度，另外還能提供細粒度的安全管理手段，如更多的許可權類別，更小的管理單元。
附圖說明
圖1為依照該發明的文檔處理系統的結構框圖。
圖2為依照該發明的通用文檔模型。
圖3-9為依照該發明的文檔模型的詳細邏輯結構。
圖10為以UOML接口為例子的文檔處理系統。
權利要求
1.一種對文檔進行處理的系統，其包括存儲器，文檔庫系統，和套用軟體，其中，文檔庫的數據存儲在存儲器中，文檔庫系統和套用軟體通過一種標準調用接口連線起來。套用軟體對文檔的操作都統一成對一種預定義的通用文檔模型進行的操作，並通過該標準調用接口向文檔庫系統發出指令，文檔庫系統按照套用軟體的指令，對存儲在存儲器中的文檔庫執行相應的操作。
2.如權利要求1所述的系統，其中，文檔模型為：文檔庫由一個或多個文檔組成，文檔由一個或多個有前後順序的頁組成，頁由任意數量的文字、圖形、圖像等對象組成。
3如權利要求2所述的系統，其中，在“文檔庫”和“文檔”之間增加“文檔集”層次，文檔庫由一個或多個文檔集組成，文檔集由一個或多個文檔組成。
4.如權利要求2所述的系統，其中，在“頁”和“對象”之間增加“層"層次，頁由一個或多個有先後順序的層組成，層由任意數量的文字、圖形、圖像等對象組成。
5.如權利要求3或4所述的系統，其中，文檔集進一步包括子文檔集。
6.如權利要求2所述的系統，其中，文檔還包括任意數量的元數據、導航、導讀、微縮版面信息。
7.如權利要求2所述的系統，其中，文檔庫和/或文檔集和/或文檔和/或頁中還包括任意數量的字型檔、圖像等共享資源。
8.如權利要求2所述的系統，其中，對象包括狀態和/或文字對象和/或圖形對象和/或腳本和/或外掛程式和/或嵌入式對象和/或導航和/或書籤對象和/或連結對象和/或流媒體和/或二進制數據流和/或超連結。
9.如權利要求2所述的系統，其中，文檔庫還包括角色，並對每個角色定義其許可權。
10.如權利要求1所述的系統，其中，文檔庫系統具備下列功能：文檔庫的創建、刪除；文檔庫中各文檔的創建、刪除；文檔中各頁面的創建；頁面中各對象的創建。
11.如權利要求10所述的系統，其中，文檔庫系統還具備下列功能：文檔集的創建。
12.如權利要求11所述的系統，其中，文檔庫系統還具備下列功能：層的創建。
13.如權利要求10所述的系統，其中，文檔庫系統還具備下列功能：刪除頁面；刪除頁面中的對象。
14.如權利要求12所述的系統，其中，文檔庫系統還具備下列功能：文檔集的刪除；層的刪除。
15.如權利要求10所述的系統，其中，文檔庫系統還具備下列功能：獲取對象屬性；修改對象的屬性。
16.如權利要求10所述的系統，其中，文檔庫系統還具備下列功能：獲取指定頁的版面點陣圖。
17.如權利要求1所述的系統，其中，套用軟體調用標準調用接口的方法是套用軟體按照預先定義的格式生成指令，將指令傳送給文檔庫；或者是套用軟體調用文檔庫系統提供的接口函式；或者是上述方法的組合。
18.如權利要求17所述的系統，其中，指令格式由操作命令和操作對象組成，描述與文檔庫系統運行平台無關，即其中不含有與特定的作業系統（如WINDOWS、UNIX/LINUX、MACOS、SYMBIAN）或特定的硬體平台（如x86CPU、MIPS、POWERPC等）相關連的特徵。
19.如權利要求18所述的文檔作業系統，其中，所述操作對象包括文字對象、圖形對象、圖像對象、狀態、類型。
20.如權利要求1-18任一項所述的文檔作業系統，其中，套用層的不同的套用軟體可以同時或不同時調用同一個文檔庫系統。
21.如權利要求1-18任一項所述的文檔作業系統，其中，套用層的同一套用軟體可以同時或不同時調用不同的文檔庫系統。
實施方式
如圖1所示，依照該發明的文檔處理系統主要由三個部分組成：套用軟體、文檔庫系統和存儲器。其中套用軟體有一個上接口部，文檔庫系統有一個下接口部。
存儲器常用的是硬碟或者記憶體，也可以是光碟、快閃記憶體、軟碟、磁帶，甚至還可以是遠程的存儲設備，總之只要具備數據的存儲能力即可。在存儲器中存儲有多個文檔，但對套用軟體而言並不需要關心文檔的具體存儲方式， 只需要按照預定的文檔模型進行操作。圖2所示為依照該發明的一種通用文檔模型。
各個軟體的功能幹差萬別，對文檔的操作和記錄的數據也各自不同，例如Word和Excel處理的文檔就大相迥異。為了能夠定義出通用的文檔模型，我們可以參考紙張的特性，這是因為以紙張作為文檔信息的記錄手段是通行至今的標準方法，只要能具備紙張的所有功能，就能滿足工作、生活等實際套用的需求。
根據這個思路，我們把文檔中的一頁當成一張紙，凡是能畫到紙上的就記錄下來，即該文檔模型能夠描述頁面上的所有可見內容。2005年12月之前技術中的頁面描述語言（如PostScript）可以描述所有能印在紙上的信息，因此這一部分就不再詳細闡述。一般說來，頁面上的可見內容最終都可以歸為文字、圖形、圖像三類。
如果文檔中涉及到特定字型或特殊字元的話，為了保證在各台電腦上都能有相同的效果，就需要在文檔中嵌入相應字型檔。為了提高存儲效率，字型檔資源應當共享，這樣即使再多處使用了同一字元，也只需要嵌入一個字型檔。圖像有時也是可能在多處出現的，例如每一頁共同的底圖，或經常出現的公司標識，這種情況下最好也能共享這些圖像。
當然，作為更加先進的信息處理工具，不能僅僅模擬紙張的特性，還可以增加一些增強的數字特性，例如元數據、導航、導讀、微縮版面。元數據是描述數據的數據，例如作者、出版社、出版時間、ISBN號等就是圖書的元數據。元數據是業內通用名詞，也不在此贅述。導航是類似圖書目錄的信息，也是業內通用名詞。導讀信息描述了一篇文章所在的區域和閱讀順序，這樣當閱讀者讀完一屏後就可以根據該信息自動判斷下一屏應該顯示什麼，這樣還能做到自動換欄、自動轉版，而不用閱讀者再手工指定位置。微縮版面是事先生成的各頁面的微縮圖，閱讀者可以通過查看微縮版面來指定閱讀哪一頁。
文檔模型包含文檔倉庫、文檔庫、文檔集、文檔、頁、層、對象組、版面對象等多個層次。
其中，文檔倉庫由一個或多個文檔庫組成，文檔庫之間的關係相對於文 檔庫之下的層次之間的關係相對要鬆散一些，文檔庫之間可以非常簡單地組合和拆離，而不用對文檔庫本身的數據做改動，該多個文檔庫之間往往沒有建立統一索引（特別是全文索引），很多對文檔倉庫的檢索操作一般都需要遍歷各文檔庫的索引，而沒有統一的索引可用。每個文檔庫由一個或多個文檔集組成，每個文檔集由一個或多個文檔組成，還可以包含任意數量的子文檔集。這裡所說的文檔相當於2005年12月之前普通的一個文檔檔案（例如DOC文檔），文檔模型可以規定一個文檔只能屬於一個文檔集，但允許一個文檔屬於多個文檔集也是一種不錯的選擇。文檔庫不是多個文檔的簡單組合，它把多個文檔緊密地組織起來，特別是為文檔內容統一建立了各種檢索索引後就能帶來更大的便利性。
每個文檔由一頁或存在前後順序的多頁組成，每頁的版心可以不同，而且版心也不一定是矩形的，可以是任意形狀，可以用一條或多條封閉曲線表示版心。
每頁又由一層或存在上下順序的多層組成，各層之間如同玻璃板的疊加關係。層由任意數量的版面對象和對象組組成，版面對象是指狀態（如字型、字號、顏色、ROP等）、文字（包括符號）、圖形（如直線、曲線、填充了指定顏色的閉合區域、漸變色等）、圖象（如TIF、JPEG、BMP、JBIG等）、語義信息（如標題開始、標題結束、換行等）、源檔案、腳本、外掛程式、嵌入式對象、書籤、連結、流媒體、二進制數據流等。一個或多個版面對象可以組成一個對象組。對象組也可以包含任意數量的子對象組。
文檔庫、文檔集、文檔、頁、層都可以還包括元數據（如名稱、最後修改時間等，其類型可以根據套用需求來設定）和/或歷史痕跡；文檔中還可以包括導航信息、導讀信息、微縮版面；也可以把微縮版面放在頁或者層這個層次；文檔庫、文檔集、文檔、頁、層、對象組都可以還包括數字簽名；語義信息最好跟著版面信息走，這樣可以避免數據冗餘，也比較容易與版面建立對應關係；文檔庫、文檔還可以包括字型檔、圖像等共享資源。
該文檔模型還可以定義一個或多個角色，為每個角色分配一定許可權。許可權以文檔庫、文檔集、文檔、頁、層、對象組、元數據為單元進行分配，定義每個角色對該單元是否可讀、是否可寫、是否可複製、是否可列印；
該文檔模型是一個超越以往單個文檔對應單個檔案的方式，文檔庫中包含多個文檔集、文檔集中包含多個文檔，而對於文檔庫中文檔內容，採用了細粒度的訪問和安全控制，我們可以具體訪問文檔庫中某個文字或者矩形，而不像現在的文檔管理系統只能訪問到檔案名稱。
圖3-9給出了一種符合該發明的文檔模型，文檔模型中所涉及的各對象以樹狀結構組織，逐層展開、細化。
文檔倉庫對象是由一個或多個文檔庫對象組成。
如圖3所示，文檔庫對象是由一個或多個文檔集對象、任意數量文檔庫輔助對象和任意數量的文檔庫共享對象組成。
其中，如圖4所示，文檔庫輔助對象是指元數據對象、角色對象、許可權對象、外掛程式對象、索引信息對象、腳本對象、數字簽名對象、歷史痕跡對象等，文檔庫共享對象是指文檔庫中的不同文檔可能共同使用的對象，如字型檔對象、圖像對象等。
其中，如圖5所示，每個文檔集對象由一個或多個文檔對象、任意數量的文檔集對象和任意數量的文檔集輔助對象組成。文檔集輔助對象是指元數據對象、數字簽名對象、歷史痕跡對象。當文檔集對象包括多個文檔集對象時，其類似於資料夾包括多個資料夾的形式。
並且，如圖6所示，每個文檔對象由一個或多個頁面對象、任意數量的文檔輔助對象和任意數量的文檔共享對象組成。文檔輔助對象是指元數據對象、字型檔對象、導航信息對象、導讀信息對象、微縮版面對象、數字簽名對象、歷史痕跡對象等，文檔共享對象是指文檔中的不同頁面可能共同使用的對象，如圖像對象、印章對象等。
在圖7所示的頁面對象中，每個頁面對象由一個或多個層對象和任意數量的頁面輔助對象組成。頁面輔助對象是指元數據對象、數字簽名對象、歷史痕跡對象。
每個層對象由一個或多個版面對象、任意數量的對象組和任意數量的層輔助對象組成（如圖8所示）。層輔助對象是指元數據對象、數字簽名對象、歷史痕跡對象。對象組由任意數量的版面對象、任意數量的對象組和可選的數字簽名對象組成。當對象組包括多個對象組時，其類似於資料夾包括多個 資料夾的形式。
進一步，如圖9所示，版面對象是指狀態對象、文字對象、直線對象、曲線對象、圓弧對象、路徑對象、漸變色對象、圖像對象、流媒體對象、元數據對象、批註對象、語義信息對象、源檔案對象、腳本對象、外掛程式對象、二進制數據流對象、書籤對象以及超連結對象。
其中，狀態對象又是由任意數量的字元集對象、字型對象、字號對象、文字顏色對象，光柵操作對象、背景色對象、線顏色對象、填充色對象、線型對象、線寬對象、線接頭對象、畫刷對象、陰影對象、陰影顏色對象、旋轉對象、空心字對象、勾邊字對象、透明對象、渲染模式對象組成。
在具體實施過程中，可以在上述文檔模型基礎上進一步增強或簡化。如果在簡化模型中省略了文檔集對象，則文檔庫對象直接由文檔對象組成；如果在簡化模型中省略了層對象，則頁面對象直接由版面對象組成。最簡化的文檔模型是只有文檔對象、頁面對象、版面對象，其中版面對象只有文字對象、直線對象、圖像對象、字型對象、字號對象。完整模型和最簡化模型之間的各種中間模型都屬於該實施例的變種。
為了滿足各種套用對文檔安全性的需求，我們還需要定義一種通用的文檔安全模型。由於2005年12月之前軟體的文檔安全功能不夠強，或者是安全管理機制與文檔處理模組脫節，因此不難定義一個涵蓋並超越2005年12月之前套用軟體的通用文檔安全模型：
1.在文檔庫中定義了若干角色，角色對象是文檔庫的子對象
2.可以指定任意角色對任意對象（文檔庫、文檔集、文檔、頁、層、對象組、版面對象等）的訪問許可權。如果指定了對某個對象的訪問許可權，則該許可權將適用於其所有子對象
3.文檔庫系統實現的訪問許可權包括不可訪問、唯讀、只寫、讀寫。可以定義更多許可權（如不可列印），但需要由套用軟體來配合實現
4.角色可以對任意對象進行簽名。簽名範圍將包括該對象的所有子對象，以及所有引用到的對象
5.創建角色對象的指令返回一個密鑰，作為今後登錄該角色的依據，需要套用軟體妥善保管。該密鑰通常是PKI的私鑰
6.當套用軟體以某一角色身份登錄時，通常採用“挑戰—應答”機制，即文檔庫系統用保存的角色公鑰加密一塊數據發給套用軟體，套用軟體解密後返回給文檔庫系統，如果正確表明套用軟體確實擁有該角色對應的私鑰（為保險起見該認證過程可能會重複幾次）。採用“挑戰-應答”機制可以更好地保護私鑰的安全性
7.可以同時登錄多個角色，此時擁有的許可權是各角色許可權的並集在具體實施過程中，可以在上述安全模型基礎上進一步增強或簡化。上述安全模型的任何簡化模型都是該實施例的變種。
根據上述文檔模型、安全模型和常用的文檔操作，可以定義相應接口標準，用於傳送對文檔模型中各對象進行操作的指令。特別地，如果在接口標準中定義了獲取版面點陣圖的指令，將對保障版面一致性和文檔互操作性起到非常關鍵的作用。
通過獲取版面點陣圖的指令，套用軟體可以直接獲取指定頁面的指定點陣圖格式的版面點陣圖（用點陣圖方式表示的該頁面的顯示效果），而不用自行解釋處理每一個版面對象。也就是說，套用軟體可以直接獲得準確的版面點陣圖用於顯示/列印文檔，而不再需要自己挨個讀取頁面上每一層的每一個版面對象、自行解釋該對象的含義並在版面上體現出來。如果採用後一種方式的話，就又難免出2005年12月之前的軟體解釋的比較全、比較準確，有的軟體解釋的不全或不準確，導致同一個文檔在不同軟體出現不同的顯示/列印效果，影響了文檔互操作的用戶體驗。通過由文檔庫系統統一生成版面點陣圖的方式，將保持版面一致性的關鍵點從套用軟體移到了文檔庫系統，從而為不同的套用軟體打開同一文檔都能出現同樣的版面效果提供了可行之路。這一方面是因為文檔庫系統是統一的基礎技術平台，由少數幾家專業的技術廠商開發，肯定比各套用軟體廠商實現得完整、準確，要求各文檔庫系統都能完整準確地解釋處理各版面對象是可行的，而同樣的要求對套用軟體來說就不太可行了；另一方面是因為不同套用軟體都可以與同一個文檔庫系統配套使用，這樣就更能確保顯示/列印效果的一致性了。簡單來說，就是要求套用軟體之間保持一致不太可行，而要求文檔庫系統之間保持一致則是可行的，要求同一個文檔庫系統保持一致就更沒問題了。因此，為了保持同一文檔在不同套用軟體之間 的版面一致性，就需要把相關責任從套用軟體轉移到文檔庫系統，而由文檔庫系統來統一生成版面點陣圖是其中一個簡單易行的辦法。
更進一步，獲取版面點陣圖的指令還可以指定頁面上的一個區域，可用於只顯示頁面的一個區域（例如當頁面比螢幕大時就不需要顯示整頁，滾動頁面時也只需要重畫滾動的區域）；當該指令還允許指定獲取特定層組成的版面點陣圖，特別是可以指定由特定層以及該層下的所有層組成的版面點陣圖時，就可以很好地用於展現歷史痕跡，即可以看看在添加最近這一層以前是什麼樣，再往前又是什麼樣。如果需要的話，還可以具體指定哪一層參與點陣圖的生成，哪一層不參與。
在檢索查詢指令中，除了常規的關鍵字檢索外，還可以提供更加豐富的檢索手段。在常規的搜尋技術中，搜尋是和文檔處理分離的，搜尋程式只能從文檔中提取純文本信息，而無法獲取更多信息，只能基於文本信息檢索。但在該發明中，檢索查詢功能是集成在文檔處理的核心層（即文檔庫系統）的，這樣就可以更充分地利用文檔中蘊含的信息來提供更為強大的檢索手段，如：
1.基於字型信息的檢索，如檢索黑體字的“書生”，TimesNewRoman字型的“Sursen”
2.基於字號信息的檢索，如檢索三號字的“書生”，20磅以上的“Sursen”，長字（即字高超過字寬）的“文檔庫”
3.基於顏色的檢索，如檢索紅色的“書生”，藍色的“Sursen”
4.基於版面位置的檢索，如檢索位於頁面上半部分的“書生”，位於頁腳的“Sursen”
5.基於特殊修飾效果的檢索，如檢索斜體字的“書生”，順時針旋轉30度至90度之間的“Sursen”，空心字的“SEP”，勾邊字的“文檔庫”
6.根據類似的思路，還可以進一步提供其它類型的檢索，如檢索反白（黑底白字）的“書生”，壓圖的“Sursen”等
7.可以檢索多個版面對象的組合，如“書生”距離“Sursen”不超過5厘米
8.上述檢索條件的任意組合
現在介紹接口標準的實現方式。接口標準可以是上接口部按照預先定義的標準格式生成命令串（如“<UOML_INSERT（OBJ＝PAGE，PARENT＝123.456.789，POS＝3）/>”），將該命令串傳送給下接口部，並從下接口部接收執行結果或其它反饋信息；或者是下接口部提供一些具有標準名稱和參數的接口函式（如“BOOLUOI_InsertPage（UOI_Doc*pDoc，intnPage）”），上接口部直接調用這些標準函式；或者是上述方法的組合。
接口標準還可以用“動作+對象”的方式來定義，這樣便於學習和理解，也便於保持接口標準的穩定性。例如，對20種不同對象進行10種操作，可以定義20x10＝200種指令，也可以定義20種對象和10種動作，但顯然後一種方式大大減輕了記憶的負擔，而且今後在對接口標準進行擴充時，增加一個對象或動作也很簡單。
例如，我們定義以下7種動作：
打開：用於創建或打開文檔庫；
關閉：用於關閉會話句柄、關閉文檔庫；
獲取：用於獲取對象列表、對象相關屬性和數據；
設定：用於設定/修改對象數據；
插入：插入指定對象或數據；
刪除：用於刪除對象的某個子對象；
檢索查詢：用於根據定義條件在文檔中找到符合條件的內容，這些條件既可以是準確的信息，也可以是不準確的信息（模糊查找）
我們再定義如下對象：文檔庫、文檔集、文檔、頁、層、對象組、文字、圖像、圖形、路徑（由一組順序圖形連線組成，可以是閉合也可以不閉合的）、源檔案、腳本、外掛程式、音頻、視頻、角色等。
對象還包括下列狀態對象：背景色、線的顏色、填充色、線型、線寬、ROP、畫刷、陰影、陰影顏色、字元高、字元寬、旋轉、透明、渲染模式等。
在採用“動作+對象”方式時，不能自動理解為每一個對象和每一個動作的所有組合都一定能構成有實際意義的操作指令，在很多實施例中會存在一些組合是沒有意義的，就象不是所有動詞和所有名詞都能組成以意義的詞組一樣。
以下是用“動作+對象”的格式定義命令的一種實施例，該實施例被稱為UOML，是用XML描述的一系列的命令。上接口部生成符合UOML格式的字元串，並將該字元串傳送給下接口部，就將相應的操作指令傳送給了文檔庫系統。文檔庫系統執行這些命令後，下接口部將執行結果也生成一個符合UOML格式的字元串，返回給上接口部，使套用軟體能夠知曉操作執行結果。
所有執行結果都由UOML_RET表示，其定義如下：
屬性：
SUCCESS：為true時表明操作成功，否則失敗
子元素：
ERR_INFO：可選，僅當操作失敗時出現，描述了相應的錯誤信息。
其它子元素：根據具體命令確定，可參考各命令說明。
UOML動作包括：：
1UOML_OPEN創建或打開文檔庫
1.1屬性
1.1.1create：為true時是創建，否則是打開已有文檔庫
1.2子元素：
1.2.1path：文檔庫路徑。可以是磁碟檔案名稱，也可以是URL，或者是記憶體指針，或者是網路路徑，或者是文檔庫的邏輯名稱，或者其它能夠指定文檔庫的表示方法。可以用不同特徵的字元串區分上述各種情況，即不用改變命令格式，只要給字元串設定不同特徵，就可以用不同的方法指定文檔庫。例如，磁碟檔案名稱採用設備名稱（如盤符）和“:”開頭（如“C:”、“D:”），而且緊跟著“:”不會是“//”，也不會是又一個“:”；URL採用協定名稱和“://”開頭（如“ http://”）；記憶體指針用“MEM::”開頭，後面是指針的字元串表示方式，例如“MEM::1234:5678”；網路路徑是“\\”開頭，後面是伺服器名，以及伺服器上的路徑，如“ \\server\abc\def.sep”；文檔庫的邏輯名稱可以用“*”開頭，如“*MyDocBasel”。在下接口解析時，如果第一個字母是“*”就表明該字元串代表文檔庫的邏輯名稱；否則如果頭兩個字母是“\\”就表明該字元串代表網路路徑；否則如果頭五個字母是“MEM::”就表明該字元串代表記憶體指針；否則尋找字元串的第一個“:”，如果該“:”後面是“//” 該就表明字元串代表URL，否則就代表本地設備上的檔案。對於打開伺服器上的文檔庫的情形，可以設立一個專門的URL協定來區分，例如用“Docbase://myserver/mydoc2”指明打開服務myserver上運行的文檔庫系統伺服器系統所管理的mydoc2文檔庫。
總之，只要能給字元串設定不同特徵，就可以用不同的方式來指定文檔庫。根據上述說明，我們還可以定義各種不同的字元串特徵；該方式不僅能套用於指定文檔庫路徑，還能套用於其它場合，特別是用來指定特定資源位置的套用場合。在很多情況下，我們希望能夠用一種新方式來指定相關資源，但又不能或不希望改變2005年12月之前的協定或函式，這時就可以通過在字元串中設定不同特徵的方式來指定，因為這種方法具有最好的通用性（任何協定或函式，只要支持磁碟檔案名稱或URL，就支持字元串）。
1.3返回值：如果成功，則在UOMLRET中包含一個“handle”子元素，記錄句柄2關閉（UOML_CLOSE）
2.1屬性：無
2.2子元素：
2.2.1handle：對象句柄，是一個字元串表示的對象的引用指針
2.2.2db_handle：文檔庫句柄，字元串表示的文檔庫的引用指針
2.3返回值：無返回值
3UOML_GET獲取
3.1屬性
3.1.1usage：用途，為”GetHandle”（獲取指定對象句柄）、”GetObj”（獲取指定對象數據）、”GetPageBmp”（獲取版面點陣圖）中的一個
3.2子元素
3.2.1parent：父對象句柄，usage屬性為”GetHandle”時使用
3.2.2pos：位置順序號，usage屬性為”GetHandle”時使用
3.2.3handle：指定對象的句柄，當usage屬性為”GetObj”時使用
3.2.4page：需要顯示的頁面的句柄，當usage屬性為”GetPageBmp” 時使用
3.2.5input：描述了對輸入頁面的約束，其中可以指定顯示一層或者多層的內容（可以顯示的層一定是當前角色有許可權訪問的層）；也可以通過指定Clip區域來指定顯示區域的大小。當usage屬性為”GetPageBmp”時使用
3.2.6output：描述了版面點陣圖的輸出方式，當usage屬性為”GetPageBmp”時使用
3.3返回值：
3.3.1當usage屬性為”GetHandle”時，執行成功時在UOML_RET中包含一個“handle”子元素，記錄parent下第pos個子對象的句柄
3.3.2當usage屬性為”GetObj”時，執行成功時在UOML_RET中包含一個“xobj”子元素，含有handle對象的數據的xml表示
3.3.3當usage屬性為”GetPageBmp”時，執行成功時在output指定位置輸出版面點陣圖
4UOML_SET設定
4.1屬性：無
4.2子元素：
4.2.1Handle：設定對象的句柄
4.2.2xobj：對象的描述
4.3返回值：無返回值
5UOML_INSERT插入
5.1屬性：無
5.2子元素：
5.2.1parent：父對象句柄
5.2.2xobj：對象的描述
5.2.3pos：插入位置
5.3返回值：如果執行成功，則將xobj參數表示的對象，插入到parent中成為其第pos個子對象，並在UOML_RET中包含一個”handle”子元素，表 示新插入對象的句柄
6UOML_DELETE刪除
6.1屬性：無
6.2子元素：
6.2.1handle：需要刪除的對象的句柄。
6.3返回值：無返回值
7UOML_QUERY檢索查詢
7.1屬性：無
7.2子元素：
7.2.1handle：需要查詢的文檔庫句柄
7.2.2condition：查詢條件
7.3返回值：如果成功，在UOML_RET中包含一個“handle”子元素代表查詢結果的句柄，一個“number”子元素代表查詢結果的數量，可以用UOML_GET來獲取每一個查詢結果
UOML對象包括：
文檔庫（UOML_DOCBASE）、文檔集（UOML_DOCSET）、文檔（UOML_DOC）、頁（UOML_PAGE）、層（UOML_LAYER）、對象組（UOML_OBJGROUP）、文字（UOML_TEXT）、圖像（UOML_IMAGE）、直線（UOML_LINE）、曲線（UOML_BEIZER）、圓弧（UOML_ARC）、路徑（UOML_PATH）、源檔案（UOML_SRCFILE）、背景色（UOML_BACKCOLOR）、前景顏色（UOML_COLOR）、ROP（UOML_ROP）、字元尺寸（UOML_CHARSIZE）、字型（UOML_TYPEFACE）。
以下我們以UOML_DOC、UOML_TEXT和UOML_CHARSIZE為例說明其定義方式：
1UOML_DOC
1.1屬性：無
1.2子元素：
1.2.1metadata：元數據
1.2.2pageset：各頁面
1.2.3fontinfo：嵌入字型檔
1.2.4navigation：導航信息
1.2.5thread：導讀信息
1.2.6minipage：微縮版面
1.2.7signiture：數字簽名
1.2.8sharesource：共享資源
2UOML_TEXT
2.1屬性：
2.1.1Encoding：文字編碼方式
2.2子元素：
2.2.1TextData：文字內容
2.2.2CharSpacingList：對非等間距文字的字間距列表
2.2.3StartPos：起點位置
3UOML_CHARSIZE
3.1屬性：
3.1.1width：字元寬度
3.1.2height：字元高度
3.2子元素：無
以此類推，我們可以用同樣的方法來描述所有的UOML對象。當套用軟體對文檔庫進行操作時，由上述UOML動作與UOML對象依照XML語法生成相應的UOML命令，將該UOML命令發給文檔庫系統即代表向文檔庫系統發出了相應操作指令。
例如，對創建文檔庫操作，可以用以下命令來完成：
<UOML_OPENcreate＝″true″>
<pathval＝″f:\\data\\docbasel.sep″/>
</UOML_OPEN>
對創建文檔集操作，可以用以下命令來完成：
<UOML_INSERT>
<parentval＝″123.456.789″/>
<posval＝″1″/>
<xobj>
<docset/>
</xobj>
</UOML_INSERT>
需要說明的是，雖然UOML是用XML定義的，但為了顯得更加簡潔，我們在前面省略了類似“<？xmlversion＝″1.0″encoding＝″UTF-8″？>”以及“xmlns:xsi＝″ http://www.w3.org/2001/XMLSchema-instance″”之類的常規XML格式，只要是熟悉XML語法的實施者都可以在實施過程中自行添加。
我們也可以不用XML方式定義命令串，例如改用類似PostScript那樣的方式，這樣上例變成這樣的：
1，″f:\\data\\docbasel.sep″，/Open
/docset，1，“123.456.789”，/Insert
根據同樣的思路，我們還可以定義出其它類型的命令串格式，甚至我們還可以不用文本方式，而用二進制方式來定義命令串。
除了“動作+對象”方式外，我們也可以用其它方式定義命令串。例如，對每一個對象的每一個操作都用一個命令來表示，即用“UOML_INSERT_DOCSET”來表示插入一個文檔集，用“UOML_INSERT_PAGE”來表示插入一頁，我們以這樣的方式來定義每個命令：
UOML_INSERT_DOCSET在文檔庫中創建一個文檔集
屬性：無
子元素：
parent：文檔庫句柄
pos：插入位置
返回值：如果執行成功，則在UOML_RET中包含一個”handle”子
元素，表示新插入文檔集的句柄
這樣上例就變為：
<UOML_INSERT_DOCSET>
<parentval＝″123.456.789″/>
<posval＝″1″/>
</UOML_INSERT_DOCSET>
用這種方法定義命令格式的話就需要對每個對象的每種合法操作都單獨定義一條命令，會比較繁瑣。
接口標準也可以用函式調用的方式來實施，即通過上接口調用下接口的接口函式的方式來傳送操作指令給文檔庫系統的：
以下以C++語言為例說明，該實施例稱為UOI。
我們先定義一個UOI返回值結構：
structUOI_Ret{
BOOLm_bSuccess；
CStringm_ErrInfo；
}；
定義所有UOI對象的基礎類：
classUOI_Object{
public:
enumType{
TYPE_DOCBASE，
TYPE_DOCSET，
TYPE_DOC，
TYPE_PAGE，
TYPE_LAYER，
TYPE_TEXT，
TYPE_CHARSIZE，
……
}；
Typem_Type；
UOI_Object（）；
virtual～UOI_Object（）；
staticUOI_ObjectCreate（TypeobjType）；
}；
然後定義如下幾個UOI函式，與第一個實施例中的幾個UOML動作相對應：
UOI_RETUOI_Open（char*path，BOOLbCreate，HANDLE*pHandle）；
UOI_RETUOI_Close（HANDLEhandle，HANDLEdb_handle）；
UOI_RETUOI_GetHandle（HANDLEhParent，intnPos，HANDLE*pHandle）；
UOI_RETUOI_GetObjType（HANDLEhandle，UOI_Object::Type*pType）；
UOI_RETUOI_GetObj（HANDLEhandle，UOI_Object*pObj）；
UOI_RETUOI_GetPageBmp（HANDLEhPage，RECTrect，void*pBuf）；
UOI_RETUOI_SetObj（HANDLEhandle，UOI_Object*pObj）；
UOI_RETUOI_Insert（HANDLEhParent，intnPos，UOI_Object*pObj，HANDLE*pHandle＝NULL）；
UOI_RETUOI_Delete（HANDLEhandle）；
UOI_RETUOI_Query（HANDLEhDocbase，constchar*strCondition，HANDLE*phResult）；
然後定義各UOI對象，依然以UOI_Doc、UOI_Text和UOML_CharSize為例說明：
classUOI_Doc:publicUOI_Object{
public:
UOI_MetaDatam_MetaData；
intm_nPages；
UOI_Pagem_pPages；
intm_nFonts；
UOI_Fontm_pFonts；
UOI_Navigationm_Navigation；
UOI_Threadm_Thread；
UOI_MiniPagem_pMiniPages；
UOI_Signaturem_Signature；
intm_nShared；
UOI_Objm_pShared；
UOI_Doc（）；
virtual～UOI_Doc（）；
}；
classUOI_Text:publicUOI_Object{
public:
enumEncoding{
ENCODE_ASCII，
ENCODE_GB13000，
ENCODE_UNICODE，
……
}；
Encodingm_Encoding；
charm_pText；
Pointm_Start；
intm_CharSpace；
UOI_Text（）；
virtual～UOI_Text（）；
}；
classUOI_CharSize:publicUOI_Object{
public:
intm_Width；
intm_Height；
UOI_CharSize（）；
virtual～UOI_CharSize（）；
}；
以下示例說明UOI的使用方法。首先是創建文檔庫操作：
ret＝UOI_Open（″f:\\data\\docbasel.sep″，TRUE，&hDocBase）；
然後是構建一個創建新對象的函式：
HANDLEInsertNewObj（HANDLEhParent，intnPos，UOI_Object::Typetype）
{
UOI_Retret；
HADNLEhandle；
UOI_ObjpNewObj＝UOI_Obj::Create（type）；
if（pNewObj＝＝NULL）
returnNULL；
ret＝UOI_Insert（hParent，nPos，pNewObj，&handle）；
deletepNewObj；
returnret.m_bSuccess？handle:NULL；
}
然後是直接獲取對象的函式：
UOI_Obj*GetObj（HANDLEhandle）
{
UOI_Retret；
UOI_Object::Typetype；
UOI_ObjpObj；
ret＝UOI_GetObjType（handle，&type）；
if（！ret.m_bSuccess）
returnNULL；
pObj＝UOI_Obj::Create（type）；
if（pObj＝＝NULL）
returnNULL；
ret＝UOI_GetObj（handle，pObj）；
if（！ret.m_bSuccess）{
deletepObj；
returnNULL；
}
returnpObj；
}
我們還可以用非“動作+對象”的函式方式來定義接口標準，例如對每一個對象的每一種操作都定義一個接口函式，這樣插入文檔集的操作指令就是上接口以下列方式調用下接口的接口函式來傳送給文檔庫系統的：
UOI_InsertDocset（pDocbase，0）；
我們還可以封裝各個對象類（如文檔庫類），把該對象可以進行的操作定義成該類的方法，如：
classUOI_DocBase:publicUOI_Obj
{
public:
/*！
*\brief創建文檔庫
*\paramszPath：文檔庫全路徑
*\parambOverride：是否覆蓋原檔案
*\returnUOIDocBase對象
*/
BOOLCreate（constchar*szPath，boolbOverride＝false）；
/*！
*\brief打開文檔庫
*\paramszPath：文檔庫全路徑
*\returnUOI_DocBase對象
*/
BOOLOpen（constchar*szPath）；
/*！
*\brief關閉文檔庫
*\param無
*\return無
*/
voidClose（）；
/*！
*\brief獲取角色列表
*\param無
*\returnUOI_RoleList對象
*\saUOI_RoleList
*/
UOI_RoleListGetRoleList（）；
/*！
*\brief存儲文檔庫
*\paramszPath：存儲文檔庫全路徑
*\return無
*/
voidSave（char*szPath＝0）；
/*！
*\brief插入文檔集
*\paramnPos：插入文檔集的位置
*\returnUOI_DocSet對象
*\saUOI_DocSet
*/
UOI_DocSetInsertDocSet（intnPos）；
/*！
*\brief獲取指定索引的文檔集
*\paramnIndex：文檔列表的索引號
*\returnUOI_DocSet對象
*\saUOI_DocSet
*/
UOI_DocSetGetDocSet（intnIndex）；
/*！
*\brief獲取文檔集的總數
*\param無
*\return文檔集個數
*/
intGetDocSetCount（）；
/*！
*\brief設定文檔庫的名稱
*\paramnLen：文檔庫名稱長度
*\paramszName：文檔庫名稱
*\return無
*/
voidSetName（intnLen，constchar*szName）；
/*！
*\brief獲取文檔庫名稱長度
*\param無
*\return長度
*/
intGetNameLen（）；
/*！
*\brief獲取文檔庫名稱
*\param無
*\return文檔庫名稱
*/
constchar*GetName（）；
/*！
*\brief獲取文檔庫id長度
*\param無
*\return長度
*/
intGetIDLen（）；
/*！
*\brief獲取文檔庫id
*\param無
*\returnid
*/
constchar*GetID（）；
//！構造函式
UOI_DocBase（）；
//！析構函式
virtual～UOI_DocBase（）；
}；
這樣插入文檔集的操作指令就是上接口以下列方式調用下接口的接口函式來傳送給文檔庫系統的：
pDocBase.InsertDocset（0）；
我們還可以用同樣的方法為Java、C#、VB、Delphi等各種程式語言開發的套用軟體設計各種不同的接口標準。
只要在接口標準中不含有與特定的作業系統（如WINDOWS、UNIX/LINUX、MACOS、SYMBIAN）或特定的硬體平台（如x86CPU、MIPS、POWERPC等）相關連的特徵，該接口標準就可以具有跨平台性，使得不同平台上運行的套用軟體和文檔庫系統都可以統一使用同樣的接口標準，特別是可以讓一個平台上運行的套用軟體可以調用另一個平台上運行的文檔庫系統來執行相應操作。例如，套用軟體部署在客戶端，使用的是PC機，Windows作業系統，文檔庫系統部署在伺服器端，使用的是大型機，Linux作業系統，但套用軟體依然可以像調用本地文檔庫系統一樣調用伺服器上的文檔庫系統來執行相應文檔操作。
如果在接口標準中不含有與特定程式語言相關的特徵，則該接口標準還能做到與程式語言無關。可以看出，用命令串的方式容易構造與平台無關、與程式語言無關的接口標準，更具有通用性。特別是用XML來構造命令串的話，由於2005年12月之前在各種不同平台、不同程式語言都存在易於獲得的XML生成解析工具，因此不僅該接口標準具有很好的跨平台性和與程式語言無關性，也非常便於工程師開發上接口部和下接口部。
以上列舉了多種接口標準的實施方法，按照類似的思路，不難設計出更多種類的接口標準。
接口標準可以在上述實施例的基礎上按同樣的思路增加操作指令，也可以簡化操作指令，特別是文檔模型被簡化時操作指令也會相應被簡化。最簡化情況下只有文檔的創建、頁面的創建、各版面對象的創建這幾個操作指令。
現在，返回圖1，繼續描述依照該發明的文檔作業系統的工作過程。
套用軟體可以是具有符合接口標準的上接口部的任意軟體，例如Office軟體、內容管理、資源採集等。任一套用軟體在需要對文檔進行操作時，依照前述方法將指令傳遞給文檔庫系統，文檔庫系統根據指令來完成具體操作過程。
文檔庫系統可以自由地存儲、組織文檔庫數據，例如可以把一個文檔庫的檔案全部都存儲在一個磁碟檔案中；可以一個文檔對應一個磁碟檔案，利用作業系統中的檔案系統功能實現多文檔組織；也可以一頁對應一個磁碟檔案；還可以完全拋開作業系統，在磁碟上留出一塊空間後直接對磁軌、扇區 進行管理。對文檔庫數據的存儲格式，可以用二進制格式保存，可以用XML，還可以用二進制XML。頁面描述語言（定義頁面上的文字、圖形、圖像等對象的方法）可以用PostScript，可以用PDF，可以用SPD（書生公司使用的頁面描述語言），當然也可以自定義。總之，只要能夠實現接口標準所定義的功能，任何實現方式都是可以的。
例如，我們可以用XML來描述文檔庫數據，當文檔模型是層次型的時候，可以完全對照建立相應的XML樹。執行創建操作時就在XML樹中增加一個結點，執行刪除操作就刪掉相應結點，執行設定操作就設定相應結點的屬性，執行獲取操作就取出相應結點的屬性並返回給套用軟體，執行查詢操作時就遍歷相關結點查找。
以下是該實施例的進一步說明：
1.用XML來描述每個對象。也就是說，為每個對象都建立了一個對應的XML樹。有的對象屬性比較簡單，其對應的XML樹就只有根結點，有的對象比較複雜，其對應的XML樹還有子結點。具體描述方法可以參見前面用XML來定義操作對象的說明。
2.當新建一個文檔庫時就新建一個根結點為文檔庫對象的XML檔案
3.每當在文檔庫中插入一個對象時（如文字對象），就將該對象對應的XML樹插入到插入位置的父結點（如層）之下。這樣，文檔庫中的每個對象都在文檔庫為根結點的XML樹中有一個對應的結點
4.當刪除一個對象時，就刪除該對象對應的結點，其下屬所有子結點也都被刪除。刪除過程是從葉子結點開始自下而上遍歷的
5.設定一個對象屬性時，將該對象對應的結點的屬性設定成該屬性。如果該屬性是用子結點表示的，則設定對應的子結點
6.獲取一個對象屬性時，訪問該對象對應的結點，根據該結點的屬性和子結點獲得該對象的屬性
7.獲取一個對象的句柄時，返回該對象對應結點的XML路徑
8.複製一個對象（如頁面）到指定位置時，就將該對象對應的結點開始的整個子樹都複製到目標位置對應的父結點（如文檔）之下。如果是複製到另一個文檔庫中，則需要將該子樹引用的對象（如嵌入字型檔）也一起複製過 去
9.執行獲取版面信息指令時，先生成一個指定點陣圖格式的空白點陣圖，其尺寸和指定區域相同，然後遍歷指定頁面的所有版面對象，凡是位於指定區域內（包括只有一部分在該區域內）的版面對象，都解釋其含義，並在版面上相應體現。具體過程雖然比較複雜比較專業，但均屬於2005年12月之前RIP技術範疇，不在此贅述。
10.在創建角色對象時，生成一對隨機公私鑰對（例如512位的RSA密鑰），將公鑰存儲在角色對象中，將私鑰返回給套用軟體
11.當套用軟體登錄時，隨機生成一塊（例如128位元組）數據，用相應角色對象中的公鑰加密該數據發給套用軟體，套用軟體解密後比較驗證，如果正確則表明套用軟體確實擁有該角色對應的私鑰，登錄成功。為保險起見，該認證過程可以重複三次，三次全部通過才算登錄成功
12.當對某一對象進行簽名時，也就是對其對應的結點開始的子樹進行簽名。為了能夠使簽名不受具體物理存儲方式的影響，需要先做一個正則化，使得邏輯上等效的變化（例如存儲位置的改變導致相應指針的變化）不會影響簽名有效性。該正則化的方法如下：
a）對樹的某一結點，先將該結點的子結點數計算HASH值，然後再依次計算其類型和各個屬性的HASH值，按順序連線在子結點數HASH值的後面。對連線的結果再計算其HASH值，得到該結點的正則結果；
b）從子樹的根節點開始，按照上述方法計算該結點的正則結果，並對其所有子結點，按照從左到右順序依次計算其正則結果，將子結點的正則結果按順序附加到父結點正則結果之後；
c）這是一個深度優先的遞歸過程。遞歸結束之後，即得到最終結果。
d）如果需要對被引用的對象也一起做簽名，則可以將被引用對象也作為一個字結點處理，方法同上
正則化以後，再做HASH並用角色的私鑰進行簽名就屬於2005年12月之前技術了。
在上述正則化過程中，我們可以把a）改成如下方案：對樹的某一結點，將該結點的子結點數、類型及其各屬性用分隔設定隔開後按照順序連線起來，對連線的結果計算其HASH值，得到該結點的正則結果；
我們還可以把a）改成如下方案：對樹的某一結點，其子結點數、類型及其各屬性的長度用分隔設定隔開後按照順序連線起來，再與子結點數、類型、各屬性連線起來，即為該結點的正則結果；
總之，a）可以是以下各種方案中的任意一種：對樹的某一結點，其子結點數、類型、各屬性，子結點數/類型/各屬性的長度（可選的），原值或經過特定變換（如HASH、壓縮），按照預定順序連線起來（直接連線或用分隔設定隔開）
上述預定順序的意思是，子結點數長度、類型長度、各屬性長度、子結點數、類型、各屬性可以按任意順序排列，只要是預定的順序即可
b）、c）步驟也可以改為寬度優先
我們不難給出上述方案的各種變化方式，如每個結點的子結點數用分隔設定隔開後按照深度優先的順序連線起來，再與各結點其它數據的正則結果連線起來。總之，只要對該子樹中的所有結點的子結點數、類型和各屬性，按照確定的方法排列在一起就屬於該實施例的變種
13.當對某一對象設定許可權時，最簡單的實現方式是簡單記錄各角色對該對象（及其子對象）的許可權，並在今後各角色訪問時加以比較，符合許可權的則允許相應操作，否則報錯返回。更好的實現方式是對相應數據加密，並用密鑰來控制許可權，如果該角色沒有相應密鑰就沒有對應的許可權，這種方式抗攻擊能力要更強。具體方案為：
a）對受保護的數據區域（通常為一個子樹，對應某對象及其所有子對象），有一對對應的PKI密鑰對，用其中的加密密鑰對該數據區域進行加密
b）對具有讀許可權的角色，授予其解密密鑰，該角色可以用該密鑰解密該數據區域，從而正確讀取這些數據
c）對具有寫許可權的角色，將授予其加密密鑰，該角色可以將修改後的數據用該密鑰加密，從而可以正確寫入該區域的數據
d）鑒於PKI的加密/解密效率較低，為提高運行效率，也可以用對稱密鑰來對該數據區域加密，加密密鑰用於對該對稱密鑰進行加密，解密密鑰用於解密經過加密後的密鑰數據，從而獲得正確的對稱密鑰。為防止只有讀許可權的角色在獲得對稱密鑰後用其修改數據，可以用加密密鑰來對該數據 區域進行數字簽名，每次擁有寫許可權的角色修改該數據區域後都重新做一次簽名，從而確保數據不會被沒有寫許可權的角色篡改
e）當授予某一角色加密密鑰或解密密鑰時，可以用該角色的公鑰對該密鑰加密後存儲，這樣只有擁有該角色的私鑰時才能取出該密鑰
該發明中所說明的文檔安全技術，如基於角色的許可權管理、角色的認證方式、多重角色登入、對樹結構的正則化技術、細粒度的許可權管理單元、基於加密的許可權設定等，都不僅適用於該發明所述的文檔處理系統，還可以運用於更為廣泛的其它套用場合。
在該發明中，為了使本文檔處理系統能很好地模擬紙張的特性，提供了一種“只加不改”的技術方案。也就是說，每個套用軟體都只在2005年12月之前文檔內容基礎上添加新的內容，但不修改、不刪除已有的內容，使文檔的一個頁面就象一張紙一樣，可以由不同的人用不同的筆在紙上不斷寫寫畫畫，但誰都不能修改、刪除已有內容。具體方法是每個文檔的每一層只由一個套用軟體來管理和維護，即每一個套用軟體在編輯其它軟體生成的文檔時，都在2005年12月之前文檔基礎上新增加一層，將本軟體新編輯的內容都放到這一層中，不修改和刪除前面各層的內容。由於2005年12月之前社會就是基於紙張來運轉的，因此只要能符合紙張的特性就能滿足2005年12月之前套用的需求，具備足夠的實用價值。
為了確保每一層內容在生成後沒有被修改、刪除，我們可以利用每一層的數字簽名對象。數字簽名可以是對本層內容進行簽名，更可以是對本層以及本層下面的所有層的內容一起簽名。簽名以後並不妨礙對文檔做進一步的批註等編輯，只要新的內容是位於新建的層，沒有修改破壞簽名時存在的各層，簽名依然是有效的，但簽名者只對簽名以前的內容負責，不對簽名以後的內容負責。這是一個非常符合套用需求的技術方案，具有很大的實用價值。相比之下，2005年12月之前的其它技術或者簽名後不允許編輯，或者編輯後（儘管是“只加不改”的編輯）簽名被破壞。
前述技術方案不允許修改文檔中的已有內容，即使不考慮與紙張特性的兼容以及數字簽名問題，需要修改的話也只能做版面級編輯，即對每個版面對象的編輯（增、刪、改）都不會對其它版面對象產生影響（這是由於通用文檔模型是基於可見部分為基礎構建的，不包含大量不可見的、關於版面對 象之間的關係，因此修改任何一個版面對象時，其它版面對象不會產生相應的調整，例如刪掉一個字，就會在其位置留下空白，右邊的文字不會自動左移）。如果用戶需要對文檔中的已有內容進行編輯，並且還希望能像在原來那樣編輯的話，有一個技術方案可以很好地滿足這個套用需求。該方案是當套用軟體完成初始編輯時，除了新建一層存放當前編輯的內容外，還將源檔案（按照套用軟體自有的格式存儲，記錄了各對象之間完整關係的檔案，例如.doc檔案）嵌入到文檔中。當下次需要進行繼續編輯時，從文檔中取出該源檔案，並使用該源檔案繼續編輯。編輯完成後清除該軟體所管理的那一層，重新生成該層的內容，並繼續將新修改的源檔案嵌入到文檔中。
具體方法如下：
1.套用軟體第一次處理該文檔時，新建一層，將新編輯內容對應的版面對象插入到新建層中，同時用自身格式另外儲存一份新編輯的內容（即源檔案）
2.在文檔對象中新建一個源檔案子對象，用來嵌入源檔案（例如用二進制數據的方式整體嵌入），並記錄是哪一層對應該源檔案對象
3.用同一套用軟體再次編輯該文檔時，從對應的源檔案對象中取出對應的源檔案
4.使用該源檔案繼續編輯該層內容。由於該源檔案是該套用軟體自身的格式，可以按照該套用軟體自身的功能繼續對該層內容進行編輯
5.再次編輯結束後，根據新編輯後的結果更新該層內容（例如用全部清除後全部重新生成的方式），同時將新修改後的源檔案重新嵌入到文檔對象中
6.如此循環往復，就可以用原有套用軟體按照原有方式對文檔中的已有內容進行編輯
採用上述技術方案，可以最大程度地實現文檔的互操作性。在套用軟體、文檔都採用該發明技術時，可以實現（如果有足夠安全許可權的話）：
1.對任何文檔，用任何套用軟體都可以正確打開、顯示、列印
2.對任何文檔，用任何套用軟體都可以新添加任何內容，而且不會破壞文檔已有簽名
3.對任何文檔，在不必考慮文檔已有簽名（沒有簽名或者雖有簽名但允許破壞）的前提下，用任何套用軟體都可以對文檔已有內容進行版面級編輯
4.對任何文檔，使用文檔已有內容的原始編輯軟體可以對該內容進行正常編輯
由此可見，通過該發明中對層的管理，對文檔的管理、互操作、安全設定都帶來極大的便利。
下面我們以A軟體創建一個文檔並且B軟體對其進行編輯為例說明其工作過程。為了節約篇幅起見，在本例中我們選用UOI作為接口標準：
1.A軟體發出指令，創建文檔庫c:\sample\mydocbase.sep，將其句柄存放在hDocBase：
UOI_Open（“c:\\sample\\mydocbase.sep”，TRUE，&hDocBase）；
2.A軟體發出指令，在文檔庫hDocBase中新建文檔集，將其句柄存放在hDocSet：
hDocSet＝InsertNewObj（hDocBase，0，UOI_Obj::TYPE_DOCSET）；
3.A軟體發出指令，在文檔集hDocBase中新建文檔，將其句柄存放在hDoc：
hDoc＝InsertNewObj（hDocSet，0，UOI_Obj::TYPE_DOC）；
4.A軟體發出指令，在文檔hDoc中新建一頁，版心大小是寬w，高h，將其句柄存放在hPage：
UOI_Pagepage；
page.size.w＝w；
page.size.h＝h；
UOI_Insert（hDoc，0，&page，&hPage）；
5.A軟體發出指令，在頁hPage中創建一層，將其句柄存放在hLayer：
hLayer＝InertNewObj（hPage，0，UOI_Obj::TYPE_LAYER）；
6.A軟體發出指令，設定字號為s：
UOI_CharSizecharSize；
charSize.m_Width＝charSize.m_Height＝s；
UOI_Insert（hLayer，0，&charSize）；
7.A軟體發出指令，在坐標（x1，y1）位置插入文字串“書生意氣揮斥 方遒”：
UOI_Texttext；
text.m_pText＝Duplicate（“書生意氣揮斥方遒”）；
text.m_Encoding＝UOI_Text::ENCODEGB13000；
text.m_Start.x＝x1；
text.m_Start.y＝y1；
UOI_Insert（hLayer，1，&text）；
8.A軟體發出指令，關閉文檔庫hDocBase：
UOI_Close（hDocBase）；
9.B軟體發出指令，打開文檔庫c:\sample\mydocbase.sep，將其句柄存放在hDocBase：
UOI_Open（“c:\\sample\\mydocbase.sep”，FALSE，&hDocBase）；
10.B軟體發出指令，獲取文檔庫hDocBase第一個文檔集的指針，將其句柄存放在hDocSet.
UOI_GetHandle（hDocBase，0，&hDocSet）；
11.B軟體發出指令，獲取文檔集hDocSet第一個文檔的指針，將其句柄存放在hDoc：
UOI_GetHandle（hDocSet，0，&hDoc）；
12.B軟體發出指令，獲取文檔hDoc第一頁的指針，將其句柄存放在hPage：
UOI_GetHandle（hDoc，0，&hPage）；
13.B軟體獲取該頁版面點陣圖，用於顯示該頁
UOI_GetPageBmp（hPage，rect，buf）；
14.B軟體發出指令，獲取hPage第一層的指針，將其句柄存放在hLayer：
UOI_GetHandle（hPage，0，&hLayer）；
15.B軟體發出指令，獲取第一個版面對象的句柄hObj：
UOI_GetHandle（hLayer，0，&hObj）；
16.B軟體發出指令，獲取hObj的類型
UOI_GetObjType（hObj，&type）；
17.B軟體發現這是一個字號對象，獲取該對象
UOI_GetObj（hObj，&charSize）；
18.B軟體將字高放大一倍：
charSize.m_Height*＝2；
UOI_SetObj（hObj，&charSize）；
B軟體重新獲取版面點陣圖並顯示，這時會發現螢幕上的“書生意氣揮斥方遒”變成長體字了
下面，參照圖10描述依照該發明的文檔作業系統執行一操作的一個例子。在該例子中，套用軟體通過統一的接口標準（UOML接口）請求對文檔的操作。文檔庫系統可能會有不同廠商的不同型號，但是對於套用開發廠商來說面向的都是同一個接口標準，因此都可以與之配套使用。
在該發明中，不同的套用軟體可以同時或不同時調用同一個文檔庫系統，同一套用軟體可以同時或不同時調用不同的文檔庫系統。
依照該發明，使得套用層和數據處理層分離，使得同一文檔能在不同的套用軟體之間通用，使不同套用軟體之間具有良好的文檔互操作性。
依照該發明，形成產業分工，減少重複開發，並更加專業、完備、正確；對文檔的基本操作都在文檔庫系統中處理，各套用軟體不必重複開發。而且由於文檔庫系統是由專業廠商開發，相關技術的專業性、完備性、正確性較有保障，而且套用軟體廠商和用戶可以選擇做的最好的一家文檔庫系統廠商，從而保證處理效果的正確性和一致性。
依照該發明，提供多文檔甚至海量文檔的管理機制，使文檔之間能夠有效組織起來，便於檢索、查詢、保管，便於嵌入較強的信息安全機制。
依照該發明，提供更好的安全機制，可以設定多種角色，細粒度地設定每個角色的許可權。其中細粒度是雙重的，一方面可以對整個文檔或文檔的一個細微之處進行許可權設定，另一方面可以設定種類非常多的許可權，而不僅僅是傳統的讀/寫/不可訪問三級。
依照該發明，鼓勵創新，合理競爭。形成合理的產業分工後，各文檔庫系統廠商和各套用軟體廠商就會在領域展開競爭，而不會再出現Microsoft Word一樣靠文檔格式來壟斷套用軟體的情形發生。各文檔庫系統廠商也可以在標準之外增加新的功能以吸引用戶，標準並不會對創新形成束縛。
榮譽表彰
2010年11月15日，《文檔處理系統》獲得第十二屆中國專利獎優秀獎。
