專利名稱：文檔處理系統(tǒng)和方法
技術(shù)領(lǐng)域：
本發(fā)明涉及一種文檔處理系統(tǒng)和方法。
背景技術(shù)：
信息可大致分為結(jié)構(gòu)化數(shù)據(jù)和非結(jié)構(gòu)化數(shù)據(jù)，其中以書面文檔和流J 某體為 主的非結(jié)構(gòu)化數(shù)據(jù)根據(jù)資料統(tǒng)計占有量超過百分之七十。結(jié)構(gòu)化數(shù)據(jù)的結(jié)構(gòu)比 較簡單，即一個二維表結(jié)構(gòu)，其處理技術(shù)以數(shù)據(jù)為代表，主要是利用數(shù)據(jù)庫系 統(tǒng)進行處理，從上世紀七八十年代開始發(fā)展，到九十年代達到頂峰，研發(fā)和應(yīng) 用已經(jīng)比較成熟。非結(jié)構(gòu)化數(shù)據(jù)則沒有固定數(shù)據(jù)結(jié)構(gòu)，因此對非結(jié)構(gòu)化數(shù)據(jù)的 處理非常的復雜。
目前處理各種非結(jié)構(gòu)化文檔的軟件已經(jīng)比較普及，形成了多種文檔格式林
立的狀況。例如，文檔編輯目前就存在Microsoft的word、 WPS、永中的Office、 Red的Office等。通常， 一個內(nèi)容管理軟件往往要處理二三百種文檔才各式，而 且這些格式還在不斷更新，給這類軟件的開發(fā)帶來了巨大的困難。如何解決文 檔通用性、進行數(shù)字內(nèi)容提取、格式兼容越來越成為人們的關(guān)注點，人們迫切 希望解決以下問題
1) 文檔不通用
基本上，不同用戶只能交換同一種軟件處理的文檔，無法交換不同軟件處 理的文檔，形成^f言息封閉。
2) 訪問接口不統(tǒng)一、數(shù)據(jù)兼容代價太高
不同的文檔處理軟件之間，文件格式互不兼容，在處理過程中要么利用對 方組件解析(前提是對方提供相應(yīng)接口 )，要么自己投入研發(fā)力量從頭到尾的解 析對方的格式。3) 信息安全較差
目前針對書面文檔的權(quán)限控制手段單一，主要是數(shù)據(jù)加密、口令認證。因 為信息泄露，每年造成巨大損失的公司案例層出不窮。
4) 都是針對單個文檔的處理，缺乏多文檔管理手^:: 每個人電腦中都有大量文檔，但多個文檔之間缺乏有效的組織管理，而且
資源共享很難。如，字庫/字體文件、全文數(shù)據(jù);險索等。
5) 頁面分層的技術(shù)不完善
目前一些軟件，如Adobe的photoshop， Microsoft的word，多多少少已經(jīng) 有層的概念，但層的功能還比較單一，管理手段比較簡單，不能滿足應(yīng)用需求。
6) 檢索手段不夠豐富
隨著信息的海量化，用任何一個關(guān)鍵詞來搜索都會得到數(shù)量龐大的檢索結(jié) 果，全文檢索技術(shù)基本解決了查全率的問題，但查準率迅速上升為首要問題。 現(xiàn)有技術(shù)還沒有很充分地利用全部信息來解決查準率問題，例如每個文字的字 體、字號完全可以用來判斷該文字的重要性，但都在^r索時被忽略了。
雖然各大公司目前都努力將自己特有的文檔格式發(fā)展為市場標準，各標準 組織也致力于制訂通用的文檔格式標準。但不管是專有的文檔格式(如.doc) 還是開放的文檔格式(如PDF)，只要是以文檔格式為標準，就不可避免產(chǎn)生以 下問題
a) 重復開發(fā)，效果不統(tǒng)一
使用同一標準的不同軟件都需要自己去解釋、生成該格式的文檔，造成大 量重復開發(fā)，而且會因為各家解釋程序不同，例如有的完善有的相對簡單，有 的支持新版本有的只支持舊版本數(shù)據(jù)，同 一文檔在不同軟件下顯現(xiàn)出不同的版 式，甚至出現(xiàn)解釋錯誤導致無法打開文檔。
b) 阻礙創(chuàng)新
軟件是不斷創(chuàng)新的行業(yè)，但由于每增加一個新功能就需要增加描述該功能 的信息，而且只有等到標準修訂的時候才能增加新的格式，因此把存儲格式固 定死，將會妨礙技術(shù)創(chuàng)新的竟爭。C)影響檢索性能
對海量信息，需要增加大量的檢索信息以提高檢索性能，但固定死的存儲 格式難以增加檢索信息
d)影響可移植性和可伸縮性
在不同的系統(tǒng)環(huán)境下，不同的應(yīng)用需求，可能會有不同的存儲要求。例如， 存儲在硬盤上就需要考慮如何減少磁頭尋道的次數(shù)以提高性能，而在嵌入式應(yīng) 用中數(shù)據(jù)都相當于存儲在內(nèi)存中的，就不存在這個問題。例如，同一個廠商的 數(shù)據(jù)庫軟件在不同平臺上就可能會使用不同的存儲格式。因此，設(shè)置文檔存儲 標準將會影響系統(tǒng)的可移植性和可伸縮性。
現(xiàn)有技術(shù)中最開放、可交換性最好的文檔是Adobe Acrobat的PDF。然而， 雖然PDF已經(jīng)成為全球文檔分發(fā)、交換的事實標準，但也不能實現(xiàn)在不同的軟 件之間交換PDF文檔，也就是說，不能實現(xiàn)PDF文檔的互操作性。而且，無 論是Acrobat還是O伍ce，都只能對單文檔進行處理，缺乏對多文檔的管理功能， 不具備對文檔庫進行操作的功能。
另外，在文檔信息安全的方面，現(xiàn)有技術(shù)也存在較多缺陷。Word和PDF 這些應(yīng)用最廣泛的文檔，都是釆用對數(shù)據(jù)加密或者口令認證等進行數(shù)據(jù)安全控 制，沒有提供系統(tǒng)的身份認證機制，對權(quán)限的控制都是整個文檔范圍的，不能 細化到文檔內(nèi)的任意區(qū)域，無法對任意邏輯數(shù)據(jù)設(shè)定加密和簽名?，F(xiàn)有的內(nèi)容 管理系統(tǒng)雖然能夠提供較好的身份認證機制，但由于與文檔處理系統(tǒng)是分離的， 不僅管理粒度只能做到文檔級，而且無法在文檔使用過程中對文檔實施安全控 制，難以進行必要的安全管理。由此可見，由于現(xiàn)有的安全機制與文檔處理是 分離的模塊，容易出現(xiàn)安全縫隙。

發(fā)明內(nèi)容
本發(fā)明實施例提供了 一種文檔處理的系統(tǒng)和方法，實現(xiàn)對文檔的互操作。
本發(fā)明實施例提供的文檔處理方法，包括
應(yīng)用軟件發(fā)送指令到平臺軟件，以對抽象非結(jié)構(gòu)化信息進行操作；平臺軟件接收到來自所述應(yīng)用軟件的指令，根據(jù)所述指令，對與所述抽象
非結(jié)構(gòu)化信息對應(yīng)的存儲數(shù)據(jù)執(zhí)行所述操作；
其中，所述抽象非結(jié)構(gòu)化信息與所述存儲it據(jù)的存儲方式無關(guān)。
本發(fā)明實施例提供的一種文檔處理系統(tǒng)，包括
應(yīng)用軟件，用于發(fā)送指令到平臺軟件，以對抽象非結(jié)構(gòu)化信息進行揭:作； 平臺軟件，用于接收到來自所述應(yīng)用軟件的指令，根據(jù)所述指令，對與所 述抽象非結(jié)構(gòu)化信息對應(yīng)的存儲數(shù)據(jù)執(zhí)行所述操作；
其中，所述抽象非結(jié)構(gòu)化信息與所述存儲數(shù)據(jù)的存儲方式無關(guān)。
本發(fā)明實施例提供的一種文檔處理方法，包括
第 一應(yīng)用軟件發(fā)送第 一指令到平臺軟件，以創(chuàng)建第 一抽象文檔；
所述平臺軟件接收所述第一指令，創(chuàng)建與所述第一抽象文檔對應(yīng)的存儲數(shù)
據(jù)；
第二應(yīng)用軟件發(fā)送第二指令到所述平臺軟件以打開所述創(chuàng)建的存儲數(shù)據(jù)； 所述平臺軟件接收所述第二指令，打開并解析所述存儲數(shù)據(jù)，生成與所述
存儲數(shù)據(jù)對應(yīng)的第二抽象文檔；
其中，所述第一指令與第二指令符合相同的接口標準。 本發(fā)明實施例提供的一種文檔處理系統(tǒng)，包括 第一應(yīng)用軟件，用于發(fā)送第一指令到平臺軟件，以創(chuàng)建第一抽象文檔； 所述平臺軟件，用于接收所述第一指令，創(chuàng)建與所述第一抽象文檔對應(yīng)的
存儲數(shù)據(jù)；
第二應(yīng)用軟件，用于發(fā)送第二指令到平臺軟件以打開所述創(chuàng)建的存儲數(shù)據(jù)； 所述平臺軟件，進一步用于接收所述第二指令，打開并解析所述存儲數(shù)據(jù)， 生成與所述存儲數(shù)據(jù)對應(yīng)的第二抽象文檔；
其中，所述第一指令與第二指令符合相同的接口標準。 本發(fā)明實施例提供的一種文檔處理方法，包括
第 一平臺軟件解析以第 一數(shù)據(jù)格式存儲的第 一存儲數(shù)據(jù)，生成與所述存儲 數(shù)據(jù)對應(yīng)的第 一抽象文檔；所述應(yīng)用軟件發(fā)送第 一指令到所述第 一平臺軟件，以獲取所述第 一抽象文 檔的所有信息；發(fā)送第二指令到第二平臺軟件，以創(chuàng)建與所述第一抽象文件相
同或相似的第二抽象文檔；
所述第二平臺軟件根據(jù)所述第二指令，創(chuàng)建與所述第二抽象文檔對應(yīng)并按 第二數(shù)據(jù)格式存儲的第二存儲數(shù)據(jù)；
其中，所述第一指令和第二指令符合相同的接口標準。
本發(fā)明實施例提供的一種文檔處理系統(tǒng)，包括
第一平臺軟件，用于解析以第一數(shù)據(jù)格式存儲的第一存儲數(shù)據(jù)，生成與所 述存儲數(shù)據(jù)對應(yīng)的第 一抽象文檔；
所述應(yīng)用軟件，用于發(fā)送第一指令到所述第一平臺軟件，以獲取所述第一 抽象文檔的所有信息；發(fā)送第二指令到第二平臺軟件，以創(chuàng)建與所述第一抽象 文件相同或相似的第二抽象文檔；
所述第二平臺軟件，用于才艮據(jù)所述第二指令，創(chuàng)建與所述第二抽象文檔對 應(yīng)并按第二數(shù)據(jù)格式存儲的第二存儲數(shù)據(jù)；
其中，所述第一指令和第二指令符合相同的接口標準。
利用本發(fā)明實施例提供的方法和系統(tǒng)，應(yīng)用軟件對一個抽象文檔執(zhí)行操作， 因此它無需考慮文檔的數(shù)據(jù)是如何存儲的。平臺軟件維護抽象文檔和存儲數(shù)據(jù) (如具有某種格式的文檔文件)之間的關(guān)系，如平臺軟件將應(yīng)用軟件針對抽象 問的那個的操作映射到對存儲數(shù)據(jù)的實際操作，并對存儲數(shù)據(jù)執(zhí)行此操作。這 樣應(yīng)用軟件和平臺軟件實現(xiàn)了分工，進而實現(xiàn)文檔的互操作。


圖1為依照本發(fā)明的文檔處理系統(tǒng)的結(jié)構(gòu)框圖。 圖2示出了依照本發(fā)明優(yōu)選實施例的通用文檔模型的組織結(jié)構(gòu)。 圖3示出了圖2所示通用文檔^^莫型中文檔庫對象的組織結(jié)構(gòu)。 圖4示出了圖3所示文檔庫對象中文檔庫輔助對象的組織結(jié)構(gòu)。 圖5示出了圖3所示文檔庫對象中文檔集對象的組織結(jié)構(gòu)。圖6示出了圖5所示文檔集對象中文檔對象的組織結(jié)構(gòu)。 圖7示出了圖6所示文檔對象中頁面對象的組織結(jié)構(gòu)。 圖8示出了圖7所示頁面對象中層對象的組織結(jié)構(gòu)。 圖9示出了圖8所示層對象中版面對象的組織結(jié)構(gòu)。 圖10-17為本發(fā)明的實施例中所定義的動作。 圖18為以UOML接口為例的文檔處理系統(tǒng)的處理示意圖。
具體實施例方式
以下結(jié)合附圖及實施例，對本發(fā)明進行進一步詳細說明。應(yīng)當理解，此處 所描述的具體實施例僅僅用于解釋本發(fā)明，并不用于限定本發(fā)明。
如圖l所示，依照本發(fā)明的文檔處理系統(tǒng)主要包括應(yīng)用軟件、接口層、文 檔庫系統(tǒng)和存儲設(shè)備。
其中的應(yīng)用軟件包括現(xiàn)有的任何文檔處理和內(nèi)容管理軟件，這些應(yīng)用軟件 都位于文檔處理系統(tǒng)的應(yīng)用層，通過發(fā)送符合接口標準的指令來對文檔進行操 作，所述操作都是對符合通用文檔模型的文檔進行的，與具體存儲格式無關(guān)。
其中的接口層符合規(guī)范應(yīng)用層和文檔庫系統(tǒng)之間交互的接口標準，所述應(yīng) 用層通過接口層向文檔庫系統(tǒng)發(fā)送標準指令，所述文檔庫系統(tǒng)通過接口層向應(yīng) 用層返回執(zhí)行的結(jié)果。由此可見，由于應(yīng)用軟件均可以通過接口層發(fā)出標準指 令，對符合通用文檔模型的文檔進行操作，所以不同的應(yīng)用軟件可以通過同一 文檔庫系統(tǒng)對同 一文檔進4亍#:作，同 一應(yīng)用庫欠件也可以通過不同文檔庫系統(tǒng)對 不同格式的文檔進行操作。
優(yōu)選地，接口層可包括上接口單元和下接口單元，應(yīng)用層通過上接口單元 發(fā)送標準指令至下接口單元，文檔庫系統(tǒng)通過下接口單元接收標準指令，下接 口單元還用于將文檔庫系統(tǒng)的執(zhí)行結(jié)果通過上接口單元返回給應(yīng)用系統(tǒng)。在實 現(xiàn)上，上接口單元可位于應(yīng)用層中，下接口單元可位于文檔庫系統(tǒng)中。
其中的文檔庫系統(tǒng)為文檔處理系統(tǒng)的核心層，根據(jù)應(yīng)用軟件通過接口層發(fā)
來的標準指令執(zhí)行具體的文檔處理操作。
其中的存儲設(shè)備為文檔處理系統(tǒng)的存儲層，常用的是硬盤或者內(nèi)存，也可以是光盤、閃存、軟盤、磁帶，也可以是遠程的存儲設(shè)備，總之只要具備數(shù)據(jù) 的存儲能力即可。在存儲設(shè)備中存儲有多個文檔，但對應(yīng)用軟件而言并不需要 關(guān)心文檔的具體存儲方式。
由此可見，依照本發(fā)明，使得應(yīng)用層和數(shù)據(jù)處理層真正分離開來，文檔不 再與特定應(yīng)用軟件綁定，應(yīng)用軟件不再直接跟具體的文檔格式打交道，不同的 應(yīng)用軟件可以對符合通用文檔模型的同 一文檔進行編輯，使不同應(yīng)用軟件之間 具有良好的文檔互操作性。
本發(fā)明還公開了一種應(yīng)用軟件，其包括用于發(fā)出標準指令的接口單元，所 述標準指令用于對符合通用文檔才莫型的文檔進行操作。
本發(fā)明還公開了一種文檔庫系統(tǒng)，其包括用于接收標準指令的接口單元； 和，用于根據(jù)該標準指令對符合通用文檔模型的文檔進行操作的處理單元。 本發(fā)明還公開了一種接口層，其包括
上接口單元，用于發(fā)送對符合通用文檔模型的文檔進行操作的標準指令； 下接口單元，用于接收該標準指令。
進一步，上接口單元可以才艮據(jù)應(yīng)用層發(fā)出的指令生成標準指令，下接口單 元判斷接收到的指令是否符合標準，并解析符合標準的指令。
文檔處理系統(tǒng)可以包括應(yīng)用軟件和平臺軟件(如文檔庫系統(tǒng))。應(yīng)用軟件通 過發(fā)送一個或多個指令到平臺軟件來對抽象非結(jié)構(gòu)化信息(abstract unstructured information)進行操作。平臺軟件接收到來自應(yīng)用軟件的指令后，將針對抽象 非結(jié)構(gòu)化信息的操作映射到針對與該非結(jié)構(gòu)化信息對應(yīng)的存儲數(shù)據(jù)的4喿作，并 且對該存儲數(shù)據(jù)執(zhí)行該操作。其中，需要說明的是抽象非結(jié)構(gòu)化信息與存儲 數(shù)據(jù)的存儲方式無關(guān)。
存儲數(shù)據(jù)是指維護或存儲在存儲器(諸如硬盤等非易失性永久存儲器，或 諸如RAM等易失性存儲器)中供長期使用的各種信息，這些信息可由計算裝 置處理。存儲數(shù)據(jù)可以包括一份完整的或綜合的信息，如o伍ce文檔、圖片或 音頻/視頻節(jié)目等。這里"長期"不是指存儲的介質(zhì)，而是指數(shù)據(jù)的形式，表明 數(shù)據(jù)不是動態(tài)存儲(例如運行實例中的一個內(nèi)存指針)的，而是可被其他軟件或另 一個運行實例以后^f吏用的。
存儲數(shù)據(jù)通常包含于一個磁盤文件中，但也可以包含在多個(相關(guān)聯(lián)的) 磁盤文件中或在數(shù)據(jù)庫的多個(相關(guān)聯(lián)的)字段中，或者是在一個獨立的磁盤 分區(qū)的一個區(qū)域中。其中，該磁盤分區(qū)不由操作系統(tǒng)的文件系統(tǒng)管理，而是由 平臺軟件直接管理?？蛇x的，存儲數(shù)據(jù)還可以分布式存儲在不同地理位置的不 同設(shè)備上，也可以具有其他存儲形式。由此可見，存儲數(shù)據(jù)的格式可以包括如 上所述的將信息存儲為物理數(shù)據(jù)的各種形式，而不局限于一個或多個;茲盤文件 的格式。
文檔的存儲數(shù)據(jù)可稱為文檔數(shù)據(jù)，除了包含文檔的可視化信息以外，還可 以包含其它一些信息，例如安全控制信息或編輯過程信息。文檔文件是以磁盤 文件方式存儲的文檔l史據(jù)。
這里"文檔，，通常有兩個含義 一個是指可打印到紙上的信息，如靜態(tài)的 二維信息(static two-dimension information);另 一個則泛指所有可呈現(xiàn)的信息， 包括多維信息或諸如音/視頻等的流媒體信息。本發(fā)明中并不嚴格區(qū)分這兩種用 法。
在本發(fā)明實施例中，應(yīng)用軟件仿佛是對一個抽象文檔進行操作，它并不需 要關(guān)心文檔數(shù)據(jù)的存儲方式。平臺軟件(如文檔庫系統(tǒng))負責維護抽象文檔與 存儲數(shù)據(jù)(如具有特定格式的文檔文件)之間的對應(yīng)關(guān)系，比如將應(yīng)用軟件 對抽象文檔執(zhí)行的操作映射到針對存儲數(shù)據(jù)的實際操作，執(zhí)行此操作，并在操 作需要返回值的情況下，向應(yīng)用軟件返回操作結(jié)果。
在本發(fā)明實施例中，抽象文檔是對文檔數(shù)據(jù)進行抽象的結(jié)果，不同的文檔 數(shù)據(jù)可以對應(yīng)相同的抽象文檔。例如，抽象文檔可以基于文檔的可視化外觀(也 稱為文檔的版式)進行抽象，具有相同可視化外觀的不同文檔數(shù)據(jù)，無論其以 何種方式存卡者，都可以對應(yīng)同一抽象文檔。比如，當一個Word文件;故轉(zhuǎn)成一 個與其具有相同可一見化外)i見的PDF文件后，該Word文件與該PDF文件就是對 應(yīng)同一抽象文檔的不同存儲數(shù)據(jù)。又比如當同一文檔被保存為不同版本的Word 格式文件時，這些不同版本的Word格式文件也是對應(yīng)相同抽象文檔的不同存儲數(shù)據(jù)。
在本發(fā)明實施例中，為了更好地記錄可視化外觀信息，最好能記錄文字、 圖形、圖像等可視內(nèi)容的位置信息，并同時記錄所引用的資源，例如^皮鏈接的 照片和非標準字庫。這樣，就能保證這些可視內(nèi)容不會錯位、并且隨時可用。 版式文檔滿足上述條件，因此常常被用作平臺軟件的存儲數(shù)據(jù)。
由于平臺軟件創(chuàng)建的存儲數(shù)據(jù)可被標準指令訪問，并且可被符合接口標準 的各種應(yīng)用軟件使用，因此平臺軟件創(chuàng)建的存儲數(shù)據(jù)又可稱為通用數(shù)據(jù)。應(yīng)用
軟件不僅可以訪問通用數(shù)據(jù)，還可以定義自己特有的數(shù)據(jù)格式，如O伍ce文檔
格式。應(yīng)用軟件打開并解析具有自己特有格式的文檔后，通過一個或多個標準 指令來請求生成相應(yīng)的抽象文檔，平臺軟件再根據(jù)這些指令創(chuàng)建相應(yīng)的存儲數(shù) 據(jù)。雖然新生成的存儲數(shù)據(jù)(通用數(shù)據(jù))與原始數(shù)據(jù)的格式不同，但其與原始 數(shù)據(jù)對應(yīng)相同的抽象文檔，如其具有與原始數(shù)據(jù)相同或者相似的可視化外觀。 因此，只要一個文檔數(shù)據(jù)(無論其格式如何)對應(yīng)一個抽象文檔，平臺軟件就 可以創(chuàng)建一個與該抽象文檔對應(yīng)的存儲數(shù)據(jù)，任何文檔數(shù)據(jù)都可以被轉(zhuǎn)化為與 其對應(yīng)相同抽象文檔的通用文檔，并可纟皮各種應(yīng)用軟件使用。這樣就實現(xiàn)了在 符合相同接口標準的不同應(yīng)用軟件之間的文檔互操作。
下面以兩個應(yīng)用軟件和一個平臺軟件為例(但不限于此)來說明文檔互操 作過程。第一應(yīng)用軟件發(fā)送第一指令到平臺軟件，以創(chuàng)建第一抽象文檔。平臺 軟件接收到第一指令后，創(chuàng)建與第一抽象文檔對應(yīng)的存儲數(shù)據(jù)。第二應(yīng)用軟件 發(fā)送第二指令到平臺軟件以打開上述已創(chuàng)建的存儲數(shù)據(jù)。平臺軟件根據(jù)第二指 令打開并解析該存儲數(shù)據(jù)，并產(chǎn)生與該存儲數(shù)據(jù)對應(yīng)的第二抽象文檔。這里第 二抽象文檔與第 一抽象文檔相同或相似，并且第 一指令和第二指令符合相同的 接口標準，這樣第二應(yīng)用軟件就可以打開由第 一應(yīng)用軟件創(chuàng)建的文檔。
再以一個應(yīng)用軟件和兩個平臺軟件為例(但不限于此)來說明另一文檔互 操作過程。第一平臺軟件解析以第一數(shù)據(jù)格式存儲的第一存儲數(shù)據(jù)，產(chǎn)生與該 存儲數(shù)據(jù)對應(yīng)的第一抽象文檔。應(yīng)用軟件發(fā)送第一指令到第一平臺軟件，以獲 取第一抽象文檔的所有信息。應(yīng)用軟件發(fā)送第二指令到第二平臺軟件，以創(chuàng)建一個與第 一抽象文件相同或相似的第二抽象文檔。第二平臺軟件根據(jù)第二指令， 創(chuàng)建與第二抽象文檔對應(yīng)的并且按第二數(shù)據(jù)格式存儲的第二存儲數(shù)據(jù)。這里第 一指令和第二指令符合相同的接口標準這樣應(yīng)用軟件可以將數(shù)據(jù)在不同格式間 轉(zhuǎn)化并且保持其抽象特征不變。
多個應(yīng)用軟件與多個平臺軟件情況下的文檔互操作過程可由以上兩個例子 推知。
受到文檔格式和相關(guān)軟件功能等因素的限制，存儲數(shù)據(jù)與抽象文檔的映射 關(guān)系不一定能100%完整準確，往往會存在一定程度上的偏差。例如(但不限于 此)，不管用什么精度的浮點數(shù)還是整型數(shù)來存儲可視內(nèi)容的坐標，都不能避免 出現(xiàn)偏差。又如，缺乏必要色彩管理功能的用于顯示/打印的軟件顯示/打印出來 的顏色和預(yù)定義的顏色可能會有一定偏差。如果這些偏差不是很明顯的話(例
如但不限于此，某個字符的位置偏離了 O.Olmm,或者某個圖像用JPEG進行了 失真壓縮)，這些偏差可以被使用者忽略。使用者所能接受的偏差程度與其實際 需求等因素有關(guān)，例如一個專業(yè)美工對色彩偏差的要求就會比一般人苛刻得多。 由此可見，抽象文檔與相對應(yīng)的存儲凄t據(jù)不一定能絕對一致，與一個抽象可視 化外觀對應(yīng)的多個存儲數(shù)據(jù)，其顯示/打印效果也未必絕對相同。即使用相同的 應(yīng)用軟件來處理同樣的存儲數(shù)據(jù)，其呈現(xiàn)效果也不一定會完全一樣，例如不同 的屏幕分辨率下顯示效果就會有細^t的不同。在本發(fā)明中，"相似"、"一致"被 用來表示可接受的范圍內(nèi)的偏差(即偏差程度不超過預(yù)設(shè)的閾值)。由此可見， 存儲數(shù)據(jù)可以與多個相似的抽象文檔相對應(yīng)或相符合。
平臺軟件可以用多種方式建立抽象文檔與存儲數(shù)據(jù)的對應(yīng)關(guān)系。例如，平 臺軟件可以在打開某個文檔文件、解析該文檔文件的存儲數(shù)據(jù)并形成一個可供 應(yīng)用軟件操作的抽象文檔時，建立此抽象文檔和存儲數(shù)據(jù)的對應(yīng)關(guān)系。又如， 平臺軟件可以在接收到來自應(yīng)用軟件指令以指示創(chuàng)建一個抽象文檔、并創(chuàng)建相 應(yīng)的存儲數(shù)據(jù)時，建立此抽象文檔和存儲數(shù)據(jù)之間的對應(yīng)關(guān)系。在本發(fā)明某些 實施例中，應(yīng)用軟件知道其所操作的抽象文檔所對應(yīng)的存儲數(shù)據(jù)(比如此時 應(yīng)用軟件可以通知平臺軟件該存儲數(shù)據(jù)的地址，或者應(yīng)用軟件可以將文檔數(shù)據(jù)讀到內(nèi)存中，并將內(nèi)存數(shù)據(jù)塊提交給平臺軟件供其處理)。在本發(fā)明另外的實施 例中，應(yīng)用軟件可能對其所操作的抽象文檔所對應(yīng)的存儲數(shù)據(jù)"一無所知"。例 如(但不限于此)，應(yīng)用軟件可以要求平臺軟件在互聯(lián)網(wǎng)上按某個條件搜索，并 打開第一個搜索到的文檔。
一般說來，抽象文檔是不具有存儲的，也就是說其并未存儲在任何存儲介 質(zhì)中。各種用于記錄和描述抽象文檔的信息可以包含在對應(yīng)的存儲數(shù)據(jù)或操作 指令中，但這種信息都不是抽象文檔本身。因此，抽象文檔也可被稱為虛擬文 檔。
在本發(fā)明實施例中，抽象文檔可以具有結(jié)構(gòu)，該結(jié)構(gòu)可以用某種文檔模型 來描述，如以下提到的通用文檔模型。所謂"文檔數(shù)據(jù)符合通用文檔模型"可 以理解為對文檔數(shù)據(jù)進行抽象得到的抽象文檔符合通用文檔模型。由于通用文 檔模型是基于紙張?zhí)匦猿橄蠖鴣?，因此所有可打印到紙上的文檔符合通用文檔
模型，這就是通用文檔模型之所以稱為"通用"的由來。
在本發(fā)明實施例中，除了可視化外觀外，還可以從文檔數(shù)據(jù)中抽取其他各 種信息，如安全控制信息、文檔組織管理信息(例如描述一個文檔屬于哪個文 檔集的信息)、導航導讀等互動信息、元數(shù)據(jù)等非可視信息等各種信息進行抽象， 甚至還可以是多維信息以及如音/視頻信息等的流媒體信息。所有這些被抽取的 信息可以統(tǒng)稱為抽象信息。由于抽象信息本身是沒有存儲的，也可以稱為虛擬"息。
雖然本發(fā)明所舉的實施例大都是針對文檔的可視化外觀信息的，但上述方 法也可用于其他的抽象信息，如安全控制信息、文檔組織管理信息、多維信息、 流媒體信息等。
存在多種方式來發(fā)送指令以操作抽象信息，如通過發(fā)送命令串或調(diào)用函數(shù)。 可以用不同的指令形式來表示對抽象信息進行的操作。之所以將函數(shù)調(diào)用也視 為一種指令發(fā)送形式，是因為可以將不同函數(shù)調(diào)用地址視為不同指令，將函數(shù) 的參數(shù)視為對應(yīng)的指令參數(shù)。當指令以"操作動作+操作對象，，形式描述時，
指令中的對象可以與通用文檔模型中的對象相同，也可以不同。例如，設(shè)置文檔的文字對象的位置時，指令中的對象可以是文字對象，此時此指令中的對象
與通用文檔模型中的對象相同；或者，指令中的對象可以是文字的位置對象， 此時此指令中的對象與通用文檔模型的對象不同。在實際應(yīng)用中，為了方便起 見，還是應(yīng)當盡量將指令中的對象可以與通用文檔模型的對象統(tǒng)一為好。
以上描述的方法將應(yīng)用軟件從平臺軟件中分離處理，使得文檔處理更加便 利。在實際應(yīng)用中，也可能會出現(xiàn)不嚴格區(qū)分抽象信息與存儲數(shù)據(jù)，應(yīng)用軟件 甚至可以通過指令直接操作文檔數(shù)據(jù)的情形。但在這種情況下，為了保持通用 性，指令應(yīng)該與具體的文檔數(shù)據(jù)格式無關(guān)。更具體的，該指令可以符合一個與 文檔數(shù)據(jù)格式無關(guān)的接口標準，并可以通過這個符合該接口標準的接口層發(fā)送 該指令。接口層也可以不是一個單獨的層，而是可以分為上接口單元和下接口 單元兩部分，其中上接口單元為應(yīng)用軟件的一部分，下接口單元為平臺軟件的 一部分。
以下對本發(fā)明的文檔處理系統(tǒng)的具體實施方式
進行闡述。 通用文檔模型
可參考紙張的特性定義所述通用文檔模型，這是因為以紙張作為文檔信息 的記錄手段是通行至今的標準方法，只要能具備紙張的所有功能，就能滿足工 作、生活等實際應(yīng)用的需求。
如果把文檔中的一頁當成一張紙，凡是能畫到紙上的就記錄下來，該通用 文檔模型能夠描述頁面上的所有可見內(nèi)容?，F(xiàn)有技術(shù)中的頁面描述語言(如 PostScript)可以描述所有能印在紙上的信息，因此這一部分就不再詳細闡述。 一般說來，頁面上的可見內(nèi)容最終都可以歸為文字、圖形、圖像三類。
如果文檔中涉及到特定字體或特殊字符的話，為了保證在各臺電腦上都能 有相同的效果，就需要在文檔中嵌入相應(yīng)字庫。為了提高存儲效率，字庫資源 應(yīng)當共享，這樣即使在多處使用了同一字符，也只需要嵌入一個字庫。圖像有 時也是可能在多處出現(xiàn)的，例如每一頁共同的底圖，或經(jīng)常出現(xiàn)的公司標識， 這種情況下最好也能共享這些圖像。
當然，作為更加先進的信息處理工具，不能僅僅模擬紙張的特性，還需要增加一些增強的數(shù)字特性，例如元數(shù)據(jù)、導航、導讀、微縮版面。元數(shù)據(jù)是描 述數(shù)據(jù)的數(shù)據(jù)，例如作者、出版社、出版時間、ISBN號等就是圖書的元數(shù)據(jù)。 元數(shù)據(jù)是業(yè)內(nèi)通用名詞，也不在此贅述。導航是類似圖書目錄的信息，也是業(yè) 內(nèi)通用名詞。導讀信息描述了一篇文章所在的區(qū)域和閱讀順序，這樣當閱讀者 讀完一屏后就可以根據(jù)該信息自動判斷下一屏應(yīng)該顯示什么，這樣還能做到自 動換欄、自動轉(zhuǎn)版，而不用閱讀者再手工指定位置。微縮版面是事先生成的各 頁面的微縮圖，閱讀者可以通過查看微縮版面來指定閱讀哪一頁。
圖2是本發(fā)明的一優(yōu)選實施例的通用文檔模型。如圖2所示，該通用文檔
模型包含文檔倉庫、文檔庫、文檔集、文檔、頁、層、對象組、版面對象等多 個層次。
其中，文檔倉庫由一個或多個文檔庫組成，文檔庫之間的關(guān)系相對于文檔 庫之下的層次之間的關(guān)系相對要松散一些，文檔庫之間可以非常簡單地組合和 拆離，而不用對文檔庫本身的數(shù)據(jù)做改動，該多個文檔庫之間往往沒有建立統(tǒng) 一索引(特別是全文索引)，很多對文檔倉庫的檢索操作一般都需要遍歷各文 檔庫的索引，而沒有統(tǒng)一的索引可用。每個文檔庫由一個或多個文檔集組成， 每個文檔集由一個或多個文檔組成，還可以包含任意數(shù)量的子文檔集。這里所
說的文檔相當于目前普通的一個文檔文件(例如DOC文檔)，通用文檔才莫型 可以規(guī)定一個文檔只能屬于一個文檔集，但也可以允許一個文檔屬于多個文檔 集。文檔庫不是多個文檔的簡單組合，它把多個文檔緊密地組織起來，特別是 為文檔內(nèi)容統(tǒng)一建立了各種檢索索引后就能帶來更大的便利性。
每個文檔由一頁或存在一定順序(如前后順序)的多頁組成，每頁的版心 可以不同，而且版心也不一定是矩形的，可以是任意形狀，可以用一條或多條 封閉曲線表示版心。
每頁又由一層或按一定順序(如上下順序)的多層組成，各層之間如同玻 璃板的疊加關(guān)系。層由任意數(shù)量的版面對象和對象組組成，版面對象是指狀態(tài) (如字體、字號、顏色、ROP等)、文字(包括符號)、圖形(如直線、曲線、 填充了指定顏色的閉合區(qū)域、漸變色等)、圖象(如TIF、 JPEG、 BMP、 JBIG等)、語義信息(如標題開始、標題結(jié)束、換行等)、源文件、腳本、插件、 嵌入式對象、書簽、鏈接、流媒體、二進制數(shù)據(jù)流等。 一個或多個版面對象可 以組成一個對象組。對象組也可以包含任意數(shù)量的子對象組。
文檔庫、文檔集、文檔、頁、層都可以還包括元數(shù)據(jù)(如名稱、最后修改 時間等，其類型可以根據(jù)應(yīng)用需求來設(shè)置)和/或歷史痕跡；文檔中還可以包
括導航信息、導讀信息、微縮版面；也可以把微縮版面放在頁或者層這個層次； 文檔庫、文檔集、文檔、頁、層、對象組都可以還包括數(shù)字簽名；語義信息最 好跟著版面信息走，這樣可以避免數(shù)據(jù)冗余，也比較容易與版面建立對應(yīng)關(guān)系； 文檔庫、文檔還可以包括字庫、圖像等共享資源。
該通用文檔模型還可以定義一個或多個角色，為每個角色分配一定權(quán)限。 權(quán)限以文檔庫、文檔集、文檔、頁、層、對象組、元數(shù)據(jù)為單元進行分配，定 義每個角色對該單元是否可讀、是否可寫、是否可復制、是否可打印，等等。
該通用文檔模型是一個超越以往單個文檔對應(yīng)單個文件的方式，文檔庫中 包含多個文檔集、文檔集中包含多個文檔，而對于文檔庫中文檔內(nèi)容，采用了 細粒度的訪問和安全控制，可以具體訪問文檔庫中某個文字或者矩形，而不像 現(xiàn)在的文檔管理系統(tǒng)只能訪問到文件名。
圖3至圖9示出了本發(fā)明一優(yōu)選實施例的通用文檔模型所涉及的各對象的 組織結(jié)構(gòu)示意圖。所述的各對象的組織結(jié)構(gòu)是樹狀結(jié)構(gòu)，是逐層展開、細化的。
文檔倉庫對象是由一個或多個文檔庫對象組成(圖中未示出)。
如圖3所示，文檔庫對象包括一個或多個文檔集對象、任意數(shù)量文檔庫輔 助對象和任意數(shù)量的文檔庫共享對象。
如圖4所示，所述的文檔庫輔助對象包括元數(shù)據(jù)對象、角色對象、權(quán)限對 象、插件對象、索引信息對象、腳本對象、數(shù)字簽名對象、歷史痕跡對象等。 文檔庫共享對象是指文檔庫中的不同文檔可能共享的對象，如字庫對象、圖像 對象等。
如圖5所示，每個文檔集對象包括一個或多個文檔對象、任意數(shù)量的文檔 集對象和任意數(shù)量的文檔集輔助對象。文檔集輔助對象包括元數(shù)據(jù)對象、數(shù)字簽名對象、歷史痕跡對象。當文檔集對象包括多個文檔集對象時，其類似于資 源管理器中的文件夾包括多個文件夾的形式。
如圖6所示，每個文檔對象包括一個或多個頁面對象、任意數(shù)量的文檔輔 助對象和任意數(shù)量的文檔共享對象。文檔輔助對象包括元數(shù)據(jù)對象、字庫對象、 導航信息對象、導讀信息對象、微縮版面對象、數(shù)字簽名對象、歷史痕跡對象 等。文檔共享對象包括文檔中的不同頁面可能共同使用的對象，如圖^象對象、 印章對象等。
如圖7所示，每個頁面對象包含一個或多個層對象和任意數(shù)量的頁面輔助 對象組成。頁面輔助對象包括元數(shù)據(jù)對象、數(shù)字簽名對象、歷史痕跡對象。
如圖8所示，每個層對象包括一個或多個版面對象、任意數(shù)量的對象組和 任意數(shù)量的層輔助對象。層輔助對象包括元數(shù)據(jù)對象、數(shù)字簽名對象、歷史痕 跡對象。對象組包括任意數(shù)量的版面對象、任意數(shù)量的對象組和可選的數(shù)字簽 名對象。當對象組包括多個對象組時，其類似于資源管理器的文件夾包括多個 文件夾的形式。
如圖9所示，版面對象包括狀態(tài)對象、文字對象、直線對象、曲線對象、 圓弧對象、路徑對象、漸變色對象、圖像對象、流媒體對象、元數(shù)據(jù)對象、批 注對象、語義信息對象、源文件對象、腳本對象、插件對象、二進制^:據(jù)流對 象、書簽對象以及超鏈接對象。
其中，狀態(tài)對象包括任意數(shù)量的字符集對象、字體對象、字號對象、文字 顏色對象，光柵操作對象、背景色對象、線顏色對象、填充色對象、線型對象、 線寬對象、線接頭對象、畫刷對象、陰影對象、陰影顏色對象、旋轉(zhuǎn)對象、空 心字對象、勾邊字對象、透明對象和渲染模式對象。
在具體實施過程中，可以在上述通用文檔^^莫型基礎(chǔ)上進一步增強或簡化。 如果在簡化模型中省略了文檔集對象，則文檔庫對象直接由文檔對象組成；如 果在簡化模型中省略了層對象，則頁面對象直接由版面對象組成。
可以理解，最簡化的通用文檔模型是僅包含文檔對象、頁面對象和版面對 象。其中版面對象僅包括文字對象、直線對象和圖像對象。完整模型和最簡化模型之間的各種中間模型都屬于本優(yōu)選實施例的變形。
通用安全模型
為了滿足各種應(yīng)用對文檔安全性的需求，還需要定義一種通用的文檔安全 ^t型，以解決由于現(xiàn)有軟件的文檔安全功能不夠強，或者是安全管理^4'J與文 檔處理模塊脫節(jié)所導致的安全縫隙。根據(jù)本發(fā)明一優(yōu)選實施例，通用文檔安全 模型包括
1. 在文檔庫中設(shè)置若干角色，角色對象是文檔庫對象的子對象。
2. 可以設(shè)置任意角色對任意對象(例如文檔庫、文檔集、文檔、頁、層、 對象組、版面對象等)的訪問權(quán)限。如果設(shè)置了某角色對某對象的訪問權(quán)限， 則該^L限適用于該對象的所有子對象。
3. 文檔庫系統(tǒng)實現(xiàn)的訪問權(quán)限包括是否可讀、是否可寫、是否可再授權(quán)、 是否可收回授權(quán)及其排列組合。也可以定義其他需要由應(yīng)用軟件來配合實現(xiàn)的 ^J艮，如不可打印。
4. 角色可以對任意對象進行簽名。簽名范圍包括該對象的子對象，以及 引用到的對象。
5. 創(chuàng)建角色對象的指令的執(zhí)行結(jié)果是向應(yīng)用軟件返回一個密鑰，作為應(yīng) 用軟件以該角色身份登錄的依據(jù)，該密鑰通常是PKI的私鑰，由應(yīng)用軟件保管， 該密鑰也可以是登錄口令。
6. 當應(yīng)用軟件以某一角色身份登錄時，通常采用"挑戰(zhàn)-應(yīng)答"機制，即 文檔庫系統(tǒng)用保存的角色公鑰加密一塊隨機數(shù)據(jù)發(fā)給應(yīng)用軟件，應(yīng)用軟件解密 后返回給文檔庫系統(tǒng)，如果解密正確，則表明應(yīng)用軟件確實擁有該角色對應(yīng)的 私鑰。"挑戰(zhàn)-應(yīng)答"機制也可以用以下方式實現(xiàn)，文檔庫系統(tǒng)將一塊隨機數(shù)據(jù) 發(fā)給應(yīng)用軟件，應(yīng)用軟件用私鑰加密后返回給文檔庫系統(tǒng)，文檔庫系統(tǒng)用保存 的角色的公鑰解密，如果解密正確，則表明應(yīng)用軟件確實擁有該角色對應(yīng)的私 鑰。為保險起見，該認證過程可能會重復幾次。采用"挑戰(zhàn)-應(yīng)答"機制可以更 好地保護私鑰的安全性。如果角色的密鑰是登錄口令，則需要用戶輸入正確的 登錄口令。7.應(yīng)用軟件可以同時登錄多個角色，此時擁有的權(quán)限是各角色權(quán)限的并集。
在具體實施過程中，可以在上述通用安全模型基礎(chǔ)上進一步增強或筒化。 針對上述安全模型的任何簡化模型都是本實施例的變形。 接口層的具體實現(xiàn)
所述接口層的統(tǒng)一接口標準可根據(jù)通用文檔模型、通用安全模型和常用的 文檔操作而定義，用于發(fā)送對通用文檔模型中各對象進行操作的指令。所述的 對通用文檔模型中各對象進行操作的指令符合接口標準，各種應(yīng)用軟件可以通 過接口層發(fā)出標準指令。
現(xiàn)在介紹接口標準的實現(xiàn)方式。接口標準的實現(xiàn)可以是上接口單元按照預(yù)
先定義的標準才各式生成命令串，例如"<UOML_INSERT (OBJ=PAGE, PARENT=123.456.789, POS=3)/>，，，將該命令串發(fā)送給下接口單元，并從下接 口單元接收文檔庫系統(tǒng)對該命令的執(zhí)行結(jié)果或其它反饋信息；或者，接口標準 的實現(xiàn)是下接口單元提供一些具有標準名稱和參數(shù)的接口函數(shù)，例如"BOOL UOI—InsertPage (UOI—Doc *pDoc, int nPage)，，，上接口單元調(diào)用這些標準函數(shù)， 調(diào)用操作本身就代表上接口單元發(fā)出了標準指令；或者是上述方法的組合。
接口標準釆用"操作動作+操作對象"的方式來實現(xiàn)便于學習和理解，也便于 保持接口標準的穩(wěn)定性。例如，對20種不同對象進行10種操作，可以定義 20x10=200種指令，也可以定義20種對象和10種動作，但顯然后一種方式大 大減輕了記憶的負擔，而且今后在對接口標準進行擴充時，增加一個對象或動 作也很簡單。所述操作對象為通用文檔模型所包含的對象。
例如，定義以下7種操作動作
打開用于創(chuàng)建或打開文檔庫；
關(guān)閉用于關(guān)閉會話句柄、關(guān)閉文檔庫；
獲取用于獲取對象列表、對象相關(guān)屬性和數(shù)據(jù)；
設(shè)置用于設(shè)置/修改對象數(shù)據(jù)；
插入插入指定對象或數(shù)據(jù)；刪除用于刪除對象的某個子對象；
檢索查詢用于根據(jù)定義條件在文檔中找到符合條件的內(nèi)容，這些條件既 可以是準確的信息，也可以是不準確的信息，即模糊查找。
定義如下對象文檔庫、文檔集、文檔、頁、層、對象組、文字、圖像、 圖形、路徑(由一組順序圖形連接組成，可以是閉合也可以不閉合的)、源文 件、腳本、插件、音頻、視頻、角色等。
對象還包括下列狀態(tài)對象背景色、線的顏色、填充色、線型、線寬、ROP、 畫刷、陰影、陰影顏色、字符高、字符寬、旋轉(zhuǎn)、透明、渲染模式等。
可以理解，在采用"操作動作+操作對象"方式實現(xiàn)接口標準時，不能自動理 解為每一個對象和每一個動作的所有組合都一定能構(gòu)成有實際意義的操作指 令， 一些組合是沒有意義的。
還可以用非"操作動作+操作對象"的函數(shù)方式來定義接口標準，例如對每 一個對象的每一種操作都定義一個接口函數(shù)，這樣各種操作指令就是上接口單 元以調(diào)用下接口單元的接口函數(shù)來發(fā)送給文檔庫系統(tǒng)。
還可以封裝各個對象類，如文檔庫類，把該對象可以進行的操作定義成該 類的方法。
特別地，如果在接口標準中定義了獲取版面位圖的指令，將對保障版面一 致性和文檔互操作性起到非常關(guān)鍵的作用。
在檢索查詢指令中，除了常規(guī)的關(guān)鍵詞檢索外，還可以提供更加豐富的檢 索手段。在常規(guī)的搜索技術(shù)中，搜索是和文檔處理分離的，搜索程序只能從文 檔中提取純文本信息，而無法獲取更多信息，只能基于文本信息檢索。但在本 發(fā)明中，檢索查詢功能是集成在文檔處理的核心層，即文檔庫系統(tǒng)，這樣就可 以更充分地利用文檔中蘊含的信息來提供更為強大的4全索手段，如
1. 基于字體信息的檢索，如檢索黑體字的"書生"，Times New Roman字體 的"S薦n"
2. 基于字號信息的檢索，如檢索三號字的"書生"，20磅以上的"Sursen", 長字(即字高超過字寬)的"文檔庫，，3. 基于顏色的才全索，如才全索紅色的"書生"，藍色的"Sursen"
4. 基于版面位置的檢索，如檢索位于頁面上半部分的"書生"，位于頁腳的 "Su羅，，
5. 基于特殊修飾效果的檢索，如檢索斜體字的"書生"，順時針旋轉(zhuǎn)30度 至90度之間的"Sursen",空心字的"SEP",勾邊字的"文檔庫"
6. 根據(jù)類似的思路，還可以進一步提供其它類型的檢索，如檢索反白(黑 底白字)的"書生"，壓圖的"Sursen，，等
7. 可以檢索多個版面對象的組合，如"書生"距離"Sursen"不超過5厘米
8. 上述檢索條件的任意組合
以下是用"操作動作+操作對象"的方式實現(xiàn)接口標準的 一 個實施例，在該 實施例中，接口稱為非結(jié)構(gòu)操作標記語言(UOML),是用可擴展標記語言 (XML)描述的一系列的命令。每個動作都對應(yīng)一個XML元素，每個對象 也都對應(yīng)一個XML元素；描述一個命令時，將描述對象的XML元素作為 描述動作的XML元素的子元素，即可生成包括動作+對象的字符串。上接 口單元將該字符串發(fā)送給下接口單元，就將相應(yīng)的操作指令發(fā)送給了文檔庫 系統(tǒng)。文檔庫系統(tǒng)執(zhí)行這些命令后，下接口單元將執(zhí)行結(jié)果也生成一個符合 UOML格式的字符串，返回給上接口單元，使應(yīng)用軟件能夠知曉操作執(zhí)行結(jié) 果。
所有執(zhí)行結(jié)果都由UOML—RET表示，參見圖10,其定義如下 屬性
SUCCESS:值為真(true)時表明操作成功，否則失敗。 子元素
ERR_INFO:可選，僅當操作失敗時出現(xiàn)，描述了相應(yīng)的錯誤信息。 其它子元素根據(jù)具體命令確定，可參考各命令說明。 UOML動作包括
1 UOML—OPEN創(chuàng)建或打開文檔庫，參見圖11。 1.1屬性1.1.1 create:為true時是創(chuàng)建，否則是打開已有文檔庫。 1.2子元素
1.2.1 path:文檔庫路徑。可以是磁盤文件名，也可以是URL,或者是內(nèi)存 指針，或者是網(wǎng)絡(luò)路徑，或者是文檔庫的邏輯名稱，或者其它能夠指定文檔庫 的表示方法?？梢杂貌煌卣鞯淖址畢^(qū)分上述各種情況，即不用改變命令格 式，只要給字符串設(shè)置不同特征，就可以用不同的方法指定文檔庫。例如，磁 盤文件名采用設(shè)備名稱(如盤符)和":"開頭(如"C:"、 "D:"),而且緊跟著":" 不會是"〃"，也不會是又一個":"；URL采用協(xié)議名稱和":〃"開頭(如"http:〃")； 內(nèi)存指針用"MEM::"開頭，后面是指針的字符串表示方式，例如 "MEM::1234:5678，，；網(wǎng)絡(luò)路徑是"W，，開頭，后面是服務(wù)器名，以及服務(wù)器上的路 徑，如"\\server\abc\def.sep"; 文檔庫的邏輯名稱可以用"*，，開頭，如 "*MyDocBasel"。在下接口單元解析時，如果第一個字母是"*"就表明該字符串 代表文檔庫的邏輯名稱；否則如果頭兩個字母是"W"就表明該字符串代表網(wǎng)絡(luò)路 徑；否則如果頭五個字母是"MEM::"就表明該字符串代表內(nèi)存指針；否則尋找 字符串的第一個":"，如果該":，，后面是"〃"該就表明字符串代表URL,否則就代 表本地設(shè)備上的文件。對于打開服務(wù)器上的文檔庫的情形，可以設(shè)立一個專門 的URL協(xié)議來區(qū)分，例如用"Docbase:〃myserver/mydoc2"指明打開服務(wù)器 myserver上運行的文檔庫系統(tǒng)服務(wù)器系統(tǒng)所管理的mydoc2文檔庫。 總之，只要能給字符串設(shè)置不同特征，就可以用不同的方式來指定文檔庫。根 據(jù)上述說明，還可以定義各種不同的字符串特征；該方式不僅能應(yīng)用于指定文 檔庫路徑，還能應(yīng)用于其它場合，特別是用來指定特定資源位置的應(yīng)用場合。 在很多情況下，希望能夠用一種新方式來指定相關(guān)資源，但又不能或不希望改 變現(xiàn)有的協(xié)議或函數(shù)，這時就可以通過在字符串中設(shè)置不同特征的方式來指定， 這種方法具有最好的通用性，這是因為，無論何種協(xié)議或函數(shù)，只要支持磁盤 文件名或URL,就支持字符串。
1.3返回值
如果成功，則在UOML—RET中包含一個"handle"子元素，記錄句柄2關(guān)閉(UOML—CLOSE),參見圖12。 2.1屬性無。 2.2子元素
2.2.1 handle:對象句柄，是一個字符串表示的對象的引用指針。
2.2.2 db—handle:文檔庫句柄，字符串表示的文檔庫的引用指針。 2.3返回值無返回值。
3 UOML—GET獲取，參見圖13。 3.1屬性
3.1.1 usage:用途，為"GetHandle"(獲取指定對象句柄)、"GetObj"(獲 取指定對象數(shù)據(jù))、"GetPageBmp"(獲取版面位圖)中的一個。 3.2子元素
3.2.1 parent:父對象句柄，usage屬性為"GetHandle"時使用。
3.2.2 pos:位置順序號，usage屬性為"GetHandle"時使用。
3.2.3 handle:指定對象的句柄，當usage屬性為"GetObj"時使用。
3.2.4 page:需要顯示的頁面的句柄，當usage屬性為"GetPageBmp"時使用。
3.2.5 input:描述了對輸入頁面的約束，其中可以指定顯示一層或者多層 的內(nèi)容(可以顯示的層一定是當前角色有權(quán)限訪問的層)；也可以通過指定Clip 區(qū)域來指定顯示區(qū)域的大小。當usage屬性為"GetPageBmp"時使用。
3.2.6 output:描述了版面位圖的輸出方式.，當usage屬性為"GetPageBmp" 時使用。
3.3返回值
3.3.1 當usage屬性為"GetHandle"時，執(zhí)行成功時在UOML—RET中包含 一個"handle"子元素，記錄parent下第pos個子對象的句柄。
3.3.2 當usage屬性為"GetObj"時，執(zhí)行成功時在UOML—RET中包含一個 "xobj"子元素，含有handle對象的數(shù)據(jù)的xml表示。
3.3.3 當usage屬性為"GetPageBmp"時，執(zhí)行成功時在output指定位置輸出版面位圖。
4 UOML—SET設(shè)置，參見圖14。 4.1屬性無。
4.2子元素
4.2.1 Handle:設(shè)置對象的句柄。
4.2.2 xobj:對象的描述。 4.3返回值無返回值。
5 UOML—INSERT插入，參見圖15 5.1屬性無。
5.2子元素
5.2.1 parent:父對象句柄。
5.2.2 xobj:對象的描述。
5.2.3 pos:插入位置。
5.3返回值如果執(zhí)行成功，則將xobj參數(shù)表示的對象，插入到parent中 成為其第pos個子對象，并在UOML—RET中包含一個"handle"子元素，表示新 插入對象的句柄。
6 UOML—DELETE 刪除，參見圖16 6.1屬性無。
6.2子元素
6.2.1 handle:需要刪除的對象的句柄。 6.3返回值無返回值。
7 UOML—QUERY檢索查詢，參見圖17 7.1屬性無。
7.2子元素
7.2.1 handle:需要查詢的文檔庫句柄。
7.2.2 condition:查詢條件。
7.3返回值如果成功，在UOML—RET中包含一個"handle，，子元素代表查詢結(jié)果的句柄， 一個"number"子元素代表查詢結(jié)果的數(shù)量，可以用UOML—GET 來獲取每一個查詢結(jié)果。 UOML對象包括
文檔庫(UOMLDOCBASE)、 文檔集(UOML_DOCSET)、 文檔 (UOML一DOC)、 頁(UOML—PAGE)、 層(UOML—LAYER)、 對象組 (UOMLOBJGROUP)、文字(UOMLTEXT)、圖像(UOMLIMAGE)、直線 (UOML—LINE)、 曲線(UOML—BEIZER)、 圓弧(UOML—ARC)、 路徑 (UOML—PATH )、源文件(UOMLSRCFILE)、背景色(UOML—BACKCOLOR)、 前景顏色(UOMLCOLOR)、 ROP(UOML—ROP)、字符尺寸(UOML—CHARSIZE)、 字體(UOML—TYPEFACE)。
下文以UOML—DOC、 UOML—TEXT和UOML—CHARSIZE為例i兌明其定 義方式
1 UOML—DOC 1.1屬性無。 1.2子元素
1.2.1 metadata:元凄t據(jù)。
1.2.2 pageset:各頁面。
1.2.3 fontinfo:嵌入字庫。
1.2.4 navigation:導航信息。
1.2.5 thread:導讀信息。
1.2.6 minipage:孩i縮片反面。
1.2.7 signiture:數(shù)字簽名。
1.2.8 sharesource:共享資源。
2 UOML—TEXT 2.1屬性
2.1.1 Encoding: 文字編碼方式。 2.2子元素2.2.1 TextData: 文字內(nèi)容。
2.2.2 CharSpacingList:對非等間距文字的字間距列表。
2.2.3 StartPos:起點位置。 3 UOML—CHARSIZE
3.1屬性
3丄1 width:字符寬度。 3丄2 height:字符高度。 3.2子元素無。
以此類推，可以用同樣的方法來描述所有的UOML對象。當應(yīng)用軟件對文 檔庫進行操作時，由上述UOML動作與UOML對象依照XML語法生成相應(yīng) 的UOML命令，將該UOML命令發(fā)給文檔庫系統(tǒng)，即代表向文檔庫系統(tǒng)發(fā)出 了相應(yīng)操作指令。
例如，對創(chuàng)建文檔庫操作,可以用以下命令來完成
<UOML—OPEN create="true">
<path val="f:\\data\\docbasel .sep'V〉
</UOML—OPEN〉
對創(chuàng)建文檔集操作，可以用以下命令來完成 <UOML—INSERT >
<parent val= "123.456.7897〉
<pos val="17>
<xobj>
<docset/> </xobj>
</UOML—INSERT>
需要說明的是，雖然UOML是用XML定義的，但為了顯得更加簡潔，在 前面省略了類似"< xml version=" 1.0" encoding="UTF-8" >，，以及"xmlns:xsi: "http:〃www.w3.org/2001/XMLSchema-instance""之類的常規(guī)XML格式，只要是 熟悉XML語法的實施者都可以在實施過程中自行添加。也可以不用XML方式定義命令串，例如改用類似PostScript那樣的方式， 這才羊上例變成
1, "f:WdataWdocbasel.sep", /Open /docset, 1, "123.456.789" ， /Insert
根據(jù)同樣的思路，還可以定義出其它類型的命令串格式，甚至還可以不用 文本方式，而用二進制方式來定義命令串。
現(xiàn)在介紹對每一個對象的每一個操作都用一個命令來表示的方式的一個具 體實例，在本實例中，用"UOML—INSERT—DOCSET"來表示插入一個文檔集， 用"UOML—INSERT—PAGE"來表示插入一頁，以這樣的方式來定義每個命令 UOML—INSERT—DOCSET在文檔庫中創(chuàng)建一個文檔集 屬性無 子元素
parent: 文檔庫句柄 pos:插入位置
返回值如果執(zhí)行成功，則在UOML一RET中包含一個"handle"子元
素，表示新插入文檔集的句柄 這才羊上例就變?yōu)?<UOML—INSERT—DOCSET >
〈parent val="123.456.7897>
<pos val=T/> </UOML—INSERT—DOCSET >
用這種方法定義命令格式需要對每個對象的每種合法操作都單獨定義一條 命令，缺點是比較繁瑣。
現(xiàn)在介紹用函數(shù)調(diào)用的方式來實現(xiàn)接口標準的實例，在該實例中，通過上 接口調(diào)用下接口的接口函數(shù)的方式來發(fā)送操作指令給文檔庫系統(tǒng)。以下以C++ 語言為例說明，該實例稱為UOI。在該實例中，定義了 UOI一Object作為所有對 象的基類，為每個動作定義了一個函數(shù)，該函數(shù)的參數(shù)可以是對基類的指針或引用，這樣該函數(shù)就可適用于所有對象。
先定義一個UOI返回值結(jié)構(gòu) struct UOI—Ret {
BOOL m—bSuccess;
CString m—Errlnfo;
};
定義所有UOI對象的基礎(chǔ)類
class UOI—Object {
public:
enum Type {
TYPE—DOCBASE，
TYPE—DOCSET，
TYPE—DOC, TYPE—PAGE, TYPE—LAYER, TYPE—TEXT, TYPE—CHARSIZE,
Type m—Type;
UOI_Object(); virtual UOI—Object(); static UOI—Object Create(Type objType);
};
然后定義如下幾個uoi函數(shù)，與"操作動作+操作對象，，方式實例中的幾個
UOML動作相對應(yīng)
UOI—RET UOI—Open(char *path， BOOL bCreate, HANDLE *pHandle); UOI—RET UOI—GloseCHANDLE handle, HANDLE db—handle);UOI—RET UOI—GetHandle(HANDLE hParent， int nPos, HANDLE *pHandle); UOI—RET UOI—GetObjType(HANDLE handle, UOI—Object ::Type *pType); UOI—RET UOI—GetObj(HANDLE handle, UOI—Object *pObj); UOI—RET UOI—GetPageBmp(HANDLE hPage， RECT rect, void *pBuf); UOI—RET UOI—SetObj(HANDLE handle, UOI—Object *pObj); UOI—RET UOI—Insert(HANDLE hParent, int nPos， UOI—Object *pObj, HANDLE *pHandle = NULL);
UOI—RET UOI—Delete(HANDLE handle);
UOI—RET UOI—Query(HANDLE hDocbase， const char *strCondition, HANDLE承phResult);
然后定義各UOI對象，依然以U01—Doc、 UOI—Text和UOML—CharSize為
例i兌明
class UOI一Doc : public UOI一Object { public:
UOI—MetaData m一MetaData;
int m—nPages;
UOI—Page **m_pPages;
int m一nFonts;
UOI—Font **m_pFonts; UOI—Navigation m—Navigation ;
UOI—Thread m—Thread ;
UOI一MiniPage *ip_pMiniPages;
UOI—Signature m—Signature ;
int m—nShared j
UOI—Obj *m_pShared;
UOI—Doc();
virtual UOI一Doc();
};class UOI—Text: public UOI—Object {
public:
enum Encoding { ENCODE—ASCII, ENCODE一GB 13000, ENCODE—UNICODE,
Encoding m一Encoding;
char *m_pText;
Point m一Start;
int *m—CharSpace ;
UOI一Text();
virtual UOI—Text();
};
class UOI一CharSize : public UOI一Object { public :
int m—Width ;
int m一Height j
UOI—CharSize(); virtual ~UOI—GharSize();
};
以下說明UOI的使用方法。首先是創(chuàng)建文檔庫操作
ret = UOI—Open("f:WdataWdocbasel.sep", TRUE, &hDocBase);
然后是構(gòu)建一個創(chuàng)建新對象的函數(shù)
HANDLE InsertNewObj (HANDLE hParent, int nPos， UOI一Object ::Type type) {
UOI—Ret ret;HADNLEhandle ;
UOI—Obj *pNewObj = UOI—Obj::Create(type); if(pNewObj==NULL)
return NUIX; ret = UOI—Insert(hParent, nPos, pNewObj， &handle); delete pNewObj;
return ret.m_b Success handle : NULL;
然后是直接獲取對象的函數(shù) UOI—Obj *GetObj(HANDLE handle)
UOI—Ret ret;
UOI一Object ::Type type; UOI—Obj *pObj;
ret = UOI—GetObjType(handle, &type); if ( !ret. m一bSuccess )
return NULL; pObj = UOI一Obj::Create(type); if(pObj==NULL)
return NULL; ret = UOI—GetObj(handle, pObj); if ( !ret. m—bSuccess ) {
delete pObj;
return NULL;
return pObj;
在對每一個對象的每一種操作都定義一個接口函數(shù)的方式中，插入文檔集 的操作指令就是上接口以下列方式調(diào)用下接口的接口函數(shù)來發(fā)送給文檔庫系統(tǒng)UOI—InsertDocset(pDocbase, 0);
在封裝各個對象類(如文檔庫類)的方式中，把該對象可以進行的操作定 義成該類的方法，^:
class UOI—DocBase : public UOI—Obj
public:
/承！
* \brief 創(chuàng)建文檔庫
* \param szPath: 文檔庫全路徑
* \param bOverride:是否覆蓋原文件
* Veturn UOI—DocBase對象
承/
BOOL Create(const char *szPath, bool bOverride = false);
* \brief 打開文檔庫
* \param szPath:文檔庫全-各徑
* \retum UOI—DocBase對象
承/
BOOL Open(const char承szPath);
* \brief 關(guān)閉文檔庫
* \pamm 無
* \return 無
void Close();
/"
* \brief 獲取角色列表* \param 無
* \retum UOI—RoleList對象
* \sa UOI—RoleList
承/
UOI—RoleList GetRoleList();
/承1
* \brief 存儲文檔庫
* \param szPath:存儲文檔庫全路徑
* \return 無
承/
void Save(char *szPath = 0);
* \brief 插入文檔集
* \param nPos:插入文檔集的位置
* \retum UOI—DocSet對象
* \sa UOI—DocSet
氺/
UOI—DocSet InsertDocSet(int nPos);
* \brief 獲取指定索引的文檔集
* \param nindex:文檔列表的索引號
* \return UOI—DocSet對象
* \sa UOI—DocSet
承/
UOI—DocSet GetDocSet(int nindex); /承1
* \brief 獲取文檔集的總數(shù)* \param 無
* \retum 文檔集個凄史 */
int GetDocSetCount(); /*!
* \brief 設(shè)置文檔庫的名稱
* \param nLen: 文檔庫名稱長度
* \param szName: 文檔庫名稱
* \return 無
*/
void SetName(int nLen， const char* szName); /*!
* \brief 獲取文檔庫名稱長度
* \param 無
* Veturn 長度
*/
int GetNameLen(); /*!
* \brief 獲取文檔庫名稱
* \param 無
* \retum 文檔庫名稱 */
const char* GetName();
* \brief 獲取文檔庫id長度
* \param 無
* \return 長度
*/int GetIDLen();
/承！
* \brief 獲取文檔庫id
* \param 無
* \return id
承/
const char* GetID();
//!構(gòu)造函數(shù)
UOI—DocBase();
〃！析構(gòu)函數(shù)
virtual UOI—DocBase();
};
這樣插入文檔集的操作指令就是上接口以下列方式調(diào)用下接口的接口函數(shù)
來發(fā)送給文檔庫系統(tǒng)的
pDocBase.InsertDocset(O);
還可以用同樣的方法為Java、 C#、 VB、 Delphi等各種編程語言開發(fā)的應(yīng)用 軟件設(shè)計各種不同的接口標準。
只要在接口標準中不含有與特定的操作系統(tǒng)(如WINDOWS, UNIX/LINUX、 MACOS、 SYMBIAN)或特定的硬件平臺(如x86CPU、 MIPS、 POWER PC等)相關(guān)連的特征，該接口標準就可以具有跨平臺性，使得不同平 臺上運行的應(yīng)用軟件和文檔庫系統(tǒng)都可以統(tǒng)一使用同樣的接口標準，特別是可 以讓一個平臺上運行的應(yīng)用軟件可以調(diào)用另 一個平臺上運行的文檔庫系統(tǒng)來才丸 行相應(yīng)操作。例如，應(yīng)用軟件部署在客戶端，使用的是PC機，Windows操作 系統(tǒng)，文檔庫系統(tǒng)部署在服務(wù)器端，使用的是大型機，Linux操作系統(tǒng)，但應(yīng) 用軟件依然可以像調(diào)用本地文檔庫系統(tǒng)一樣調(diào)用服務(wù)器上的文檔庫系統(tǒng)來執(zhí)行 相應(yīng)文檔操作。
如果在接口標準中不含有與特定編程語言相關(guān)的特征，則該接口標準還 能做到與編程語言無關(guān)?？梢钥闯?，用命令串的方式容易構(gòu)造與平臺無關(guān)、與編程語言無關(guān)的接口標準，更具有通用性。特別是用XML來構(gòu)造命令串 的話，由于目前在各種不同平臺、不同編程語言都存在易于獲得的XML生 成解析工具，因此不僅該接口標準具有很好的跨平臺性和與編程語言無關(guān) 性，也非常便于工程師開發(fā)上接口單元和下接口單元。
以上列舉了多種接口標準的實現(xiàn)方法，按照類似的思路設(shè)計的更多種類的 接口標準也包含在本發(fā)明的保護范圍之內(nèi)。
應(yīng)該理解，可以在上述實例的基礎(chǔ)上按同樣的思路增加操作指令，也可以 筒化操作指令，特別是文檔模型被簡化時操作指令也會相應(yīng)被簡化。最簡化情 況下只有文檔的創(chuàng)建、頁面的創(chuàng)建、各版面對象的創(chuàng)建這幾個操作指令。
文檔操作處理
現(xiàn)在，參見圖1,繼續(xù)描述依照本發(fā)明一優(yōu)選實施例的文檔處理系統(tǒng)的工 作過程。
應(yīng)用軟件是包含符合接口標準的上接口單元的軟件，例如Office軟件、內(nèi) 容管理、資源采集等。任一應(yīng)用軟件在需要對文檔進行操作時，依照前述方法 將指令傳遞給文檔庫系統(tǒng)，文檔庫系統(tǒng)根據(jù)指令來完成具體操作過程。
文檔庫系統(tǒng)可以自由地存儲、組織文檔庫數(shù)據(jù)，例如可以把一個文檔庫的 文件全部都存儲在一個磁盤文件中；可以一個文檔對應(yīng)一個磁盤文件，利用操 作系統(tǒng)中的文件系統(tǒng)功能實現(xiàn)多文檔組織；也可以一頁對應(yīng)一個^茲盤文件；還 可以完全拋開梯:作系統(tǒng)，在^f茲盤上留出一塊空間后直接對^磁道、扇區(qū)進行管理。 對文檔庫數(shù)據(jù)的存儲格式，可以用二進制格式保存，可以用XML,還可以用二 進制XML。頁面描述語言(定義頁面上的文字、圖形、圖像等對象的方法)可 以采用PostScript,可以采用PDF、 SPD (書生公司使用的頁面描述語言)，當 然也可以采用自定義的任何頁面描述語言，只要其符合統(tǒng)一的接口標準。
例如，可以用XML來描述文檔庫數(shù)據(jù)，當文檔模型是層次型的時候，可 以完全對照建立相應(yīng)的XML樹。執(zhí)行創(chuàng)建操作時就在XML樹中增加一個結(jié)點， 執(zhí)行刪除操作就刪掉相應(yīng)結(jié)點，執(zhí)行設(shè)置操作就設(shè)置相應(yīng)結(jié)點的屬性，執(zhí)行獲 取操作就取出相應(yīng)結(jié)點的屬性并返回給應(yīng)用軟件，執(zhí)行查詢操作時就遍歷相關(guān)結(jié)點查找。
以下是該實施例的進一步說明
1. 用XML來描述每個對象。也就是說，為每個對象都建立了一個對應(yīng)的 XML樹。有的對象屬性比較簡單，其對應(yīng)的XML樹就只有根結(jié)點，有的對象 比較復雜，其對應(yīng)的XML樹還有子結(jié)點。具體描述方法可以參見前面用XML 來定義操:作對象的說明。
2. 當新建一個文檔庫時就新建一個根結(jié)點為文檔庫對象的XML文件。
3. 每當在文檔庫中插入一個對象時，如文字對象，就將該對象對應(yīng)的XML 樹插入到插入位置的父結(jié)點(如層)之下。這樣，文檔庫中的每個對象都在文 檔庫為根結(jié)點的XML樹中有一個對應(yīng)的結(jié)點。
4. 當刪除一個對象時，就刪除該對象對應(yīng)的結(jié)點，其下屬所有子結(jié)點也都 被刪除。刪除過程是從葉子結(jié)點開始自下而上遍歷的。
5. 設(shè)置一個對象屬性時，將該對象對應(yīng)的結(jié)點的屬性設(shè)置成該屬性。如果 該屬性是用子結(jié)點表示的，則設(shè)置對應(yīng)的子結(jié)點。
6. 獲取一個對象屬性時，訪問該對象對應(yīng)的結(jié)點，根據(jù)該結(jié)點的屬性和子 結(jié)點獲得該對象的屬性。
7. 獲取一個對象的句柄時，返回該對象對應(yīng)結(jié)點的XML路徑。
8. 復制一個對象(如頁面)到指定位置時，就將該對象對應(yīng)的結(jié)點開始的 整個子樹都復制到目標位置對應(yīng)的父結(jié)點(如文檔)之下。如果是復制到另一 個文檔庫中，則需要將該子樹引用的對象(如嵌入字庫)也一起復制過去。
9. 執(zhí)行獲取版面信息指令時，先生成一個指定位圖格式的空白位圖，其尺 寸和指定區(qū)域相同，然后遍歷指定頁面的所有版面對象，凡是位于指定區(qū)域內(nèi)
(包括只有一部分在該區(qū)域內(nèi))的版面對象，都解釋其含義，并在版面上相應(yīng) 體現(xiàn)。具體過程雖然比較復雜比較專業(yè)，但均屬于現(xiàn)有RIP技術(shù)范疇，不在此贅述。
文檔安全處理
在創(chuàng)建角色對象時，生成一對隨機7>私鑰對(例如512位的RSA密鑰)，將公鑰存儲在角色對象中，將私鑰返回給應(yīng)用軟件。
當應(yīng)用軟件登錄時，隨機生成一塊(例如128字節(jié))數(shù)據(jù)，用相應(yīng)角色對 象中的公鑰加密該數(shù)據(jù)發(fā)給應(yīng)用軟件，應(yīng)用軟件解密后比較驗證，如果正確則 表明應(yīng)用軟件確實擁有該角色對應(yīng)的私鑰，登錄成功。為保險起見，該認證過 程可以重復三次，三次全部通過才算登錄成功。
當對某一對象進行簽名時，也就是對其對應(yīng)的結(jié)點開始的子樹進行簽名。 為了能夠使簽名不受具體物理存儲方式的影響，需要先做一個正則化，使得邏 輯上等效的變化(例如存儲位置的改變導致相應(yīng)指針的變化)不會影響簽名有
歲支性。該正則4b的方法如下
按深度優(yōu)先遍歷以目標對象為根節(jié)點的子樹中的各個節(jié)點(即目標對象及 其各個子對象)，按照遍歷順序依次計算每個節(jié)點的正則結(jié)果并連接起來。
其中，對子樹的某一節(jié)點計算正則結(jié)果的方法為先計算該節(jié)點的子節(jié)點 數(shù)的HASH值，然后再依次計算該節(jié)點類型及其各個屬性的HASH值并按順序 連接在該節(jié)點的子節(jié)點數(shù)的HASH值的后面，再計算該連接結(jié)果的HASH值， 得到該節(jié)點的正則結(jié)果。如果需要對子樹中的某個節(jié)點引用的對象也一起做簽 名，則可以將該節(jié)點引用的對象也作為該節(jié)點的一個子節(jié)點來處理，方法同上。
這里不再贅述。
在上述正則化過程中，可以把計算一個節(jié)點正則結(jié)果的方法改成如下方案 將該節(jié)點的子節(jié)點數(shù)、類型及其各屬性用分隔符隔開后按照順序連接起來，計 算該連接的結(jié)果的HASH值，得到該節(jié)點的正則結(jié)果。還可以把計算一個節(jié)點 正則結(jié)果的方法改成如下方案將該節(jié)點的子節(jié)點數(shù)、類型及其各屬性的長度 用分隔符隔開后按照順序連接起來，再與子節(jié)點數(shù)、類型、各屬性連接起來， 即得到該節(jié)點的正則結(jié)果?？傊?，計算一個節(jié)點正則結(jié)果的方法可以采用以下 各種方案中的任意一種對樹的某一節(jié)點，其子節(jié)點數(shù)、類型、各屬性，子節(jié) 點數(shù)/類型/各屬性的長度(可選的)，原值或經(jīng)過特定變換(如HASH、壓縮), 按照預(yù)定順序連接起來(直接連接或用分隔符隔開)。上述預(yù)定順序的意思是，子節(jié)點數(shù)長度、類型長度、各屬性長度、子節(jié)點 數(shù)、類型、各屬性可以按任意順序排列，只要是預(yù)定的順序即可。
另外，在遍歷子樹中各個節(jié)點時，既可以釆用深度優(yōu)先遍歷也可以采用寬 度優(yōu)先遍歷。
不難給出上述方案的各種變化方式，如每個結(jié)點的子結(jié)點數(shù)用分隔符隔開 后按照深度優(yōu)先的順序連接起來，再與各結(jié)點其它數(shù)據(jù)的正則結(jié)果連接起來。 總之，只要對該子樹中的所有結(jié)點的子結(jié)點數(shù)、類型和各屬性，按照確定的方 法排列在一起就屬于本實施例的變化。
當對某一對象設(shè)置權(quán)限時，最簡單的實現(xiàn)方式是簡單記錄各角色對該對象 (及其子對象)的權(quán)限，并在今后各角色訪問時加以比較，符合權(quán)限的則允許 相應(yīng)操作，否則報錯返回。更好的實現(xiàn)方式是對相應(yīng)數(shù)據(jù)加密，并用密鑰來控 制權(quán)限，如果該角色沒有相應(yīng)密鑰就沒有對應(yīng)的權(quán)限，這種方式抗攻擊能力要
更強。具體方案為
a) 對受保護的數(shù)據(jù)區(qū)域(通常為一個子樹，對應(yīng)某對象及其所有子對 象)，有一對對應(yīng)的PKI密鑰對，用其中的加密密鑰對該數(shù)據(jù)區(qū)域進行加密。
b) 對具有讀權(quán)限的角色，授予其解密密鑰，該角色可以用該密鑰解密該 數(shù)據(jù)區(qū)域，從而正確讀取這些數(shù)據(jù)。
c) 對具有寫權(quán)限的角色，將授予其加密密鑰，該角色可以將修改后的數(shù)
據(jù)用該密鑰加密，〃Mv而可以正確寫入該區(qū)域的凄t據(jù)。
d) 鑒于PKI的加密/解密效率較低，為提高運行效率，也可以用對稱 密鑰來對該數(shù)據(jù)區(qū)域加密，加密密鑰用于對該對稱密鑰進行加密，解密密鑰用 于解密經(jīng)過加密后的密鑰數(shù)據(jù)，從而獲得正確的對稱密鑰。為防止只有讀權(quán)限 的角色在獲得對稱密鑰后用其修改數(shù)據(jù)，可以用加密密鑰來對該數(shù)據(jù)區(qū)域進行 數(shù)字簽名，每次擁有寫權(quán)限的角色修改該數(shù)據(jù)區(qū)域后都重新做一次簽名，從而 確保數(shù)據(jù)不會被沒有寫權(quán)限的角色篡改。
e) 當授予某一角色加密密鑰或解密密鑰時，可以用該角色的公鑰對該密 鑰加密后存儲，這樣只有擁有該角色的私鑰時才能取出該密鑰需要說明的是，本發(fā)明中所說明的文檔安全技術(shù)，如基于角色的權(quán)限管理、 角色的認證方式、多重角色登陸、對樹結(jié)構(gòu)的正則化技術(shù)、細粒度的權(quán)限管理 單元、基于加密的權(quán)限設(shè)置等，都不僅適用于本發(fā)明所述的文檔處理系統(tǒng)，還 可以運用于更為廣泛的其它應(yīng)用場合。
對層的管理
在本發(fā)明中，為了使本文檔處理系統(tǒng)能很好地模擬紙張的特性，提供了一 種"只加不改"的技術(shù)方案。也就是說，每個應(yīng)用軟件都只在現(xiàn)有文檔內(nèi)容基礎(chǔ) 上添加新的內(nèi)容，但不修改、不刪除已有的內(nèi)容，使文檔的一個頁面就象一張 紙一樣，可以由不同的人用不同的筆在紙上不斷寫寫畫畫，但誰都不能》務(wù)改、 刪除已有內(nèi)容。具體方法是每一個應(yīng)用軟件在編輯其它軟件生成的文檔時，都 在現(xiàn)有文檔基礎(chǔ)上新增加一層，將本軟件新編輯的內(nèi)容都放到這一層中，不修 改和刪除前面各層的內(nèi)容。這樣，每個文檔的每一層只由一個應(yīng)用軟件來管理 和維護，其他應(yīng)用軟件不能對該層進行編輯。由于現(xiàn)有社會就是基于紙張來運 轉(zhuǎn)的，因此只要能符合紙張的特性就能滿足現(xiàn)有應(yīng)用的需求，具備足夠的實用 價值。
為了確保每一層內(nèi)容在生成后沒有被修改、刪除，可以利用每一層的數(shù)字 簽名對象。數(shù)字簽名可以是對本層內(nèi)容進行簽名，優(yōu)選地，可以是對本層以及 本層之前生成的所有層的內(nèi)容一起簽名。簽名以后并不妨礙對文檔做進一步的 批注等編輯，只要新的內(nèi)容是位于新建的層，沒有修改破壞簽名時存在的各層， 簽名依然是有效的，但簽名者只對簽名以前的內(nèi)容負責，不對簽名以后的內(nèi)容 負責。這是一個非常符合應(yīng)用需求的技術(shù)方案，具有很大的實用價值。相比之 下，現(xiàn)有的其它技術(shù)或者簽名后不允許編輯，或者編輯后(盡管是"只加不改" 的編輯)簽名被破壞。
前述技術(shù)方案不允許修改文檔中的已有內(nèi)容，即使不考慮與紙張?zhí)匦缘募?容以及數(shù)字簽名問題，需要修改的話也只能做版面級編輯，即對每個版面對象 的編輯(增、刪、改)都不會對其它版面對象產(chǎn)生影響(這是由于通用文檔才莫
型是基于可見部分為基礎(chǔ)構(gòu)建的，不包含大量不可見的、關(guān)于版面對象之間的關(guān)系，因此修改任何一個版面對象時，其它版面對象不會產(chǎn)生相應(yīng)的調(diào)整，例 如刪掉一個字，就會在其位置留下空白，右邊的文字不會自動左移)。如果用 戶需要對文檔中的已有內(nèi)容進行編輯，并且還希望能像在原來那樣編輯的話， 有一個技術(shù)方案可以很好地滿足這個應(yīng)用需求。該方案是當應(yīng)用軟件完成初始
編輯時，除了新建一層存;^文當前編輯的內(nèi)容外，還將源文件(按照應(yīng)用軟件自 有的格式存儲，記錄了各對象之間完整關(guān)系的文件，例如.doc文件)嵌入到文
檔中。當下次需要進行繼續(xù)編輯時，/人文檔中取出該源文件，并使用該源文件 繼續(xù)編輯。編輯完成后清除該軟件所管理的那一層，重新生成該層的內(nèi)容，并 繼續(xù)將新修改的源文件嵌入到文檔中。
具體方法如下
1. 應(yīng)用軟件第一次處理該文檔時，新建一層，將新編輯內(nèi)容對應(yīng)的版面對 象插入到新建層中，同時用自身格式另存一J分新編輯的內(nèi)容(即源文件)。
2. 在文檔對象中新建一個源文件子對象，用來嵌入源文件(例如用二進制 數(shù)據(jù)的方式整體嵌入)，并記錄是哪一層對應(yīng)該源文件對象。
3. 用同 一應(yīng)用軟件再次編輯該文檔時， >夂人對應(yīng)的源文件對象中取出對應(yīng)的 源文件。
4. 使用該源文件繼續(xù)編輯該層內(nèi)容。由于該源文件是該應(yīng)用軟件自身的格 式，可以按照該應(yīng)用軟件自身的功能繼續(xù)對該層內(nèi)容進行編輯。
5. 再次編輯結(jié)束后，根據(jù)新編輯后的結(jié)果更新該層內(nèi)容(例如用全部清除 后全部重新生成的方式)，同時將新^修改后的源文件重新嵌入到文檔對象中。
6. 如此循環(huán)往復，就可以用原有應(yīng)用軟件按照原有方式對文檔中的已有內(nèi) 容進行編輯。
采用上述技術(shù)方案，可以最大程度地實現(xiàn)文檔的互操作性。在應(yīng)用軟件、 文檔都采用本發(fā)明技術(shù)時，在有足夠安全權(quán)限的前提下，可以實現(xiàn)以下功能
1. 對任何文檔，用任何應(yīng)用軟件都可以正確打開、顯示、打印。
2. 對任何文檔，用任何應(yīng)用軟件都可以新添加任何內(nèi)容，而且不會破壞文 檔已有簽名。3. 對任何文檔，在不必考慮文檔已有簽名(沒有簽名或者雖有簽名但允許
4. 對任何文檔，使用文檔已有內(nèi)容的原始編輯軟件可以對該內(nèi)容進行正常
由此可見，通過本發(fā)明中對層的管理，對文檔的管理、互操作、安全設(shè)置 都帶來極大的便利。
下面以A軟件創(chuàng)建一個文檔并且B軟件對其進行編輯為例說明其工作過 程。在本例中選用UOI作為接口標準
1. A軟件發(fā)出指令,創(chuàng)建文檔庫c:\sample\mydocbase.sep，將其句柄存放 在hDocBase:
UOI—Open("c:WsampleWmydocbase.sep", TRUE, &hDocBase);
2. A軟件發(fā)出指令,在文檔庫hDocBase中新建文檔集，將其句柄存放在 hDocSet:
hDocSet = InsertNewObj(hDocBase, 0, UOI—Obj:: TYPE—DOCSET);在本實例中， 該文檔庫中只有一個文檔集，即第一個文檔集；
3. A軟件發(fā)出指令,在文檔集hDocBase中新建文檔，將其句柄存;^文在 hDoc:
hDoc = InsertNewObj(hDocSet, 0, UOI—Obj:: TYPE—DOC);在本實例中，該文檔 集只有一個文檔，即第一個文檔；
4. A軟件發(fā)出指令，在文檔hDoc中新建一頁，版心大小是寬w,高h,將 其句柄存放在KPage:
UOI—Page page; page.size.w畫 w; page.size.h =
UOI_Insert(hDoc, 0, &page, &hPage);在本實例中，該文檔中只有一頁，即第一
頁；
5. A軟件發(fā)出指令，在頁hPage中創(chuàng)建一層，將其句柄存放在hLayer:hLayer = InertNewObj(hPage, 0, UOI—Obj::TYPE—LAYER);在本實例中，該頁只 有一層，即第一層；
6. A軟件發(fā)出指令，設(shè)置字號為s: UOI—CharSize charSize; charSize.m—Width ■— charSize.m—Height — s;
UOI—Insert(hLayer, 0, &charSize);在本實例中，該層的第一個版面對象是字號
對象；
7. A軟件發(fā)出指令,在坐標(xl,yl)位置插入文字串"書生意氣揮斥方遒" UOI—Text text;
text.m_pText = Duplicate("書生意氣揮斥方遒")； text.m—Encoding = UOI—Text:: ENCODE—GB13000; text.m—Start.x = xl; text.m一Start.y = yl;
UOI—Insert(hLayer, 1, &text);在本實例中，該層的第二個對象是文字對象；
8. A軟件發(fā)出指令,關(guān)閉文檔庫hDocBase: UOI—Close(hDocBase);
B軟件發(fā)出指令,打開文檔庫c:\sample\mydocbase.sep，將其句柄存放在
hDocBase:
UOI—Open("c:WsampleWmydocbase.sep", FALSE, &hDocBase);
B軟件發(fā)出指令,獲取文檔庫hDocBase第一個文檔集的指針，將其句柄存 放在hDocSet:
UOI—GetHandle(hDocBase, 0, &hDocSet);
9. B軟件發(fā)出指令,獲取文檔集hDocSet第 一個文檔的指針，將其句柄 存放在hDoc:
UOI—GetHandle(hDocSet, 0, &hDoc);
10. B軟件發(fā)出指令,獲取文檔hDoc第一頁的指針，將其句柄存放在 hPage:
UOI—GetHandle(hDoc, 0, &hPage);11. B軟件獲取該頁版面位圖，用于顯示該頁
UOI—GetPageBmp(hPage， rect, buf);
12. B軟件發(fā)出指令,獲取hPage第一層的指針，將其句柄存放在hLayer: UOI—GetHandle(hPage, 0, &hLayer);
13. B軟件發(fā)出指令，獲取第一個版面對象的句柄hObj: UOI—GetHandle(hLayer, 0， &hObj);
14. B軟件發(fā)出指令,獲取hObj的類型 UOI—GetObjType(hObj， &type);
15. B軟件發(fā)現(xiàn)這是一個字號對象，獲取該對象 UOI—GetObj(hObj, &charSize);
16. B軟件將字高放大一倍 charSize.m—Height *= 2; UOI一SetObj(hObj, &charSize);
B軟件重新獲取版面位圖并顯示，這時會發(fā)現(xiàn)屏幕上的"書生意氣揮斥方 遒"變成長體字了 。
本發(fā)明改變了從用戶界面到文檔存儲都由一個軟件來完成的現(xiàn)狀，將其劃 分為應(yīng)用層和文檔庫系統(tǒng)層，并定義一個規(guī)范兩層之間交互的接口標準，還可 以進一步構(gòu)建一個符合該接口標準的接口層。文檔庫系統(tǒng)是具備各種文檔操作 功能的通用技術(shù)平臺，應(yīng)用軟件要對文檔進行操作時就通過該接口層來向文檔 庫系統(tǒng)發(fā)出相應(yīng)指令，文檔庫系統(tǒng)根據(jù)該指令執(zhí)行相應(yīng)操作。這樣，只要各應(yīng) 用軟件和各文檔庫系統(tǒng)都遵循同樣的標準，不同應(yīng)用軟件就可以通過同 一個文 檔庫系統(tǒng)對同一文檔操作，即可實現(xiàn)對文檔的互操作。同樣，同一個應(yīng)用軟件 也可以通過不同文檔庫系統(tǒng)對不同文檔進行操作，而不用分別對每種文檔格式 都進行單獨開發(fā)。
本發(fā)明還包括一個通用文檔模型，該模型能與各應(yīng)用軟件所需要處理的文 檔相符合。接口標準就是基于該文檔模型來確定的，這樣才能實現(xiàn)不同的應(yīng)用 軟件都可以通過接口層來對文檔進行操作。該通用文檔^t型也適用于各種文檔格式，這樣同 一個應(yīng)用軟件才可以通過接口層來對不同文檔格式進行操作。接口標準定義了基于該通用文檔模型對文檔進行操作的各種指令，以及應(yīng)用軟件向文檔庫系統(tǒng)發(fā)送指令的方式。文檔庫系統(tǒng)具備實現(xiàn)這些指令的功能，以供應(yīng)用軟件調(diào)用。該通用文檔模型還包括由多個文檔組成的文檔集、文檔庫和文檔倉庫等層次，接口標準中也包含對多文檔的組織管理、查詢檢索、安全控制等指令。該通用模型還包括將頁由具有上下順序的層組成，接口標準中也包含對層 的各種操作指令，以及對一個文檔某一層所對應(yīng)源文件的存儲和提取。文檔庫系統(tǒng)還具備對文檔的信息安全管理控制功能，如基于角色的細粒度 權(quán)限管理，并在接口標準中定義了相關(guān)的操作指令。依照本發(fā)明，使得應(yīng)用層和數(shù)據(jù)處理層分離。這樣應(yīng)用軟件不再直接跟具 體的文檔格式打交道，文檔也不再與特定應(yīng)用軟件綁定，從而使得同一文檔能 在不同的應(yīng)用軟件之間通用，同一應(yīng)用軟件也能對不同文檔進行操作，實現(xiàn)了文檔的互操作；整個文檔處理系統(tǒng)還具備多文檔處理功能，而不局限在單文檔 處理；將頁分成多層后，可以實現(xiàn)對不同層實施不同管理和控制，更便于不同 應(yīng)用軟件對同 一頁的操作(可以設(shè)計成不同應(yīng)用軟件管理和維護不同層)，為以 源文件方式進行編輯提供了便利，也是一種很好的保留歷史痕跡的方式；通過 將信息安全集成在文檔處理的核心層，可以消滅安全縫隙，還能使安全機制與 文檔操作緊密地結(jié)合為一體，而不是可以分離的兩個it塊，同時有更多的空間 部署安全管理技術(shù)，相關(guān)代碼也能隱藏得更深，能更有效地防御非法攻擊，提 高安全可靠度，另外還能提供細粒度的安全管理手段，如更多的權(quán)限類別，更 小的管理單元。下面，參照圖18描述依照本發(fā)明的文檔操作系統(tǒng)執(zhí)行一操作的一個實例。 在該實例中，應(yīng)用軟件通過統(tǒng)一的接口標準(例如UOML接口 )請求對文檔的 操作。文檔庫系統(tǒng)可能會有不同廠商的不同型號，但是對于應(yīng)用開發(fā)廠商來說 面向的都是同一個接口標準，因此都可以與之配套使用。RedOffice、 OCR、網(wǎng) 頁生成軟件、樂語編輯軟件、書生閱讀器、Office編輯軟件、其他閱讀器等通過UOML接口指示文檔庫系統(tǒng)進行操作，文檔庫系統(tǒng)可以有多個，在圖中顯示 為文檔庫系統(tǒng)1 、文檔庫系統(tǒng)2和文檔庫系統(tǒng)3 ，文檔庫系統(tǒng)根據(jù)UOML發(fā)來 的統(tǒng)一標準指令對符合通用文檔模型的文檔進行操作，例如創(chuàng)建、保存、顯示、 呈現(xiàn)文檔。在本發(fā)明中，不同的應(yīng)用軟件可以同時或不同時調(diào)用同一個文檔庫 系統(tǒng)，同一應(yīng)用軟件可以同時或不同時調(diào)用不同的文檔庫系統(tǒng)。依照本發(fā)明，使得應(yīng)用層和數(shù)據(jù)處理層分離，使得同一文檔能在不同的應(yīng) 用軟件之間通用，使不同應(yīng)用軟件之間具有良好的文檔互操作性。依照本發(fā)明，形成產(chǎn)業(yè)分工，減少重復開發(fā)，并更加專業(yè)、完備、正確； 對文檔的基本操作都在文檔庫系統(tǒng)中處理，各應(yīng)用軟件不必重復開發(fā)。而且由 于文檔庫系統(tǒng)是由專業(yè)廠商開發(fā)，相關(guān)技術(shù)的專業(yè)性、完備性、正確性較有保 障，而且應(yīng)用軟件廠商和用戶可以選擇估支的最好的一家文檔庫系統(tǒng)廠商，從而 保證處理效果的正確性和 一致性。依照本發(fā)明，提供多文檔甚至海量文檔的管理機制，使文檔之間能夠有效 組織起來，便于檢索、查詢、保管，便于嵌入較強的信息安全機制。依照本發(fā)明，提供更好的安全機制，可以設(shè)置多種角色，細粒度地設(shè)置每 個角色的權(quán)限。其中細粒度是雙重的， 一方面可以對整個文檔或文檔的一個細 微之處進行權(quán)限設(shè)置，另一方面可以設(shè)置種類非常多的權(quán)限，而不僅僅是傳統(tǒng) 的讀/寫/不可訪問三級。依照本發(fā)明，鼓勵創(chuàng)新，合理竟爭。形成合理的產(chǎn)業(yè)分工后，各文檔庫系 統(tǒng)廠商和各應(yīng)用軟件廠商就會在領(lǐng)域展開竟爭，而不會再出現(xiàn)Microsoft Word 一樣靠文檔格式來壟斷應(yīng)用軟件的情形發(fā)生。各文檔庫系統(tǒng)廠商也可以在標準 之外增加新的功能以吸引用戶，標準并不會對創(chuàng)新形成束縛。依照本發(fā)明，便于優(yōu)化性能，有更好的可移植性和可伸縮性。無論是什 么平臺，什么樣的性能，都可以遵循同樣的調(diào)用接口 ，使得在不改變接口標 準的情況下可以不斷優(yōu)化性能，并移植到不同的平臺。以上所述僅為本發(fā)明的較佳實施例而已，并不用以限制本發(fā)明，凡在本 發(fā)明的精神和原則之內(nèi)所作的任何修改、等同替換和改進等，均應(yīng)包含在本發(fā)明的保護范圍之內(nèi)。
權(quán)利要求
1、一種文檔處理方法，其特征在于，包括應(yīng)用軟件發(fā)送指令到平臺軟件，以對抽象非結(jié)構(gòu)化信息進行操作；平臺軟件接收到來自所述應(yīng)用軟件的指令，根據(jù)所述指令，對與所述抽象非結(jié)構(gòu)化信息對應(yīng)的存儲數(shù)據(jù)執(zhí)行所述操作；其中，所述抽象非結(jié)構(gòu)化信息與所述存儲數(shù)據(jù)的存儲方式無關(guān)。
2、 如;k利要求1所述的方法，其特征在于，所述抽象非結(jié)構(gòu)化信息不具有 存儲。
3、 如權(quán)利要求l所述的方法，其特征在于，所述抽象非結(jié)構(gòu)化信息包括可 視化信息、和/或流媒體信息、和/或多維信息、和/或安全控制信息、和/或文檔 組織4言息、和/或交互4言息。
4、 如權(quán)利要求l所述的方法，其特征在于，通過發(fā)送命令串或調(diào)用函數(shù)來 發(fā)送指令。
5、 如權(quán)利要求l所述的方法，其特征在于，所述存儲數(shù)據(jù)為一個或多個磁 盤文件、部分磁盤文件、數(shù)據(jù)庫的一個或多個字段、或磁盤分區(qū)的一個區(qū)域。
6、 如權(quán)利要求l所述的方法，其特征在于，所述抽象非結(jié)構(gòu)化信息包括多 個頁的可視化信息。
7、 如權(quán)利要求l所述的方法，其特征在于，所述抽象非結(jié)構(gòu)化信息符合預(yù) 定義文檔^t型。
8、 如權(quán)利要求l所述的方'法，其特征在于，所述預(yù)定義文檔模型為樹形結(jié) 構(gòu)，并且包括至少文檔對象、頁對象以及用于描述版面的對象。
9、 如權(quán)利要求8所述的方法，其特征在于，所述用于描述版面的對象可以 是文字對象、圖片對象和圖形對象中的任一項或任幾項的組合。
10、 如權(quán)利要求9所述的方法，其特征在于，所述用于描述版面的對象還 可以是狀態(tài)對象、文字對象、直線對象、曲線對象、圓弧對象、路徑對象、漸 變色對象、圖像對象、流媒體對象、元數(shù)據(jù)對象、批注對象、語義信息對象、源文件對象、腳本對象、插件對象、二進制數(shù)據(jù)流對象、書簽對象以及超鏈接 對象中任一項或任幾項的組合。
11、 如權(quán)利要求8所述的方法，其特征在于，所述預(yù)定義文檔模型進一步包括文檔庫對象，所述文檔庫對象包括至少一個文檔對象；或者，所述預(yù)定義^t型進一步包括文檔庫對象和文檔集對象，其中所述文檔庫對 象包括至少一個文檔集對象，所述文檔集對象包括至少一個文檔對象和\或至少 一個文檔集對象。
12、 如權(quán)利要求8所述的方法，其特征在于，所述預(yù)定義文檔^t型進一步 包括層對象，所述頁對象包括至少一個層對象，所述層對象包括至少一個用于 描述版面的對象。
13、 如權(quán)利要求12所述的方法，其特征在于，所述預(yù)定義文檔模型進一步 包括對象組對象，所述層對象包括至少一個對象組對象，所述對象組對象包括 至少一個用于描述版面的對象。
14、 如權(quán)利要求7所述的方法，其特征在于，所述預(yù)定義文檔^f莫型進一步 包括角色對象以及角色的訪問權(quán)限。
15、 如權(quán)利要求14所述的方法，其特征在于，所述角色的訪問權(quán)限包括所 述角色針對所述抽象非結(jié)構(gòu)化信息的至少一個對象的訪問權(quán)限。
16、 如權(quán)利要求l所述的方法，其特征在于，所述指令符合操作動作+操 作對象的標準，以指示一個4喿作。
17、 如權(quán)利要求16所述的方法，其特征在于，所述操作包括獲取信息、 設(shè)置對象屬性、插入對象、刪除對象以及查詢。
18、 如權(quán)利要求16所述的方法，其特征在于，所述指令按預(yù)定義的格式生成。
19、 如權(quán)利要求18所述的方法，其特征在于，所述指令包含描述操作動作 和操作對象的字符串。
20、 如權(quán)利要求19所述的方法，其特征在于，所述字符串用可擴展標記語 言XML描述。
21、 如權(quán)利要求20所述的方法，其特征在于，所述操作動作對應(yīng)一個XML 元素，所述操作對象通過句柄handle引用。
22、 如權(quán)利要求16所述的方法，其特征在于，所述平臺軟件提供接口函數(shù)， 每個接口函數(shù)定義針對一個對象的一個操作；所述應(yīng)用軟件通過調(diào)用與所述操作動作和操作對象對應(yīng)的接口函數(shù)，發(fā)送 所述指令。
23、 如權(quán)利要求16所述的方法，其特征在于，所述平臺軟件提供基于對象 類的方法；所述應(yīng)用軟件通過調(diào)用所述對象類的方法發(fā)送指令；其中所述對象類由所 述操作對象封裝而成，所述對象類的方法對應(yīng)所述操作動作。
24、 如權(quán)利要求l所述的方法，其特征在于，所述平臺軟件進一步為應(yīng)用 軟件提供操作結(jié)果。
25、 —種文檔處理系統(tǒng)，其特征在于，包括應(yīng)用軟件，用于發(fā)送指令到平臺軟件，以對抽象非結(jié)構(gòu)化信息進行操作； 平臺軟件，用于接收到來自所述應(yīng)用軟件的指令，根據(jù)所述指令，對與所 述抽象非結(jié)構(gòu)化信息對應(yīng)的存儲數(shù)據(jù)執(zhí)行所述操作；其中，所述抽象非結(jié)構(gòu)化信息與所述存儲數(shù)據(jù)的存^f諸方式無關(guān)。
26、 一種文檔處理方法，其特征在于，包括 第一應(yīng)用軟件發(fā)送第一指令到平臺軟件，以創(chuàng)建第一抽象文檔；所述平臺軟件接收所述第 一指令，創(chuàng)建與所述第 一抽象文檔對應(yīng)的存儲數(shù)據(jù)；第二應(yīng)用軟件發(fā)送第二指令到所述平臺軟件以打開所述創(chuàng)建的存儲數(shù)據(jù)； 所述平臺軟件接收所述第二指令，打開并解析所述存儲數(shù)據(jù)，生成與所述 存儲數(shù)據(jù)對應(yīng)的第二抽象文檔；其中所述第 一指令與第二指令符合相同的接口標準。
27、 一種文檔處理系統(tǒng)，其特征在于，包括第一應(yīng)用軟件，用于發(fā)送第一指令到平臺軟件，以創(chuàng)建第一抽象文檔；所述平臺軟件，用于接收所述第一指令，創(chuàng)建與所述第一抽象文檔對應(yīng)的存儲數(shù)據(jù)；第二應(yīng)用軟件，用于發(fā)送第二指令到平臺軟件以打開所述創(chuàng)建的存儲數(shù)據(jù)； 所述平臺軟件，進一步用于接收所述第二指令，打開并解析所述存儲數(shù)據(jù)， 生成與所述存儲數(shù)據(jù)對應(yīng)的第二抽象文檔；其中，所述第一指令與第二指令符合相同的接口標準。
28、 一種文檔處理方法，其特征在于，包括第一平臺軟件解析以第一數(shù)據(jù)格式存儲的第二存儲數(shù)據(jù)，生成與所述存儲 數(shù)據(jù)對應(yīng)的第 一抽象文檔；所述應(yīng)用軟件發(fā)送第 一指令到所述第 一平臺軟件，以獲取所述第 一抽象文 檔的所有信息；發(fā)送第二指令到第二平臺軟件，以創(chuàng)建與所述第一抽象文件相 同或相似的第二抽象文檔；所述第二平臺軟件根據(jù)所述第二指令，創(chuàng)建與所述第二抽象文檔對應(yīng)并按 第二數(shù)據(jù)格式存儲的第二存儲數(shù)據(jù)；其中，所述第一指令和第二指令符合相同的接口標準。
29、 一種文檔處理系統(tǒng)，其特征在于，包括第一平臺軟件，用于解析以第一數(shù)據(jù)格式存儲的第一存儲數(shù)據(jù)，生成與所 述存儲數(shù)據(jù)對應(yīng)的第 一抽象文檔；所述應(yīng)用軟件，用于發(fā)送第一指令到所述第一平臺軟件，以獲取所述第一 抽象文檔的所有信.息；發(fā)送第二指令到第二平臺軟件，以創(chuàng)建與所述第一抽象 文件相同或相似的第二抽象文檔；所述第二平臺軟件，用于根據(jù)所述第二指令，創(chuàng)建與所述第二抽象文檔對 應(yīng)并按第二數(shù)據(jù)格式存儲的第二存儲數(shù)據(jù)；其中，所述第一指令和第二指令符合相同的接口標準。
全文摘要
本發(fā)明公開了一種文檔處理系統(tǒng)和方法，該方法包括應(yīng)用軟件發(fā)送指令到平臺軟件，對抽象非結(jié)構(gòu)化信息進行操作；平臺軟件接收到來自所述應(yīng)用軟件的指令，根據(jù)所述指令，對與所述抽象非結(jié)構(gòu)化信息對應(yīng)的存儲數(shù)據(jù)執(zhí)行所述操作；其中，所述抽象非結(jié)構(gòu)化信息與所述存儲數(shù)據(jù)的存儲方式無關(guān)。本發(fā)明的這種系統(tǒng)和方法將應(yīng)用層和數(shù)據(jù)處理層分離，有利于產(chǎn)業(yè)分工，以及達到文檔互操作、信息資源互聯(lián)互通等有益效果。
文檔編號G06F9/44GK101599011SQ20081011445
公開日2009年12月9日 申請日期2008年6月5日 優(yōu)先權(quán)日2008年6月5日
發(fā)明者劉寧勝, 王東臨 申請人:北京書生國際信息技術(shù)有限公司