幾種基于XML的流式文檔訪問方式分析

2014-02-09 07:46:52田英愛劉旭紅

計算機工程與設計 2014年4期

唐燕，田英愛，李寧，劉旭紅

（1.網絡文化與數(shù)字傳播北京市重點實驗室，北京100101；2.北京信息科技大學計算機學院，北京100101）

0 引言

在信息化建設發(fā)展的過程中，作為信息主要載體的文檔，成為我們工作生活中不可或缺的一部分，其中對基于XML格式的流式辦公文檔的應用最為廣泛［1］。目前世界主流的流式辦公文檔格式主要有3種:標準為ISO/IEC 26300:2006的開放文檔格式（open document format，ODF）［2］、標準為ISO/IEC 29500:2008的OOXML（office open XML）［3］以及標準為GB/T20916－2007的標文通（uniform office format，UOF）［4］。這3種流式文檔格式都基于XML，相應的處理技術也由原來的VBA、宏等方式逐漸過渡到利用XML相關技術進行處理。

在早期，用戶對流式文檔的操作，主要基于辦公文檔處理軟件，并可以使用VBA、宏等方式擴展對辦公文檔的處理。帶來的問題是，傳統(tǒng)的方式效率低，速度慢，所能處理的文檔格式單一，因其過分依賴辦公軟件產品，使之對于不同格式的流式文檔而言，無法通過同一個辦公軟件實現(xiàn)操作互通，給用戶帶來不便。

流式辦公文檔采用基于XML的格式之后，對XML文檔的各種訪問技術也被用于對流式辦公文檔的處理。針對基于XML格式的文檔，出現(xiàn)了很多XML數(shù)據(jù)訪問技術，如:XPath、XSLT、DOM和SAX、XQuery、LINQ、相應格式的API/SDK、UOML、ODQ等。

本文針對流式文檔處理的需求，對XQuery、DOM、相應格式的API/SDK、ODQ這4種流式文檔處理技術進行了較細致的研究，并從基本查詢功能、處理流程、格式無關性、查詢粒度等多方面進行了分析比較。

1 流式文檔處理需求與處理技術

1.1 流式文檔的處理需求

隨著對流式辦公文檔應用領域的不斷擴展，對其訪問與操作的需求也呈現(xiàn)了多樣化的趨勢，具體如下:

（1）格式無關性需求。由于目前存在的流式辦公文檔格式不統(tǒng)一，對文檔內容的訪問與操作都要依賴于支持相應格式的辦公軟件產品，無法實現(xiàn)離線文檔操作。因此需要有一種統(tǒng)一的方式，能夠對各種格式文檔進行相應的訪問與操作，以屏蔽文檔底層存在的格式差異，實現(xiàn)文檔格式的互操作；

（2）文檔訪問查詢粒度適中性需求。對于流式辦公文檔而言，用戶常常希望能夠以段落、列表、表格、圖片等基本元素，即文檔的功能點［5］進行訪問與操作，而目前對于流式辦公文檔的訪問操作，要么是利用文檔中提供的元數(shù)據(jù)對整個文檔實現(xiàn)獲取，粒度較粗糙，無法很好地從文檔真實的內容中準確獲得數(shù)據(jù)，很多流式文檔的數(shù)據(jù)資源無法得到有效的共享和利用；要么就是利用XML的相關技術，訪問文檔的結構粒度過于細致，效率不高的同時，也不利于流式文檔上下文環(huán)境內容理解。因此，流式辦公文檔訪問查詢粒度的適中性，也成為流式文檔得以進一步應用的阻礙；

（3）文檔操作的簡便實用性需求。利用XML技術對流式文檔進行訪問，無論是專業(yè)開發(fā)人員還是普通用戶，都需要學習復雜的語言及編程思想，編寫繁瑣的代碼，并且，對文檔邏輯結構要有一定的了解，訪問方式不夠簡單。此時，迫切需要一種簡便實用的流式文檔訪問技術。

1.2 流式文檔處理技術

訪問流式辦公文檔的處理需求的增加，使得相應的處理技術變得非常關鍵。這里給出XML數(shù)據(jù)訪問技術的簡要介紹:

（1）XPath。W3C的XPath主要是對XML文檔底層元素和屬性等節(jié)點直接進行操作的技術，它是直接針對XML的樹形結構的路徑表達式導航來定位XML文檔中的各個節(jié)點。表達直觀，但表達式構造復雜容易出錯，如果不借助其它工具，則需要手工編寫完成，耗時耗力［6］。

（2）XSLT。XSLT是以XPath為基礎發(fā)展起來的，是利用XPath獲取所需節(jié)點，并進行相應處理，但表達能力有所限制，不夠靈活。

（3）DOM和SAX。DOM技術是利用樹型結構來對XML文檔中的各個元素（節(jié)點）進行處理，使對XML的文檔處理更為靈活，但DOM處理需一次將整個XML文檔載入內存，尤其是對于規(guī)模較大的XML文檔，其處理速度較慢［7］；為避免DOM加載慢的問題，SAX技術被提出來，利用SAX處理時，不是一次性把整個文件加載到內存中，而是對XML文件按其對應節(jié)點的訪問次序，將文件的一部分加載入內存［8］，相比DOM處理速度大大提升。

（4）XQuery技術。XQuery的查詢描述能力較強，相比其它訪問方式來說，可支持多文檔聯(lián)合查詢［9］，但語言過于復雜，普通用戶不易完全掌握。

（5）LINQ技術。隨著對文檔訪問技術的簡化需求增加，微軟在Visual Studio 2008中引入了LINQ，其關鍵技術包括LINQ to XML，該技術提供了一套比DOM更輕量的API，相比使用以往的操作方法，使得處理XML更為容易［10］。

（6）相應格式的API/SDK。目前主流的流式辦公文檔格式ODF，OOXML以及UOF，都提供了相應的API或SDK，那么，利用API或SDK來對流式文檔的訪問就可以直接針對文檔的功能點進行直接獲取并進行各種操作，便于實現(xiàn)對文檔的進一步應用或二次開發(fā)。

（7）UOML。UOML是OASIS的正式標準，是電子文件領域針對基于XML的版式文檔的接口標準，它定義了一整套非結構化文檔的操作規(guī)范［11］，可以很方便地對版式文檔進行訪問與操作，屏蔽底層細節(jié)問題，能夠實現(xiàn)不同格式文檔的互相讀寫。

（8）ODQ。ODQ是一種專門針對流式辦公文檔的訪問技術［12］，它從用戶使用需求出發(fā)，能夠脫離辦公軟件，利用較為通俗的語句，對不同格式的文檔直接獲取其局部內容并進行相應的操作，方便用戶使用；同時對開發(fā)人員來說，能夠屏蔽底層的操作細節(jié)，使之更專注于上層應用開發(fā)。

2 流式辦公文檔查詢的典型方法

目前，流式辦公文檔多采用文件打包形式，例如ODF、OOXML以及UOF都支持zip打包結構，因此對流式文檔進行訪問查詢時，首先必須對其進行解壓，生成多個XML文件，此外，由于流式辦公文檔中除了包含呈現(xiàn)給我們的具體邏輯內容（文字、表格、圖片等）外，還有諸多的顯現(xiàn)式樣信息和頁面版式信息，這些信息都分散在流式文檔解壓后的各個XML文件中，在對流式文檔訪問處理時，就必須先識別即將訪問的信息在流式文檔中的哪個XML文件中，這就要求處理人員具有一定的專業(yè)知識。

本節(jié)以XQuery、DOM、相應格式的API/SDK這3種對流式辦公文檔的主流查詢方法為例，分析各自查詢的實現(xiàn)機制以及在訪問流式文檔方面的不足之處。

2.1 DOM方法

DOM是跨平臺、與語言無關的，訪問XML的標準接口。在利用DOM處理XML文檔時，文檔模型以樹型的數(shù)據(jù)結構映射到內存中，并將文檔中的元素、屬性等看作樹結構的各個節(jié)點。那么，開發(fā)人員對文檔中各個對象的訪問操作，就可以通過DOM解析器中提供的相應接口來實現(xiàn)動態(tài)訪問和更新XML文檔中的各個節(jié)點。DOM解析器在解析文檔的時候可以遍歷到樹的任意節(jié)點，還可以通過添加、刪除或更新樹中的節(jié)點把源文檔轉換為其它結構的文檔［7］，以實現(xiàn)對文檔中各個對象的操作。

當利用DOM對流式文檔進行訪問時，首先，需要將辦公文檔解壓并生成多個XML文件，必要時還需要將解壓后的多個XML文件進行合并，生成一個較大的XML文件；其次，需要根據(jù)用戶的需求，由編程開發(fā)人員明確所要訪問的文檔對象在哪些具體XML文件或合成文件的哪些部分中，并且確定所要獲取的對象包括了XML文件中哪些具體的節(jié)點；第三，構造DOM解析器，將確定的XML文件中的內容分成獨立的元素、屬性和注釋等［13］，裝入內存；第四，實例化XML文件的XmlDocument類，在內存中生成描述XML文件的類，同時生成包含所有節(jié)點的樹狀結構，通過調用DOM提供的各種接口，遍歷訪問結構樹中的節(jié)點，讀取節(jié)點值并進行相應操作。DOM對流式文檔的查詢過程如圖1所示。

圖1 DOM查詢過程

通過以上對處理過程的分析并在編程實踐中發(fā)現(xiàn)，利用DOM對流式辦公文檔訪問和處理時，存在一些問題，主要體現(xiàn)在以下幾個方面:

（1）在對流式辦公文檔的訪問處理時，用戶通常直接針對文檔的功能點進行訪問處理，這些功能點不但包括了文檔的邏輯內容，還包括修飾文檔邏輯內容的式樣信息或頁面版式信息，這些信息會不規(guī)則地散布在文檔中的各個部分，那么對于文檔的某個具體功能點而言，其操作就不僅僅是XML文件的某個局部的節(jié)點信息，還可能需要處理和獲取多個文檔或文檔的多個部分。這就需要開發(fā)人員對文檔內部結構有深入的了解，并能夠識別具體需要訪問的內容在哪個文件中或文件的哪個部分，不能以較簡單的方式直接訪問文檔。

（2）DOM方式中，每一次對普通XML文檔內容的定位都是獲取或修改文檔中的節(jié)點，這些屬于細粒度的操作。對于操作流式文檔的用戶來說，大多需要的是針對文檔功能點的操作，如獲取文檔段落、圖形、表格、式樣信息等。文檔功能點在XML描述時，需要用多個元素和屬性進行描述，若用DOM方式進行訪問操作時，則需多次調用DOM的各種接口，給編程帶來復雜性。

（3）流式文檔中，若要使邏輯內容和式樣內容分離，文件結構中必然會存在大量的引用關系。需要根據(jù)所要訪問的對象找到其關于式樣的引用標識符，再通過標識符定位到所需式樣，這時，可能需要重新遍歷，或者再去尋找其它XML文件，對于專業(yè)開發(fā)人員來說，需要編寫復雜的程序代碼以獲取所需信息。

還有一種與DOM類似的方法SAX，它不會一次性讀取全部文檔中的數(shù)據(jù)，而是將所需部分讀入內存［14］，是一種快速讀寫XML數(shù)據(jù)的方式。SAX訪問方式盡管比DOM處理速度快，但仍然沒有辦法避免DOM在處理流式文檔時存在的缺點。

2.2 XQuery方法

XQuery是基于一種XML結構的表達式語言，其查詢被描述成簡單的或是嵌套的表達式。XQuery應用XPath和FLWR表達式進行查詢，建立在XPath規(guī)范之上［15］，其核心是能夠通過XPath表達式獲取和操作文檔中的節(jié)點序列，這也正是訪問處理流式文檔功能點的本質所在。這一點，XQuery比DOM方式更適合流式文檔查詢。在解析XML文檔時，用一段XQuery表達式，通過XQuery處理器進行分析和計算，返回一個序列的值寫入到XML文件中作為查詢結果。

XQuery和DOM語言類似，對于一個流式文檔的查詢，都需要先將整個流式辦公文檔解壓生成多個XML文件，并且對所要獲取的數(shù)據(jù)是邏輯內容文件還是式樣內容文件進行文檔結構的識別。但是，對于編寫的用于訪問與操作的XQuery語句，需要單獨保存于后綴名為.xquery的文件中。其次，啟動XQuery處理器，以生成內部可解釋代碼，通過程序調用外部.xquery文件，解析出其中包含的查詢條件、查詢對象、查詢結果格式；最后，執(zhí)行查詢語句并返回結果。一個基本的XQuery訪問流式文檔的處理過程如圖2所示。

圖2 XQuery查詢過程

XQuery方法訪問流式文檔，也有其明顯的不足之處:

（1）同樣地，隨著對通用XML文檔操作功能需求的增加，XQuery方式也顯示出訪問粒度過細的問題，與文檔功能點的訪問處理粒度不符；

（2）W3C對XQuery不斷進行更新，從最初的支持XML數(shù)據(jù)更新功能到支持動態(tài)網頁開發(fā)和分布式軟件開發(fā)，其功能正日益強大。但由于XQuery的嵌套和多關鍵字排序特性，使得其查詢處理的復雜度增加［16］。此外，如前文所述，和DOM方式中存在的引用問題一樣，專業(yè)開發(fā)人員需要編寫復雜的程序代碼；

（3）開發(fā)人員也是需要明確了解待查XML文檔的內部結構，訪問方式不夠簡單化。

2.3 API/SDK方法

為了能更有針對性的對流式辦公文檔的各個功能點進行提取，并以此進行更多的二次開發(fā)和擴展應用，各大標準組織機構和辦公軟件廠商都提供了對其相應格式文檔功能點進行訪問操作的API，如主流辦公文檔格式ODF、OOXML、UOF均設計了比較完善的應用編程接口。API將對XML文件的操作進行封裝，為辦公軟件用戶提供獨立的文檔操作功能，常用的是對文檔內容的增、刪、改、查操作，還包括一些基本式樣的修改等操作，可以直接對辦公文檔的功能點進行操作。對于大多數(shù)API方法來說，處理步驟如下:

（1）創(chuàng)建一個代表整個文檔的文檔對象；

（2）利用API中相應的代表文檔功能點的類定義所要訪問的文檔功能點對象；

（3）通過（1）中創(chuàng)建的文檔對象調用API中提供的獲取段落集、列表集等函數(shù)，返回代表指定文檔所要訪問的功能點對象的集合，用（2）中定義的對象接收這個集合；

（4）利用（3）中的對象獲取到所要訪問的功能點；

（5）取出功能點的值并返回結果。

API是直接面向流式文檔各個功能點而設計的接口，使文檔的應用不再依賴具體的辦公軟件產品，用戶無需了解復雜的文檔底層結構便可直接訪問流式文檔的各功能點，且訪問較高效、簡潔快速。此外，還方便了辦公文檔的在線處理以及文檔的協(xié)作處理，為文檔和其它應用的集成奠定基礎，比DOM和XQuery更適合流式辦公文檔的查詢處理。但是API方法仍表現(xiàn)出如下缺點:

（1）目前許多格式的API依賴于自身的產品。如ODF的API有其專門的UNO架構，OOXML的API則需要VBA/.NET和Windows環(huán)境，避免不了平臺和語言的相關性［1］。3種文檔格式的差異，導致相應格式的API只能針對各自的格式文檔進行訪問，格式的互操作問題存在障礙；

（2）雖然避免了對XML文檔內部邏輯結構的直接操作，但仍需要專業(yè)開發(fā)人員具備一定的編程能力，且針對不同格式的文檔訪問需要了解不同的API或相應格式的SDK。

3 ODQ查詢方法

目前對流式辦公文檔格式互操作要求提高，對文檔功能點需要能夠直接獲取和操作，針對這類需求，本課題組在文獻［12］中提出了ODQ，它是一種主要針對流式辦公文檔的新型查詢語言，建立在三大主流辦公文檔格式對應API之上，是一種更高層次的API，對不同格式的文檔可以直接獲取其局部內容并進行相應的操作。目前，關于ODQ的需求分析、流式文檔模型的構建、ODQ的形式化描述都已完成。

對于流式文檔的主要功能點，用該方法可以實現(xiàn)概念級別的查詢和操作，即類似元數(shù)據(jù)、段落、表格、圖片這類的訪問對象。不僅符合用戶的使用習慣，也方便開發(fā)人員對所需內容數(shù)據(jù)的提取和進一步操作。

本節(jié)中，將圍繞ODQ對其進行查詢示例、架構及處理過程的描述。

3.1 ODQ查詢示例

在ODQ設計中，定義了抽象的文檔模型，將文檔分為多個對象，對應于不同的文檔功能點，對流式文檔功能點的訪問，都可看為是對這些對象及屬性的操作。ODQ基本語法主要包括操作命令、操作對象和關鍵字。操作命令包括查詢文檔內容（GET）、刪除對象（DELETE）、插入對象（INSERT）、更新對象（UPDATE SET）、統(tǒng)計對象（COUNT）等，前4種命令作為基本操作命令，COUNT作為統(tǒng)計命令，區(qū)分出對流式文檔功能點的查詢、刪除、修改和統(tǒng)計操作；操作對象分為節(jié)（Section）、段落（Paragraph）、圖片（Picture）、列表（list）、表格（table）等可直接訪問的文檔功能點；操作命令和操作對象通過關鍵字WHERE、FROM、of、AS、ALL、with、after、before等聯(lián)系起來，并結合基本表達式運算符＠、＝、括號、＆＆、｜等，共同構成了基本的ODQ語法。基本命令表達如下所示:

（1）查詢獲取命令GET

GET［＠屬性1，［＠屬性2］…｜式樣1，［式樣2］…of］對象［all｜序號｜范圍］

FROM Url/Document［of對象［all｜序號｜范圍］］…