專利名稱：：處理使用標記語言的文檔的裝置的制作方法
技術領域：
：本發(fā)明涉及一種文檔處理技術，尤其涉及處理以標記語言描述的文檔的技術。
背景技術：
：互聯(lián)網(wǎng)的出現(xiàn)導致由用戶處理和管理的文檔的數(shù)目近乎指數(shù)增長。形成互聯(lián)網(wǎng)核心的萬維網(wǎng)聯(lián)合會(亦即通常所說的Web)包括由這些文檔構成的大規(guī)模數(shù)據(jù)中心庫。除了文檔，Web還提供用于這些文檔的信息檢索系統(tǒng)。這些文檔通常為標記語言格式，一種簡單且常用的標記語言是超文本標記語言(HTML)。這種文檔還包括指向可能位于該Web其它部分中的其它文檔的鏈接。可擴展標記語言(XML)是另一種更高級、更常用的標記語言。用于經(jīng)由Web來訪問和查看該文檔的簡單瀏覽器用面向對象的編程語言(例如Java)來開發(fā)。以標記語言為格式的文檔通常在瀏覽器和其它應用程序中表述為樹型數(shù)據(jù)結構的格式。這種表述與文檔的語法分析樹相對應。文檔對象模型(DOM)是一種眾所周知的用于表述和操作文檔的基于樹的數(shù)據(jù)結構模型。文檔對象模型提供了用于表述文檔的標準對象集合，包括HTML和XML文檔。DOM包括兩個基本組件，即，如何將表述文檔中組件的對象進行組合的標準模型，以及用于訪問和操作它們的標準接口。應用程序開發(fā)者能夠支持DOM作為其自身的特定數(shù)據(jù)結構的接口和應用程序接口(API)。另一方面，創(chuàng)建文檔的應用程序開發(fā)者可使用標準DOM接口而不是使用其自身API的特定接口。因此，由于這種能夠提供標準的能力，DOM能有效地增加各種環(huán)境中、尤其是Web上的文檔的互操作性。已經(jīng)定義了DOM的幾種變化，由不同的編程環(huán)境和應用程序來使用。DOM樹是基于相應的DOM的內(nèi)容對文檔的分級表述。DOM樹包括“根”以及從根產(chǎn)生的一個或多個“節(jié)點”。在某些情況下，根表述整個文檔。中間節(jié)點可表述元素，諸如表及表中的行和列。DOM樹的“葉子”通常表述數(shù)據(jù)，例如不可進一步分解的文本項目或圖像。DOM樹中的各個節(jié)點可與屬性相關聯(lián)，屬性描述了由節(jié)點表述的元素的參數(shù)，例如字體、大小、顏色、縮進等。雖然HTML是一種創(chuàng)建文檔的常用語言，但它是格式和版式語言。HTML不是一種數(shù)據(jù)描述語言。表述HTML文檔的DOM樹的節(jié)點包括與HTML格式標簽相對應的預先定義的元素。由于HTML通常不提供任何數(shù)據(jù)描述，也不提供任何對數(shù)據(jù)的標簽/標注，因此，常常難以對HTML文檔中的數(shù)據(jù)進行查詢。網(wǎng)絡設計者的目標是使得Web文檔能夠被軟件應用程序查詢或處理。獨立顯示的分級組織的語言能夠通過這種方式查詢和處理。諸如XML(可擴展標記語言)的標記語言能夠提供這些特征。與HTML相反，眾所周知，XML的優(yōu)點是使得文檔設計者能夠使用可自由定義的“標簽”來對數(shù)據(jù)元素進行標注。上述數(shù)據(jù)元素可進行分級組織。另外，XML文檔可包含文檔類型定義(DTD)，它是對文檔中所使用的“語法”(標簽及其相互關系)的描述。使用CSS(層疊樣式表)或XSL(XML樣式語言)，以定義結構化的XML文檔的顯示方法。與DOM、HTML、XML、CSS、XSL有關的其它信息以及相關語言特征也可從Web獲取，例如，http://www.w3.org/TR/。Xpath提供了用于對XML文檔的部分進行尋址的公共的語法和語義。Xpath的功能的一個示例是對與XML文檔相對應的DOM樹進行遍歷。它提供了用于操作與XML文檔的各種表述相關聯(lián)的字符串、數(shù)字和布爾字符的基本工具。Xpath對XML文檔的摘要、邏輯結構(例如，DOM樹)、而不是其表面語法(例如，描述哪根線或哪個字符位于序列中的語法)進行操作。使用Xpath，能夠在分級結構中(例如，在XML文檔的DOM樹中)進行定位。除了用于尋址的用途之外，Xpath還被設計用來測試DOM樹中的節(jié)點是否與某個模式相匹配。其它涉及Xpath的細節(jié)可在http://www.w3.org/TR/中找到。假設XML的有益效果和特征已經(jīng)公知，需要一種能夠對標記語言(例如，XML)構建的文檔進行處理的有效的文檔處理和管理系統(tǒng)，并提供一種用于創(chuàng)建和修改這些文檔的友好的用戶界面?？蓴U展標記語言(XML)特別適合作為用于復合文檔(compounddocument)的格式，或者特別適合用于這種情況的格式，即，某個文檔的相關數(shù)據(jù)與其它文檔的數(shù)據(jù)通過網(wǎng)絡等共用的情況。已經(jīng)開發(fā)出許多用于創(chuàng)建、顯示和編輯XML文檔的應用程序(例如，參見日本已公開的專利申請No.2001-290804)?？呻S意地定義詞匯。因此理論上，可能存在無限多個詞匯。然而，不可能單獨提供這些詞匯專用的顯示/編輯環(huán)境。在相關技術中，如果以不具有專用編輯環(huán)境的詞匯來描述文檔，那么由文本數(shù)據(jù)構成的文檔的源代碼(source)可直接使用文本編輯器等進行編輯。能夠處理XML文檔的現(xiàn)有的應用程序在市場上能夠獲得，但是它們具有顯著的局限性，并且遇到了妨礙其被廣泛接受的障礙。本文描述的方法和裝置解決了迄今為止還未被上述現(xiàn)有產(chǎn)品及其所代表的現(xiàn)有技術所解決的問題。例如，在現(xiàn)有的XML文檔處理裝置的實現(xiàn)中，作為一種內(nèi)容表達的XML文檔與其顯示方法無關的這一特征可能在表面上被視為一種優(yōu)勢。然而，上述特征實際上是不利的，這是因為用戶不能直接對其進行編輯。為了解決這一問題，現(xiàn)有的XML文檔處理產(chǎn)品特別設計了用于XML輸入的屏幕。但是，由于現(xiàn)有XML產(chǎn)品必須預先進行硬編碼(hardcode)，因此限制了屏幕設計的靈活性。由于這一局限性，XSLT在之前作為樣式表語言的標準之一被開發(fā)。這是一種能夠將用戶從硬編碼工作中釋放出來的技術，并且與顯示XML文檔的可應用方法相兼容。然而，XSLT不能夠僅通過顯示XML文檔實現(xiàn)對該XML文檔的編輯。此外，現(xiàn)有XML產(chǎn)品主要依賴于“架構(schema)”的設置。因此，只要確定了架構，便具有這樣的局限性，即，僅能處理與來自頂層的架構結構相對應的XML文檔。換言之，該系統(tǒng)是一種硬性(rigid)系統(tǒng)。
發(fā)明內(nèi)容整個XML文檔的結構不需要硬性確定。通過將具有各種結構的復合XML文檔分為多個部分，并將該文檔分配到優(yōu)選地用插件表示的編輯模塊，能夠安全處理該復合XML文檔，從而能夠獲得靈活的系統(tǒng)。此外，不受硬編碼限制，用戶能夠實現(xiàn)靈活的屏幕設計，并利用WYSIWYG(所見即所得)對所實現(xiàn)的屏幕進行編輯。本發(fā)明針對上述情況而提出，并相應提供能夠有效地對以一種或多種例如XML類型語言的標記語言來描述的文檔進行處理的方法和裝置。本發(fā)明的一些示例性實施方案涉及文檔處理裝置，例如這樣的文檔處理裝置，其包括多個處理單元，多個處理單元的每一個處理以特定標簽集描述的共用文檔，并適于通過與各個標簽集相對應的處理單元在共用顯示媒介(例如共用顯示屏幕)上對以多種類型的標簽集描述的文檔進行顯示，以接受用戶對文檔的編輯。本發(fā)明還涉及一種文檔處理方法，尤其是這樣一種文檔處理方法，其通過與各標簽集相對應的處理單元在共用顯示媒介(例如共用顯示屏幕)上對采用多種類型的標簽集描述的文檔進行顯示，以接受用戶對文檔的編輯。這里應該注意，在方法、裝置、系統(tǒng)等之間改變的上述結構組件和表達式的任意組合對于本發(fā)明的實施方案都是有效的。根據(jù)本發(fā)明，能夠提供用于有效地處理以一種或多種標記語言描述的文檔的技術，以用于實現(xiàn)生成、編輯、顯示和/或存儲操作中的至少一種或多種。圖1以方框圖的方式示出了根據(jù)本發(fā)明的一個示例性而非限制性實施方案的文檔處理裝置；圖2示出了XML文檔的一個實施例；圖3示出了將圖2的XML文檔映射為HTML描述的表的一個實施例；圖4示出了用以將圖2的XML文檔映射為圖3的表的定義文件的一個實施例；圖5示出了當利用圖3的對應關系將圖2的XML文檔映射為HML時顯示屏的一個實施例；圖6示出了可與本發(fā)明一起使用的圖形用戶界面；圖7示出了根據(jù)本發(fā)明生成的屏幕布局(layout)的另一實施例；圖8示出了根據(jù)本發(fā)明的、用于XML文檔的編輯屏幕；圖9示出了根據(jù)本發(fā)明編輯的XML文檔的另一實施例；圖10示出了可與本發(fā)明一起使用的編輯屏幕；圖11(a)示出了能夠作為所公開的文檔處理和管理系統(tǒng)的一個示例性實現(xiàn)基礎的組件的傳統(tǒng)結構；圖11(b)和11(c)是示例性的文檔處理和管理系統(tǒng)的總體方框圖；圖12示出了文檔管理器的示例性實現(xiàn)的進一步細節(jié)；圖13示出了詞匯連接子系統(tǒng)300的示例性實現(xiàn)的進一步細節(jié)；圖14(a)示出了程序調用器的示例性實現(xiàn)及其與其它組件的關系的進一步細節(jié)；圖14(b)示出了服務代理(broker)的示例性實現(xiàn)及其與其它組件的關系的進一步細節(jié)；圖14(c)示出了服務的示例性實現(xiàn)的進一步細節(jié)；圖14(d)示出了服務的實施例；圖14(e)示出了程序調用器與用戶應用程序之間的關系的進一步細節(jié)；圖15(a)提供了載入程序調用器上的應用程序服務的結構的進一步細節(jié)；圖15(b)示出了框架、菜單欄和狀態(tài)欄之間的關系的實施例；圖16(a)示出了應用程序核心的示例性實現(xiàn)的進一步細節(jié)；圖16(b)示出了涉及快照(snapshot)的示例性實現(xiàn)的進一步細節(jié)；圖17(a)示出了涉及文檔管理器的示例性實現(xiàn)的進一步細節(jié)；圖17(b)在右側示出了一組文檔A-E如何排列為分級結構的實施例，在左側示出了右側所示的文檔的分級結構在屏幕上如何顯示的實施例；圖18(a)和18(b)提供了撤消框架和撤消命令的示例性實現(xiàn)的進一步細節(jié)；圖19(a)示出了文檔如何載入如圖11(b)-(c)所示的文檔處理和管理系統(tǒng)中的總體圖；圖19(b)示出了使用MVC范例的區(qū)的結構的概要；圖20示出了根據(jù)本發(fā)明的文檔及其多種表述的實施例；圖21(a)示出了如圖20所示的文檔的XHTML組件的MV關系的簡化視圖；圖21(b)示出了用于如圖21(a)所示的文檔的詞匯連接；圖22(a)-22(c)示出了分別涉及插件子系統(tǒng)、詞匯連接與連接器的示例性實現(xiàn)的進一步細節(jié)；圖23示出了用于文件MySampleXML的使用詞匯連接管理器的VCD腳本和連接器工廠樹的實施例；圖24(a)-(c)示出了將示例文檔MySampleXML載入圖11(b)的示例性文檔處理和管理系統(tǒng)中的步驟0-3；圖25示出了將示例文檔MySampleXML載入圖11(b)的示例性文檔處理和管理系統(tǒng)中的步驟4；圖26示出了將示例文檔MySampleXML載入圖11(b)的示例性文檔處理和管理系統(tǒng)中的步驟5；圖27示出了將示例文檔MySampleXML載入圖11(b)的示例性文檔處理和管理系統(tǒng)中的步驟6；圖28示出了將示例文檔MySampleXML載入圖11(b)的示例性文檔處理和管理系統(tǒng)中的步驟7；圖29(a)示出了在不具有相應的源節(jié)點而僅依賴于目的樹的節(jié)點上發(fā)生的事件流；圖29(b)示出了在通過TextOfConnector與源節(jié)點相關的目的樹的節(jié)點上發(fā)生的事件流。具體實施例方式圖1示出了根據(jù)本發(fā)明的一個示例性而非限制性實施方案的文檔處理裝置20的結構。文檔處理裝置20對結構化的文檔進行處理，該文檔中的數(shù)據(jù)被分為具有分級結構的多個組件。該實施方案中表示的是一個實施例，其中，對作為一種結構化文檔的XML文檔進行處理。文檔處理裝置20由主控單元22、編輯單元24、DOM(文檔對象模塊)單元30、CSS(層疊樣式表)單元40、HTML(超文本標記語言)單元50、SVG(可縮放矢量圖形)單元60以及用作轉換單元一個示例的VC(詞匯連接)單元80。在硬件組件方面，這些單元結構可由任意的傳統(tǒng)處理系統(tǒng)或設備(包括任意計算機的CPU或存儲器、存儲器載入的程序、硬連線芯片等)來實現(xiàn)。因此，如本領域技術人員能夠理解的那樣，本文以示例性結構的方式描繪和記述了功能模塊，所述結構實現(xiàn)為或可實現(xiàn)為任意的上述處理系統(tǒng)。因此，本領域技術人員能夠理解，這些功能模塊可僅通過硬件的方式、僅通過軟件的方式或通過二者相結合的方式以多種形式來實現(xiàn)。主控單元22提供插件的載入或提供執(zhí)行命令的框架。編輯單元24提供了用于編輯XML文檔的框架。文檔處理裝置20中的文檔的顯示和編輯功能是通過插件來實現(xiàn)的，而必要的插件是根據(jù)所處理的文檔類型、通過主控單元20或編輯單元24來載入的。主控單元22或編輯單元24通過參考待處理的文檔的命名空間來確定哪個或哪些詞匯描述了待處理的XML文檔的內(nèi)容，并且對應于所確定的詞匯而載入用于顯示和編輯的插件，從而執(zhí)行顯示和編輯。例如，利用控制單元52、編輯單元54和顯示單元56對HTML文檔進行顯示和編輯的HTML單元50，以及利用控制單元62、編輯單元64和顯示單元66對SVG文檔進行顯示和編輯的SVG單元60在文檔處理裝置20中被實現(xiàn)為處理單元。也就是說，對于各個詞匯(標簽集)，將顯示系統(tǒng)和編輯系統(tǒng)實現(xiàn)為插件，以使得在對HTML文檔和SVG文檔進行編輯時，分別將HTML單元50和SVG單元60與其各自的控制單元進行協(xié)同載入。如以下將描述的那樣，在要對既包括HTML又包括SVG組件的復合文檔進行處理時，既載入HTML單元50又載入SVG單元60。通過實現(xiàn)以上結構，用戶能夠僅選擇必要的功能以安裝該功能，如果需要，也能夠在稍后階段增加或刪除一個和多個功能。因此，能夠有效利用記錄媒介的存儲區(qū)域(例如硬盤)，并能夠避免在執(zhí)行程序的時候存儲器使用的浪費。此外，由于這一結構有利于性能擴展，因此開發(fā)者自己能夠以插件的形式處理新的詞匯，因而能夠促進開發(fā)過程。因此，用戶也能夠通過增加一個或多個插件而以較低成本輕易地增加一個或多個功能。編輯單元24通過接口從用戶處接收(包括但不限于)輸入動作(例如鼠標點擊或鍵盤敲打)、編輯指令的事件(觸發(fā)事件)，將事件通知適當?shù)牟寮⒖刂铺幚?，所述處理可包括重新?zhí)行事件的重做(redo)處理以及取消事件的撤消(undo)處理。DOM單元30包括DOM提供器32、DOM構造器34以及DOM編寫器36。DOM單元30實現(xiàn)了與文檔對象模型(DOM)相符的功能，在XML文檔作為數(shù)據(jù)被處理時，所述文檔對象模型被定義以提供訪問方法。DOM提供器32是滿足由編輯單元24定義的接口的DOM的實現(xiàn)。DOM構造器34從XML文檔生成DOM樹。如以下將描述的那樣，當通過VC單元80將待處理的XML文檔映射為其它詞匯時，生成與映射源中的XML文檔相對應的源樹以及與映射目的中的XML文檔相對應的目的樹。在編輯的末尾，例如DOM編寫器36輸出作為XML文檔的DOM樹。CSS單元40提供與CSS相符的顯示功能，并包括CSS分析器42、CSS提供器44以及呈現(xiàn)單元46。CSS分析器42具有用于分析CSS語法的分析功能。CSS提供器44是CSS對象的實現(xiàn)，并執(zhí)行對DOM樹的CSS層疊處理。呈現(xiàn)單元46是CSS的呈現(xiàn)引擎，并用來顯示以諸如HTML的詞匯描述的、利用CSS設置的文檔。HTML單元50對以HTML描述的文檔進行顯示或編輯。SVG單元60對以SVG描述的文檔進行顯示或編輯。這些顯示/編輯系統(tǒng)以插件的形式實現(xiàn)，各個系統(tǒng)包括對文檔進行顯示的顯示單元(本發(fā)明中也稱作“畫布(canvas)”)、發(fā)送和接收包括編輯命令的事件的控制單元(本發(fā)明中也稱作“editlet”)以及在接收到編輯命令時對DOM進行編輯的編輯單元(本發(fā)明中也稱作“區(qū)(zone)”)。在控制單元從外部源接收到用于DOM樹的編輯命令時，編輯單元修改DOM樹，而顯示單元更新顯示。這些單元具有與被稱作MVC(Model-View-Controllers，模型-視圖-控制器)的框架相類似的結構，MVC是一種眾所周知的圖形用戶界面(GUI)范例。所述MVC范例提供了一種將應用程序(或甚至是一個應用程序的接口)分解為三部分(即，模型、視圖和控制器)的方法。最初開發(fā)MVC是為了將傳統(tǒng)的輸入、處理和輸出任務映射到GUI領域。輸入->處理->輸出控制器->模型->視圖根據(jù)所述MVC范例，用戶輸入、外界建模、以及對用戶的視覺反饋被分離，并通過模型(M)、視窗(V)以及控制器(C)對象來處理?？刂破骺刹僮饕越忉屳斎?例如用戶的鼠標和鍵盤輸入)，并將這些用戶動作映射為發(fā)送至模型和/或視窗的命令，以實現(xiàn)適當?shù)母淖?。模型可操作以管理一個或多個數(shù)據(jù)元素、響應對其狀態(tài)的詢問、并響應指令以改變狀態(tài)。視窗可操作以管理顯示的矩形區(qū)域，并負責通過圖形和文本的組合將數(shù)據(jù)顯現(xiàn)給用戶。通常，根據(jù)本文所公開的本發(fā)明的示例性實施方案，顯示單元(V)對應于“視圖”，控制單元(C)對應于“控制器”，而編輯單元和DOM實體(M)對應于“模型”。在圖1-10所示的示例性實施方案的文檔處理裝置20中，不僅能夠以樹型視圖顯示格式來編輯XML文檔，而且能夠根據(jù)相應的詞匯來完成編輯。例如，HTML單元50提供了用戶界面，通過該用戶界面能夠以一種類似于word處理器的方法對HTML文檔進行編輯，而SVG單元60提供了一種用戶界面，通過該用戶界面能夠以一種類似于圖像繪制工具的方法對SVG文檔進行編輯。VC單元80包括映射單元82、定義文件獲取單元84以及定義文件生成單元86。通過將以某個詞匯描述的文檔映射為另一詞匯，VC單元80提供了一種框架，以通過與被映射成的詞匯相對應的顯示和編輯插件來顯示或編輯文檔。在本實施方案中，該功能被稱為詞匯連接(VC)。在VC單元80中，定義文件獲取單元84獲取描述了映射定義的定義文件。在該實施方案中，定義文件為腳本文件。以第一詞匯描述的文檔被表述為具有節(jié)點的源樹。同樣地，以第二詞匯描述的文檔被表述為具有節(jié)點的目的樹。定義文件為各節(jié)點描述了源樹與目的樹的節(jié)點之間的連接。如W3C領域中所公知的那樣，可根據(jù)元素值和/或屬性值來定義DOM樹中的節(jié)點。在該實施方案中，可規(guī)定各節(jié)點的元素值或屬性值是否可以編輯。此外，在該實施方案中，也可描述使用節(jié)點的元素值或屬性值的運算表達式。這些功能將在稍后進行描述。映射單元82使得DOM構個造器34通過參考定義文件獲取單元84已經(jīng)獲取的定義文件(腳本文件)來生成目的樹，以使得映射單元82能夠管理源樹與目的樹之間的對應關系。定義文件生成單元86為用戶提供圖形用戶界面，以生成定義文件。VC單元80對源樹與目的樹之間的連接進行監(jiān)控。當VC單元80通過由負責顯示的插件提供的用戶接口從用戶處接收編輯指令時，它首先修改源樹的相關節(jié)點。因此，DOM單元30將發(fā)出指示源樹已經(jīng)被修改的變化事件。然后，VC單元80接收該變化事件，并對應于被修改的節(jié)點而修改目的樹的節(jié)點，以使得目的樹與源樹的修改同步。當為顯示/編輯目的樹提供必要的處理的插件(例如HTML單元50)接收了指示目的樹已經(jīng)被修改的變化事件時，該插件通過參考被修改的目的樹而對顯示進行更新。通過執(zhí)行將詞匯轉換為另一主要詞匯的上述結構，即使是以少數(shù)用戶使用的局部詞匯來描述文檔，也能夠正確顯示文檔，并能夠相應地提供理想的編輯環(huán)境。文檔處理裝置20顯示和/或編輯文檔的操作將在下文中描述。當文檔處理裝置20載入待處理的文檔時，DOM構造器34從XML文檔生成DOM樹。主控單元22或編輯單元24通過參考待處理的XML文檔的命名空間來確定哪個詞匯描述XML文檔。如果與詞匯相對應的插件安裝在文檔處理裝置20中，則該插件被載入以顯示/編輯文檔。另一方面，如果插件并未安裝其中，則進行檢查以查看是否存在定義文件。如果存在定義文件，則定義文件獲取單元84獲取該定義文件，并根據(jù)定義生成目的樹，以使得能夠通過與被映射成的詞匯相對應的插件來顯示/編輯文檔。如果該文檔是包含多個詞匯的復合文檔，則通過與各詞匯相對應的插件來顯示/編輯該文檔的相關部分，以下將詳細描述。如果不存在定義文件，則顯示文檔的源或樹型結構，并在顯示屏中進行編輯。圖2示出了待處理的XML文檔的一個實施例。根據(jù)該示例性表示，XML文檔用于管理與學生已獲得的評分或分數(shù)(marks)相關的數(shù)據(jù)。作為XML文檔的上部節(jié)點的組件“marks”包括在“marks”下方為各個學生設置的多個組件“student”。組件“student”具有屬性“name”，并包括作為子元素的學科“Japanese”、“Math”(數(shù)學)、“Science”以及“Social”(社會科學)。屬性“name”存儲學生的姓名。組件“Japanese”、“Math”、“Science”和“Social”存儲分別為日語、數(shù)學、自然科學和社會科學的學科的測試成績。例如，姓名為“A”的學生的分數(shù)是日語為“90”、數(shù)學為“50”、自然科學為“75”以及社會科學為“60”。下文中，該文檔中使用的詞匯(標簽集)被稱作“分數(shù)管理詞匯”。由于根據(jù)本示例性實施方案的文檔處理裝置20不具有與分數(shù)管理詞匯的顯示和/或編輯相符或能夠處理分數(shù)管理詞匯的顯示和/或編輯的插件，因此，將使用以上描述的VC單元80，以不使用源顯示和樹顯示的其它顯示方法來顯示該文檔。也就是說，通過準備定義文件，使得分數(shù)管理詞匯可映射為已具有插件的另一詞匯，例如HTML或SVG。下面將要進行的說明是在假設已經(jīng)具備了定義文件的情況下進行的，不過對于用戶本身用以創(chuàng)建定義文件所必需的用戶界面將在后面描述。圖3示出了圖2中所示的XML文檔映射為以HTML描述的表的一個實施例。在圖3所示的實施例中，以分數(shù)管理詞匯描述的“student”節(jié)點與以HTML描述的表(“TABLE”節(jié)點)的行(“TR”節(jié)點)相關。各行的第一列與屬性值“name”相對應，第二列與“Japanese”節(jié)點的元素值相對應，第三列與“Math”節(jié)點的元素值相對應，第四列與“Science”節(jié)點的元素值相對應，而第五列與“Social”節(jié)點的元素值相對應。因此，圖2所示的XML文檔能以HTML的列表格式來顯示。此外，這些屬性值和元素值被指定為能夠編輯，以使得用戶能夠使用HTML單元50的編輯功能在顯示屏上對這些值進行編輯。在第六列中，指定了用來計算日語、數(shù)學、自然科學以及社會科學的分數(shù)的加權平均的運算表達式，并顯示每個學生的分數(shù)的平均值。以這種方式，通過在定義文件中指定運算表達式來完成更靈活的顯示，從而提高用戶在進行編輯時的便利性。在圖3所示的實施例中，將對第六列的編輯指定為不允許，以使得不能單獨對平均值本身進行編輯。因此，在映射定義中，能夠指定可編輯或不能編輯，以避免用戶可能的錯誤操作。圖4表示定義文件的一個實施例，以將圖2所示的XML文檔映射為圖3所示的表。該定義文件通過被定義用于和定義文件一起使用的腳本語言來描述。在圖4所示的實施例中，“addstudent”和“deletestudent”被定義為命令，并分別涉及將節(jié)點“student”插入源樹中的操作以及將節(jié)點“student”從源樹中刪除的操作。模板描述了諸如“name”和“Japanese”的標題顯示于表的第一行中，而節(jié)點“student”的內(nèi)容顯示于第二行及其隨后的行中。在顯示節(jié)點“student”內(nèi)容的模板中，包含“text-of”的項表示允許進行編輯，而包含“value-of”的項表示不允許進行編輯。在這些顯示了節(jié)點“student”內(nèi)容的行中，在第六行中描述了運算表達式“(src:japanese+src:math+scr:science+scr:social)div4”。這意味著顯示學生的分數(shù)的平均值。圖5示出了將圖2所示的由分數(shù)管理詞匯描述的XML文檔利用圖3所示的對應關系映射為HTML以使其顯示在顯示屏上時，顯示屏的一個實施例。在表90各行中從左至右顯示的是各學生的姓名，以及日語分數(shù)、數(shù)學分數(shù)、自然科學分數(shù)、社會科學分數(shù)及其平均值。用戶能夠在屏幕上對XML文檔進行編輯。例如，當?shù)诙械谌兄械闹底優(yōu)椤?0”時，源樹中與該節(jié)點相對應的元素值(亦即學生“B”的數(shù)學分數(shù))變?yōu)椤?0”。此時，為了使目的樹與源樹一致，目的樹的相應部分因此而改變，從而使得HTML單元50能夠根據(jù)改變的目的樹來對顯示進行更新。因此，學生“B”的數(shù)學分數(shù)變?yōu)椤?0”，而平均值相應地變?yōu)椤?5”。在圖5所示的屏幕上，例如“addstudent”和“deletestudent”的命令被顯示為菜單，如圖4所示的定義文件中所定義的那樣。當用戶從這些命令中選擇一個命令時，節(jié)點“student”增加至源樹中或從源樹中刪除。以這種方式，利用根據(jù)本實施方案的文檔處理裝置20，不僅能夠對分級結構下端中的組件的元素值進行編輯，而且能夠對該分級結構進行編輯。具有上述樹型結構的編輯功能能夠以命令的形式顯現(xiàn)給用戶。此外，增加或刪除表中的行的命令可例如與增加或刪除節(jié)點“student”的操作相關。嵌入其它詞匯中的命令可顯現(xiàn)給用戶。該表可用作輸入模板，以使得對于新學生的分數(shù)數(shù)據(jù)能夠以填空(fill-in-the-blank)的方式來增加。如上所述，在使用HTML單元50的顯示/編輯功能的同時，以分數(shù)管理詞匯描述的文檔可通過VC功能來編輯。圖6示出了由定義文件生成單元86顯現(xiàn)給用戶的圖形用戶界面的一個實施例，以使用戶能夠生成定義文件。待映射的XML文檔在屏幕的左側區(qū)域91顯示為樹。被映射成的XML文檔的屏幕布局顯示在屏幕的右側區(qū)域92中。該屏幕布局可通過HTML單元50來編輯，用戶在屏幕的右側區(qū)域92中確定并創(chuàng)建用于對文檔進行顯示的屏幕布局。例如，使用諸如鼠標等的指示設備將屏幕的左側區(qū)域91中顯示的XML文檔的待映射的節(jié)點拖動并放置到屏幕的左側區(qū)域91中的HTML屏幕布局中，以指定映射源處的節(jié)點與映射目的處的節(jié)點之間的連接。例如，當作為元素“student”的子元素的“math”被放置到HTML屏幕上的表90中第一行與第三行的交叉處時，第三列中的“math”節(jié)點與“TD”節(jié)點之間建立連接。各節(jié)點均被如此被指定為可編輯或者不可編輯。此外，可在顯示屏中嵌入運算表達式。當完成屏幕編輯時，定義文件生成單元86生成定義文件，其描述屏幕布局與節(jié)點之間的連接。已經(jīng)開發(fā)出了能夠處理主要詞匯(例如XHTML(可擴展超文本標記語言)、MathML(數(shù)學標記語言)以及SVG(可縮放矢量圖形))的瀏覽器或編輯器。但是，不可能開發(fā)出適于以自創(chuàng)詞匯描述的所有文檔(例如圖2中所示的文檔)的瀏覽器或編輯器。然而，如果如上所述創(chuàng)建了用于映射為其它詞匯的定義文件，那么以自創(chuàng)詞匯描述的文檔就能夠使用VC功能來顯示和/或編輯，而不需不斷開發(fā)新的瀏覽器或編輯器。圖7示出了由定義文件生成單元86生成的屏幕布局的另一實施例。在圖7所示的實施例中，在屏幕上產(chǎn)生表90和圓形圖92用于顯示以分數(shù)管理詞匯描述的XML文檔。圓形圖93以SVG描述。如以下將討論的那樣，根據(jù)本示例性實施方案的文檔處理裝置20能夠對在單個XML文檔內(nèi)以多個詞匯描述的復合文檔進行處理。這就是為什么以HTML描述的表90以及以SVG描述的圓形圖93能夠顯示在同一屏幕上的原因。圖8示出了用于由文檔處理裝置20處理的XML文檔的媒體顯示，在一個優(yōu)選但非限制性的實施方案中，其為編輯屏幕。在圖8所示的實施例中，單個屏幕被分割為多個區(qū)域，而待處理的XML文檔在各個區(qū)域以多種不同顯示格式顯示。該文檔的源在區(qū)域94中顯示，該文檔的樹結構在區(qū)域95中顯示，而圖5所示的、以HTML描述的表在區(qū)域96中顯示。該文檔在這些區(qū)域中的任意區(qū)域均可被編輯，當用戶對這些區(qū)域中的任意區(qū)域的內(nèi)容進行編輯時，源樹將被相應修改，從而負責各屏幕顯示的各插件對屏幕進行更新，以使得對源樹的上述修改有效。具體而言，負責顯示對應編輯屏幕的插件的顯示單元被預先注冊為變化事件的監(jiān)聽器，所述變化事件提供源樹中發(fā)生了改變的通知。當源樹被任意插件或VC單元80修改時，顯示編輯屏幕的所有顯示單元接收發(fā)出的一個或多個變化事件，并從而更新屏幕。此時，如果插件正在通過VC功能進行顯示，則VC單元80根據(jù)對源樹的修改來修改目的樹。之后，插件的顯示單元通過參考上述經(jīng)過修改的目的樹而對屏幕進行修改。例如，當通過專用插件來實現(xiàn)源顯示和樹型視圖顯示時，源顯示插件和樹顯示插件通過直接參考源樹而不是利用目的樹來實現(xiàn)它們的顯示。在這種情況下，當在屏幕的任何區(qū)域中完成編輯時，源顯示插件和樹顯示插件通過參考修改后的源樹來更新屏幕。同樣，負責顯示區(qū)域96的HTML單元50通過參考目的樹來更新屏幕，該目的樹已根據(jù)對源樹的修改而做了修改。源顯示和樹型視圖顯示也可通過使用VC功能而實現(xiàn)。也就是說，例如，如果HTML被用于源和樹型結構的布局，則XML文檔可映射為HTML以通過HTML單元50來顯示。在這種情況下，將生成具有源格式、樹格式、表格式的三個目的樹。如果在屏幕上的三個區(qū)域的任意一個中進行編輯，則VC單元80對源樹進行修改，并在之后分別對具有源格式、樹格式、表格式的三個目的樹進行修改。然后，HTML單元50通過參考三個目的樹來更新屏幕的三個區(qū)域。以這種方式，在單個屏幕上以多種顯示格式顯示文檔，從而提高了用戶的便利性。例如，用戶能夠利用表90或類似物來以視覺上易于理解的格式顯示和編輯文檔，同時通過源顯示或樹顯示來理解文檔的分級結構。在上述實施例中，單個屏幕被劃分為多個顯示格式，它們被同時顯示。但是，也可在單個屏幕上顯示單個顯示格式，從而可通過用戶指令來切換顯示格式。在這種情況下，主控單元22從用戶處接收用于切換顯示格式的請求，并隨后命令對應的插件進行顯示切換。圖9示出了由文檔處理裝置20編輯的XML文檔的另一實施例。在圖9所示的XML文檔中，XHTML文檔被嵌入SVG文檔的“foreignObject”標簽中，而該XHTML文檔包含以MathML描述的公式。在這種情況下，編輯單元24通過參考命名空間而將描繪任務分配或指派給適當?shù)娘@示系統(tǒng)。在圖9所示的實施例中，編輯單元24首先使SVG單元60描繪矩形，然后使HTML單元50描繪XHTML文檔。此外，編輯單元24使MathML單元(未示出)描繪公式。以這種方式，包含多個詞匯的復合文檔被適當?shù)仫@示。圖10示出了顯示結果。在對文檔進行編輯期間，可向用戶顯示編輯菜單。該菜單可對應于復合文檔的待編輯部分。因此，當用戶在顯示媒介上移動光標(或者托架(carriage))時，待顯示的菜單可根據(jù)光標的位置被切換。也就是說，當光標位于顯示SVG文檔的區(qū)域中時，顯現(xiàn)給用戶的菜單響應于SVG單元60或響應于由用于映射SVG文檔的定義文件所定義的命令。當光標位于顯示XHTML文檔的區(qū)域中時，顯現(xiàn)給用戶的菜單響應于HTML單元50或響應于由用于映射XHTML文檔的定義文件所定義的命令。因此，可根據(jù)編輯位置提供適當?shù)挠脩艚缑?。如果在復合文檔中不存在與詞匯相符的適當插件或映射定義，則以該詞匯描述的部分可以源或樹格式顯示。在傳統(tǒng)實踐中，當要打開在某個文檔中嵌有其它文檔的復合文檔時，如果沒有安裝能夠顯示該嵌入文檔的應用程序，則它們的內(nèi)容不能顯示。但是，根據(jù)本實施方案，由文本數(shù)據(jù)組成的XML文檔可顯示為源或樹格式，從而能夠確定其內(nèi)容。這是基于文本的XML文檔或類似文檔的一個特征。以基于文本的語言來描述的數(shù)據(jù)的另一個有益方面例如在于，在同一文檔中以其它詞匯描述的部分的數(shù)據(jù)可被該復合文檔中以某個詞匯描述的另一文檔所參考。此外，當在該文檔中進行搜索時，嵌入圖片(例如SVG)中的字符串也可作為被搜索的候選者。在以某個詞匯描述的文檔中，可使用屬于其它詞匯的標簽。雖然該XML文檔通常并不有效，但只要它結構良好(well-formed)，就可作為有效的XML文檔而被處理。在這種情況下，被插入的屬于其它詞匯的標簽可使用定義文件來進行映射。例如，可使用諸如“Important”和“MostImportant”的標簽以通過強調的方式來顯示這些標簽周圍的部分，或者可將這些標簽以重要性的順序來排序以進行相應顯示。當用戶在編輯顯示器(例如，如圖10所示的屏幕)上對文檔進行編輯時，負責對被編輯的部分進行處理的插件或VC單元80對源樹進行修改。能夠為源樹中的各個節(jié)點注冊對于變化事件的監(jiān)聽器。通常，與屬于各個節(jié)點的詞匯相符的插件的顯示單元或VC單元80被注冊為監(jiān)聽器。當源樹被修改時，DOM提供器32從被修改的節(jié)點向較高層次探索。如果存在注冊的監(jiān)聽器，則DOM提供器32向該監(jiān)聽器發(fā)出變化事件。例如，參考如圖9中所示的文檔，如果位于<html>節(jié)點下方的節(jié)點被修改，那么該變化事件被通報給被注冊為<html>節(jié)點的監(jiān)聽器的HTML單元50。在同一時刻，該變化事件被通報給被注冊為位于<html>節(jié)點上方的<svg>節(jié)點中的監(jiān)聽器的SVG單元60。此時，HTML單元50通過參考被修改的源樹而更新顯示。由于屬于SVG單元60的詞匯的節(jié)點本身并未被修改，因此SVG單元60可忽視該變化事件。根據(jù)編輯的內(nèi)容，由HTML單元50對顯示進行的修改可改變總體布局。在這種情況下，對于各插件的各個顯示區(qū)域的布局將由管理屏幕布局的組件(例如，負責顯示最高節(jié)點的插件)來更新。例如，當由HTML單元50顯示的區(qū)域較之以前變大時，HTML單元50首先描繪HTML單元50本身所負責的區(qū)域，然后確定顯示區(qū)域的大小。然后，顯示區(qū)域的大小被通報給管理屏幕布局的組件，以請求對布局進行更新。負責屏幕布局的組件一收到該通知便為各個插件重新布置顯示區(qū)域。因此，被編輯的部分的顯示被適當更新，且總體屏幕布局被更新。用以實現(xiàn)具有該先決條件技術的文檔處理裝置20的功能結構將在下面詳細描述。文檔處理和管理系統(tǒng)的一個示例性實現(xiàn)將在本文中參照圖11-29進行討論。圖11(a)示出了能夠作為具有本文隨后描述的類型的文檔處理和管理系統(tǒng)的基礎的組件的傳統(tǒng)裝置。裝置10包括具有CPU形式或微處理器形式的處理器11，處理器11通過通信路徑13(通常實現(xiàn)為總線)耦合至可為任何當前或將來能獲得的ROM和/或RAM存儲形式的存儲器12。用戶輸入14(例如鼠標、鍵盤、語音識別系統(tǒng)或類似設備)的I/O接口16以及顯示設備15(或其它用戶接口)也耦合至總線用于與處理器11和存儲器12通信。如本領域所公知的那樣，諸如打印機、通信調制解調器等的其它設備可耦合至該裝置。該裝置可為獨立設備或者具有將多個終端以及一個或多個服務器耦合在一起的聯(lián)網(wǎng)形式，或者以本領域公知的多種設置方式的其中之一。本發(fā)明并不受這些組件的結構、它們的集中式或分布式體系結構或者多種組件的通信方式的限制。另外，應該注意到，本文所討論的系統(tǒng)和示例性實現(xiàn)包括幾種具有多種功能的組件和子組件。應該注意到，這些組件和子組件可僅使用硬件、僅使用軟件以及使用硬件和軟件的組合來實現(xiàn)，以提供上述的多種功能。另外，硬件、軟件及其組合可使用通用計算裝置或使用專用硬件或使用通用計算裝置和專用硬件的組合來實現(xiàn)。因此，組件或子組件的結構包括運行特定軟件的通用/專用計算裝置，以提供該組件或子組件的功能。圖11(b)示出了一種示例性文檔處理和管理系統(tǒng)的總體方框圖。文檔在上述文檔處理和管理系統(tǒng)中被創(chuàng)建和編輯。這些文檔能夠以具有標記語言的特征的任何語言來表述(例如XML)。同樣，為方便起見，已經(jīng)創(chuàng)建了用于特定組件和子組件的術語和名稱。但是，這些不應被視作對本文公開的一般教導范圍造成了限制。所述文檔處理和管理系統(tǒng)可被視為具有兩個基本組件。一個組件是“執(zhí)行環(huán)境”101，它是處理和管理系統(tǒng)運行的環(huán)境。例如，執(zhí)行環(huán)境提供了協(xié)助系統(tǒng)以及用戶對文檔進行處理和管理的基本效用和功能。另一組件是“應用程序組件”102，它由在執(zhí)行環(huán)境中運行的應用程序構成。這些應用程序包括文檔本身及其各種表述。1.執(zhí)行環(huán)境執(zhí)行環(huán)境101的關鍵組件是程序調用器103。程序調用器103是被訪問以啟動文檔處理和管理系統(tǒng)的基本程序。例如，當用戶登錄并啟動文檔處理和管理系統(tǒng)時，程序調用器103被執(zhí)行。程序調用器103能夠(例如但并非限制)讀取并處理作為插件增加至文檔處理和管理系統(tǒng)的功能、啟動并運行應用程序、以及讀取與文檔相關的性質。當用戶希望發(fā)起計劃在執(zhí)行環(huán)境中運行的應用程序時，程序調用器103找到、發(fā)起然后執(zhí)行該應用程序。例如，當用戶希望對已經(jīng)載入到系統(tǒng)中的文檔進行編輯(它是執(zhí)行環(huán)境中的一種應用程序)時，程序調用器103首先找到該文檔，然后執(zhí)行用于載入和編輯該文檔所必需的功能。程序調用器103聯(lián)接至幾個組件，例如插件子系統(tǒng)104、命令子系統(tǒng)105以及資源模塊109。這些組件將隨后進行更詳細描述。1.a.插件子系統(tǒng)插件子系統(tǒng)104是向文檔處理和管理系統(tǒng)增加功能的一種高度靈活和有效的設備。插件子系統(tǒng)104也能夠被用來修改和去除文檔處理和管理系統(tǒng)中存在的功能。此外，可使用插件子系統(tǒng)增加或修改多種功能。例如，如之前所提以及隨后將詳細描述的那樣，插件子系統(tǒng)可用于增加功能“editlet”，其可操作以有助于在屏幕上呈現(xiàn)文檔。插件editlet也有助于對增加至系統(tǒng)的詞匯進行編輯。插件子系統(tǒng)104包括服務代理1041。服務代理1041管理增加至文檔處理和管理系統(tǒng)的插件，從而代理已增加至文檔處理和管理系統(tǒng)的服務。代表期望功能的單個功能以“服務”1042的形式被增加至系統(tǒng)。服務1042的可用類型包括但不限于應用程序服務、區(qū)工廠服務、editlet服務、命令工廠服務、連接xpath服務、CSS計算服務等。這些服務及其與系統(tǒng)其余部分的關系將隨后詳細描述，以更好地理解文檔處理和管理系統(tǒng)。插件和服務之間的關系是，插件是可包括一個或多個服務提供器的單元，各個服務提供器具有與之相關的一個或多個類別的服務。例如，使用具有適當軟件應用程序的單個插件，能將一個或多個服務增加至系統(tǒng)，從而向系統(tǒng)增加相應的功能。即使對于給定服務(例如editlet服務)，也可在各自的插件中提供處理單個或多個詞匯的能力。1.b.命令子系統(tǒng)命令子系統(tǒng)105被用來執(zhí)行與文檔的處理相關的命令形式的指令。用戶可通過執(zhí)行一系列指令而執(zhí)行對文檔的操作。例如，通過發(fā)出命令形式的指令，用戶在文檔管理系統(tǒng)中處理XML文檔，并編輯與該XML文檔相對應的XMLDOM樹。這些命令可利用鍵盤敲打、鼠標點擊或其它有效的用戶接口動作而輸入。有時，能夠通過命令來執(zhí)行一個以上的指令。在這種情況下，這些指令被封裝成單個命令并連續(xù)執(zhí)行。例如，用戶可能希望將錯誤詞語替換為正確詞語。在這種情況下，第一指令可用以在文檔中找尋錯誤詞語。第二指令可用以刪除該錯誤詞語。第三指令可用以輸入正確詞語。這三個指令可被封裝成單個命令。在某些示例中，命令可具有相關功能，例如，下面將要詳細討論的“撤消”功能。這些功能可隨后分配給用來創(chuàng)建對象的基類。命令子系統(tǒng)105的一個組件是命令調用器1051，命令調用器1051可操作為選擇性地提供并執(zhí)行命令。雖然圖11(b)中僅示出了一個命令調用器，但也可使用一個以上的命令調用器并同時執(zhí)行一個以上的命令。命令調用器1051維護執(zhí)行命令所需的功能和類。在操作中，要執(zhí)行的命令1052被置于隊列1053中。命令調用器創(chuàng)建連續(xù)執(zhí)行的命令線程。如果在命令調用器中沒有正在執(zhí)行的命令，則由命令調用器1051執(zhí)行待執(zhí)行的命令1052。如果命令調用器正在執(zhí)行命令，則新的命令被置于命令隊列1053的末尾。不過，對于各命令調用器1051而言，一次僅執(zhí)行一個命令。如果指定的命令執(zhí)行失敗，則命令調用器1051執(zhí)行命令異常。可由命令調用器1051執(zhí)行的命令的類型包括但不限于可撤消命令1054、異步命令1055以及詞匯連接命令1056?？沙废?054是那些如果用戶希望就能夠回退其效果的命令?？沙废畹氖纠秊榧羟小椭?、插入文本等。在操作中，當用戶突出文檔的一部分并向該部分應用剪切命令時，如果需要，通過使用可撤消命令，可使得被剪切的部分“恢復原樣(uncut)”。詞匯連接命令1056被載入詞匯連接描述符腳本文件中。詞匯連接命令1056是能夠由程序員定義的用戶指定命令。這些命令可以是更抽象命令的組合，例如，用于增加XML片段、刪除XML片段、設置屬性等。這些命令特別涉及對文檔進行編輯。異步命令1055是用于載入或保存由系統(tǒng)執(zhí)行的文檔的命令，異步命令1055與可撤消命令或VC命令異步地執(zhí)行。與可撤消命令不同，異步命令不能取消。1.c.資源資源109是向不同的類提供某些功能的對象。例如，串資源、圖標和設定鍵綁定是系統(tǒng)中使用的資源。2.應用程序組件應用程序組件102，即文檔處理系統(tǒng)的第二個主要特征，在執(zhí)行環(huán)境101中運行。概括而言，應用程序組件102包括實際文檔，實際文檔包括其在系統(tǒng)內(nèi)的多個邏輯和物理表述。應用程序組件102還包括系統(tǒng)的、用來管理文檔的組件。應用程序組件102進一步包括用戶應用程序106、應用程序核心108、用戶界面107以及核心組件110。2.a.用戶應用程序用戶應用程序106連同程序調用器103一起被載入到系統(tǒng)中。用戶應用程序106是將文檔、文檔的多種表述以及與文檔進行交互所需的用戶界面特征結合在一起的粘合劑(glue)。例如，用戶可能希望創(chuàng)建作為工程(project)一部分的一套文檔。載入這些文檔，創(chuàng)建用于文檔的適當表述，增加作為用戶應用程序106一部分的用戶界面功能。換言之，用戶應用程序106將文檔及其表述的各個方面結合在一起使得用戶能夠與形成工程一部分的文檔進行交互。一旦創(chuàng)建了用戶應用程序106，每當用戶希望與形成工程一部分的文檔進行交互時，用戶就能夠簡單地將用戶應用程序106載入到執(zhí)行環(huán)境中。2.b.核心組件核心組件110提供了在多個窗格之間共享文檔的一種方法。如將在隨后詳細討論的那樣，窗格表述DOM樹，并處理屏幕的物理布局。例如，物理屏幕包括在屏幕內(nèi)的多個窗格用于描述各條信息。實際上，由用戶在屏幕上查看的文檔可在一個或多個窗格中顯示。此外，兩個不同的文檔可以出現(xiàn)在屏幕上的兩個不同窗格中。屏幕的物理布局還可以具有樹型形式，如圖11(c)所示。因此，如果組件1083要作為窗格顯示在屏幕上，則該窗格可被實現(xiàn)為根窗格1084。作為一種選擇，它也可以是子窗格1085。根窗格1084是窗格樹根部的窗格，而子窗格1085是除了根窗格1084之外的任何窗格。核心組件110也提供字體，并充當用于文檔的多個功能性操作的源，例如，工具包(toolkit)。由核心組件110執(zhí)行的任務的一個示例是在多個窗格之間移動鼠標光標。被執(zhí)行的任務的另一個示例是標記一個窗格中的文檔的一部分，并將其復制到包含不同文檔的另一窗格上。2.c.應用程序核心如上所述，應用程序組件102由被系統(tǒng)處理和管理的文檔組成。應用程序組件102包括對于系統(tǒng)內(nèi)的文檔的多種邏輯和物理表述。應用程序核心108是應用程序組件102的組件。其功能是保持實際文檔及其內(nèi)的所有數(shù)據(jù)。應用程序核心108包括文檔管理器1081和文檔1082本身。文檔管理器1081的多個方面將在隨后更詳細描述。文檔管理器1081管理文檔1082。文檔管理器1081也連接至根窗格1084、子窗格1085、剪貼板實用程序1086以及快照實用程序1087。剪貼板實用程序1086提供了保持用戶決定增加至剪貼板的部分文檔的一種方法。例如，用戶可能希望剪切文檔的一部分，并將其保存到新的文檔上，用于稍后查看。在這種情況下，剪切的部分被增加至剪貼板1086?？煺?snapshot)實用程序1087也將在稍后描述，從而當應用程序從一個狀態(tài)變?yōu)榱硪粻顟B(tài)時，能夠記住應用程序的當前狀態(tài)。2.d.用戶界面應用程序102的另一組件是用戶界面107，其為用戶提供一種與系統(tǒng)進行物理交互的方式。例如，以物理接口1070來實現(xiàn)用戶界面時，用戶使用用戶界面上載、刪除、編輯和管理文檔。用戶界面107包括框架1071、菜單欄1072、狀態(tài)欄1073以及URL欄1074。如通常公知的那樣，框架可被視為顯示(例如物理屏幕)的活動區(qū)域。菜單欄1072是屏幕的、包括為用戶提供選項的菜單的區(qū)域。狀態(tài)欄1073是屏幕的、顯示應用程序的執(zhí)行狀態(tài)的區(qū)域。URL欄1074提供了輸入用于在互聯(lián)網(wǎng)上定位的URL地址的區(qū)域。3.文檔管理器和相關的數(shù)據(jù)結構圖12示出了文檔管理器1081的進一步細節(jié)。圖12包括被用來在文檔處理和管理系統(tǒng)內(nèi)表述文檔的數(shù)據(jù)結構和組件。為了更好的理解，在這部分描述的組件通過利用模型-視圖-控制器(MVC)表述范例來進行描述。文檔管理器1081包括文檔容器(containter)203，文檔容器203保持并容納文檔處理和管理系統(tǒng)中的所有文檔。聯(lián)接至文檔管理器1081的工具包201為文檔管理器1081的使用提供了各種工具。例如，“DOM服務”是由工具包201提供的能夠提供創(chuàng)建、維護和管理與文檔相對應的DOM所需的所有功能的工具。作為工具包201提供的另一工具的“IO管理器”分別管理向系統(tǒng)的輸入和來自系統(tǒng)的輸出。同樣地，“流處理器”是一種以比特流方式來處理文檔上載的工具。這些工具形成了工具包201的組件，不過并未在圖中明確示出或指定附圖標記。根據(jù)MVC范例表述，模型(M)包括文檔的DOM樹模型202。如上所述，所有文檔均在文檔處理和管理系統(tǒng)中被表述為DOM樹。文檔也形成文檔容器203的一部分。3.a.DOM模型和區(qū)表述文檔的DOM樹是具有節(jié)點2021的樹。作為DOM樹的子集的區(qū)209包括該DOM樹內(nèi)部的一個或多個所關注的節(jié)點。例如，僅文檔的一部分可在屏幕上顯現(xiàn)。文檔可見的這一部分可使用“區(qū)”209來表述。利用被稱作“區(qū)工廠”205的插件來創(chuàng)建、操作和處理區(qū)。雖然區(qū)表述DOM的一部分，但它也可使用一個以上的“命名空間”。如本領域中公知的那樣，命名空間是名稱的匯集或集合，這些名稱在該命名空間中是唯一。換言之，一個命名空間中不能夠出現(xiàn)兩個相同的名稱。3.b.“方面”(facet)及其與區(qū)的關系“方面”2022是MVC范例的模型(M)部分內(nèi)的另一組件。它被用來編輯區(qū)中的節(jié)點?！胺矫妗?022使用不會影響區(qū)本身的內(nèi)容的執(zhí)行過程來組織對于DOM的訪問。如以下將說明的那樣，這些過程執(zhí)行與節(jié)點相關的有意義且有用的操作。各個節(jié)點2021具有相應的2022。通過利用“方面”來執(zhí)行操作而不是直接對DOM中的節(jié)點進行操作，DOM的完整性得以確保。否則，如果直接對節(jié)點執(zhí)行操作，那么幾個插件可能同時對DOM進行改變，從而造成不一致性。盡管在每個詞匯或每個節(jié)點的基礎上提供了特定操作，并且這些操作優(yōu)選地提供為API，但是由W3C構建的DOM標準定義了用于對節(jié)點進行操作的標準接口。文檔處理/管理系統(tǒng)提供了這種作為“方面”的節(jié)點特定API，并將“方面”聯(lián)接至各個節(jié)點。這符合DOM標準，同時增加了有用的API。通過在已應用的標準DOM之上增加特定的API而不是為每個詞匯實現(xiàn)特定的DOM，可集中處理多種詞匯，并正確地處理其中具有詞匯任意組合的文檔。如上所述，“詞匯”是屬于命名空間的標簽(例如XML標簽)的集合。如上所述，命名空間具有唯一的名稱集(在該特定情況下為標簽集)。詞匯表現(xiàn)為表述XML文檔的DOM樹的子樹。這種子樹包括區(qū)。在特定實施例中，標簽集的邊界由區(qū)來限定。區(qū)209是利用被稱作“區(qū)工廠服務”205的服務而創(chuàng)建的。如上所述，區(qū)209是對表述文檔的DOM樹的僅僅一部分的內(nèi)部表述。為了提供對該文檔的上述部分的訪問，需要邏輯表述。這種邏輯表述通知計算機關于文檔如何在屏幕上進行邏輯顯示。如上所述，“畫布”(例如畫布210)是一種可操作為提供與區(qū)相對應的邏輯布局的服務。另一方面，窗格(例如窗格211)是與由畫布210提供的邏輯布局相對應的物理屏幕布局。實際上，用戶僅能看見以字符和圖片形式呈現(xiàn)在顯示屏上的文檔。因此，文檔必須通過用于在屏幕上描繪字符和圖片的處理來呈現(xiàn)在屏幕上。根據(jù)由窗格211提供的物理布局，文檔由畫布210呈現(xiàn)在屏幕上。與區(qū)209相對應的畫布210是利用“editlet服務”206來創(chuàng)建的。文檔的DOM是利用editlet服務206和畫布210來編輯的。為了維護原始文檔的完整性，editlet服務206和畫布服務210使用與區(qū)209中的一個或多個節(jié)點相對應的“方面”2022。這些服務并不直接操作區(qū)和DOM中的節(jié)點?！胺矫妗笔抢脕碜訫VC范例的(C)組件(即控制器)的命令207來操作的。用戶通常通過例如移動屏幕上的光標和/或鍵入命令而與屏幕進行交互。提供屏幕的邏輯布局的畫布2010接收這些光標操作。然后，畫布2010使得對“方面”采取相應的動作。給定這一關系，光標子系統(tǒng)204即作為用于文檔管理器1081的MVC范例的控制器(C)。畫布2010也具有處理事件的任務。例如，畫布2010處理諸如鼠標點擊、焦點移動和類似的用戶發(fā)起的動作等事件。3.c.區(qū)、“方面”、畫布和窗格之間的關系概述文檔管理和處理系統(tǒng)內(nèi)的文檔可從至少四個角度來觀察，即1)用來保持文檔管理系統(tǒng)中的文檔的內(nèi)容和結構的數(shù)據(jù)結構；2)不會影響文檔完整性就能編輯文檔內(nèi)容的方式；3)文檔在屏幕上的邏輯布局；以及4)文檔在屏幕上的物理布局。區(qū)、“方面”、畫布和窗格分別表述與上述四個方面相對應的文檔管理系統(tǒng)的組件。3.d.撤消系統(tǒng)如上所述，人們希望對文檔的任何改變(例如，編輯)應該是可撤消的。例如，用戶可執(zhí)行編輯操作，然后決定撤消該改變。參照圖12，撤消子系統(tǒng)212是文檔管理器的可撤消組件。撤消管理器2121保存可能被用戶撤消的、對文檔執(zhí)行的所有操作。例如，用戶可執(zhí)行命令來將文檔中的詞匯替換成另一個詞語。之后，該用戶可改變主意并決定保留原來的詞語。撤消子系統(tǒng)212利用可撤消編輯2122來協(xié)助上述操作。撤消管理器2121保存上述可撤消編輯2122的操作。該操作可擴展為超越單個XML操作類型，因此可能涉及文檔中多種語言(例如XHTML、SVG以及MathML)的變化特征，然后撤消對這些語言中每一個的改變。因此，在先進后出的操作中，不論詞匯使用與否，最近的改變首先被取消，然后，下一個最近的改變被取消。因此，即使兩個或更多editlet被編輯，但仍可依照正確順序執(zhí)行聯(lián)合撤消，從而提供正常和合乎邏輯的操作。3.e.光標子系統(tǒng)如上所述，MVC的控制器部分可包括光標子系統(tǒng)204。該光標子系統(tǒng)204從用戶處接收輸入。這些輸入通常具有命令和/或編輯操作的性質。因此，光標子系統(tǒng)204可被視作是與文檔管理器1081相關的MVC范例的控制器(C)部分。3.f.視圖如上所述，畫布2010表述要顯現(xiàn)在屏幕上的文檔的邏輯布局。對于XHTML文檔的特定實施例而言，畫布可包括盒樹(boxtree)208，盒樹208是文檔在屏幕上如何被查看的邏輯表述。上述盒樹208可包含在與文檔管理器1081有關的MVC范例的視圖(V)部分中。4.詞匯連接文檔處理管理系統(tǒng)的一個重要特征是，能夠以兩種不同的方式(例如，以兩種標記語言)來表述和顯示文檔，從而使得兩種不同的表述自動保持一致。標記語言文檔(例如XML文檔)基于通過文檔類型定義限定的詞匯創(chuàng)建。詞匯則是一組標簽集，并可以任意定義，這就使得詞匯的數(shù)量可能是無限的。但是，為多個可能的詞匯中的每一個都提供專用的單獨處理和管理環(huán)境是不切實際的。詞匯連接是解決這種問題的一種方式。例如，文檔可以利用兩種或更多標記語言來表述。這些文檔例如可以是XHTML(可擴展超文本標記語言)、SVG(可縮放矢量圖形)、MathML(數(shù)學標記語言)或其他的標記語言。換句話說，標記語言可以視為和XML中的詞匯和標簽集相同。詞匯可以使用詞匯插件來實現(xiàn)。在文檔處理和管理系統(tǒng)中，以插件不可用的詞匯所描述的文檔可以通過將該文檔映射為插件可用的另一詞匯來顯示。因此，以非插件的詞匯描述的文檔仍然是可以正確顯示的。詞匯連接包括獲取定義文件、在(隨后定義出的)定義文件之間進行映射、以及生成定義文件的能力。用某種詞匯描述的文檔能夠映射為另外的詞匯。因此，詞匯連接提供了通過與文檔已被映射成的詞匯相對應的顯示和編輯插件來顯示或編輯文檔的能力。應該認識到，各個文檔在文檔處理和管理系統(tǒng)中被描述為通常具有多個節(jié)點的DOM樹?！岸x文件”為各個節(jié)點描述了該節(jié)點與其他節(jié)點之間的連接。規(guī)定了是否可以對各個節(jié)點的元素值和屬性值進行編輯。還描述了使用節(jié)點的元素值和屬性值的運算表達式。利用映射特征，通過參考定義文件創(chuàng)建目的DOM樹。因此，源DOM樹和目的DOM樹之間的關系被建立并維護。詞匯連接監(jiān)控源DOM樹和目的DOM樹之間的連接。在從用戶接收到編輯指令后，詞匯連接修改源DOM樹中的相關節(jié)點。如上所述，發(fā)出表示已經(jīng)修改了源DOM樹的“變化事件”，并且相應地修改目的DOM樹。通過使用詞匯連接，僅對于少量用戶熟知的相對次要的詞匯可以被轉換為其他主要的詞匯。因此，即便是對于那些僅有少量用戶使用的次要詞匯，也可以準確地顯示文檔，并提供理想的編輯環(huán)境。因此，作為文檔管理系統(tǒng)一部分的詞匯連接子系統(tǒng)提供了能夠對文檔進行多種表述的功能。圖13顯示了詞匯連接(VC)子系統(tǒng)300。VC子系統(tǒng)300提供了一種維護同一文檔的兩種可替換表述之間的一致性的方式。在圖中具有與上面描述和標識相同的組件，這些組件相互連接從而實現(xiàn)上述目的。例如，兩種表述可以是同一文檔以兩種不同詞匯實現(xiàn)的可替換表述。如上所述，其中一種可以是源DOM樹，而另一種是目DOM樹。4.a.詞匯連接子系統(tǒng)利用被稱為“詞匯連接”301的插件在文檔處理和管理系統(tǒng)中實現(xiàn)詞匯連接子系統(tǒng)300的功能。將被表述的文檔的各詞匯305都需要相應的插件。例如，如果文檔的一部分以HTML表述，而其他部分以SVG表述，則需要相應的HTML詞匯插件和SVG詞匯插件。詞匯連接插件301為區(qū)209或窗格211創(chuàng)建與適當詞匯305的文檔相對應的適當?shù)脑~匯連接畫布310。使用詞匯連接301，利用轉換規(guī)則，對源DOM樹的區(qū)209的改變被轉換到另一DOM樹306的相應區(qū)。轉換規(guī)則以詞匯連接描述符(VCD)的形式給出。對于與源和目的DOM之間的這種轉換相對應的各個VCD文件，創(chuàng)建相應的詞匯連接管理器302。4.b.連接器連接器304連接源DOM樹中的源節(jié)點和目的DOM樹中的目的節(jié)點。連接器304可操作以觀察源DOM樹中的源節(jié)點，和與該源節(jié)點相對應的、對源文檔的修改(變化)。接著，連接器304修改相應的目的DOM樹中的節(jié)點。只有連接器304是能夠修改目的DOM樹的對象。例如，如果用戶僅能夠對源文檔和相應的源DOM樹進行修改，則連接器304對目的DOM樹進行相應的修改。連接器304被邏輯地鏈接在一起以形成樹結構，如圖13所示。連接器304形成的樹被稱為“連接器樹”。連接器304通過一種服務而創(chuàng)建，該服務被稱為“連接器工廠”303服務。連接器工廠303從源文檔創(chuàng)建連接器304，并將連接器304以連接器樹的形式鏈接起來。詞匯連接管理器302維護連接器工廠303。如上所述，詞匯是命名空間中的標簽集。如圖13所示，通過詞匯連接301為文檔創(chuàng)建詞匯305。這通過分析文檔文件以及為源DOM和目的DOM之間的轉換創(chuàng)建適當?shù)脑~匯連接管理器302來實現(xiàn)。此外，在創(chuàng)建連接器的連接器工廠303、創(chuàng)建區(qū)209的區(qū)工廠服務205和創(chuàng)建與區(qū)中的節(jié)點相對應的畫布的editlet服務206之間建立適當?shù)年P聯(lián)。當用戶從系統(tǒng)中除去或刪除文檔時，對應的詞匯連接管理器302被刪除。詞匯305接著創(chuàng)建詞匯連接畫布310。此外，連接器304和目的DOM樹306被相應地創(chuàng)建。應該理解，源DOM和畫布分別對應于模型(M)和視圖(V)。然而，僅當目標詞匯能夠在屏幕上呈現(xiàn)時，這種呈現(xiàn)才有意義。這種顯示通過詞匯插件來實現(xiàn)。詞匯插件提供用于主要的詞匯，例如XHTML、SVG和MathML。詞匯插件相對于目標詞匯使用。它們提供了一種使用詞匯連接描述符在詞匯之間進行映射的方式。僅在目標詞匯可被映射并具有預定的屏幕呈現(xiàn)方式時，這種映射才有意義。這種呈現(xiàn)方式為工業(yè)標準，例如由諸如W3C組織定義的XHTML。在需要詞匯連接時，使用詞匯連接畫布。在這種情況下，由于不能夠為源直接創(chuàng)建視圖，因此，不創(chuàng)建源畫布。在這種情況下，使用連接器樹來創(chuàng)建詞匯連接畫布。這種詞匯連接畫布僅僅處理事件轉換，而并不會有助于將文檔呈現(xiàn)在屏幕上。4.c.目的區(qū)、窗格以及畫布如上所述，詞匯連接子系統(tǒng)的目的在于創(chuàng)建并同時維護對同一文檔的兩種替換表述。第二替換表述還可以是先前被引入作為目的DOM樹的DOM樹形式。為了瀏覽第二種表述的文檔，需要目的區(qū)、畫布和窗格。在創(chuàng)建詞匯連接畫布后，創(chuàng)建相應的目的窗格307，如圖13所示。此外，相關的目的畫布308和相應的盒樹309被創(chuàng)建。同樣，詞匯連接畫布還與源文檔的窗格211和區(qū)209關聯(lián)。目的畫布308提供了文檔的第二種表述方式的邏輯布局。具體地，目的畫布308提供了用戶界面功能，例如光標和選擇(selection)，用于以目的表述的方式呈現(xiàn)文檔。在目的畫布308中發(fā)生的事件被提供到連接器。目的畫布308向連接器304通知鼠標事件、鍵盤事件、拖動和放置事件、以及通知文檔的目的(或第二種)表述的詞匯的特有事件。4.d.詞匯連接命令子系統(tǒng)圖13中的詞匯連接子系統(tǒng)300的一部分是詞匯連接命令子系統(tǒng)313。詞匯連接命令子系統(tǒng)313創(chuàng)建詞匯連接命令315，詞匯連接命令315用來執(zhí)行與詞匯連接子系統(tǒng)300相關的指令。可通過內(nèi)建的命令模板3131來創(chuàng)建詞匯連接命令，和/或可通過在腳本系統(tǒng)314中使用腳本語言從無到有地創(chuàng)建命令而創(chuàng)建詞匯連接命令。命令模板的例子包括“If”命令模板、“When”命令模板、“Insertfragment”命令模板等。這些模板被用來創(chuàng)建詞匯連接命令。4.e.Xpath子系統(tǒng)Xpath子系統(tǒng)316是文檔處理和管理系統(tǒng)的一個重要組件，因為它能夠有助于實現(xiàn)詞匯連接。連接器304通常包括xpath信息。如上所述，詞匯連接的任務是將源DOM樹中的變化反映到目的DOM樹中。xpath信息包括一個或多個用來確定源DOM樹中需要被觀察以確定改變/修改的子集的xpath表達式。4.f.源DOM樹、目的DOM樹和連接器樹的概述源DOM樹是對轉換為另一種詞匯之前以一種詞匯表述的文檔進行表述的DOM樹或區(qū)。在源DOM樹中的節(jié)點被稱為源節(jié)點。另一方面，目的DOM樹則表示用于在利用映射進行轉換之后以另一種詞匯表述的同一文檔的DOM樹或區(qū)，該映射已在前面結合詞匯連接描述。目的DOM樹中的節(jié)點被稱為目的節(jié)點。連接器樹是基于連接器的分級表述，用來表述源節(jié)點和目的節(jié)點之間的連接。連接器觀察源節(jié)點和對源文檔進行的修改。連接器隨后修改目的DOM樹。事實上，只有連接器是能夠修改目的DOM樹的對象。5.文檔處理和管理系統(tǒng)中的事件流為了能夠使用，程序必需對來自用戶的命令進行響應。事件是一種描述和執(zhí)行用戶對程序實施的動作的方式。許多高級語言例如JAVA依靠描述用戶動作的事件。在現(xiàn)有技術中，程序不得不主動收集用于理解用戶動作和通過自身執(zhí)行用戶動作的信息。這可能意味著，例如，在對程序初始化后，程序進入重復地查看用戶是否對屏幕、鍵盤和鼠標等執(zhí)行了任何動作、并接著采取適當動作的循環(huán)。然而，這種處理可能難以操控。此外，這種處理在等候用戶作某些事情時，還需要執(zhí)行循環(huán)的程序，從而消耗了CPU周期。許多語言通過包含不同的范例來解決這些問題，其中的一個范例構成了所有現(xiàn)代的window系統(tǒng)的基礎事件驅動程序。在這種范例中，所有的用戶動作屬于被稱為“事件”的事務的抽象集合。一種事件足夠詳細地描述了特殊的用戶動作。在感興趣的事件發(fā)生時，這種系統(tǒng)通知程序，而不是程序主動地收集用戶生成的事件。以這種方式處理用戶交互的程序被稱為“事件驅動”。這通常使用事件類來進行處理，其中事件類捕獲了所有用戶生成事件的基礎特性。文檔處理和管理系統(tǒng)定義和使用其自身的事件以及處理這些事件的方式。幾種類型的事件被使用。例如，鼠標事件是來自用戶的鼠標動作的事件。與鼠標有關的用戶動作由畫布210傳遞到鼠標事件。因此，畫布可以被認為是用戶與系統(tǒng)交互的最前沿。如果需要，最前沿的畫布將把其與事件有關的內(nèi)容傳遞到其下級(children)。另一方面，按鍵事件從畫布210產(chǎn)生。按鍵事件具有瞬時的焦點，即，按鍵事件涉及任意瞬時的活動。進入到畫布210的按鍵事件接著被傳遞到其上級(parent)。鍵盤輸入通過能夠處理字符串插入的不同事件而被處理。在使用鍵盤插入字符時，將觸發(fā)處理字符串插入的事件。其他的“事件”包括例如拖動事件、放置事件和其他能夠以與鼠標事件相似的方式處理的事件。5.a.在詞匯連接之外處理事件使用事件線程對事件進行傳遞。在接收到事件后，畫布210改變其狀態(tài)。如果需要，畫布210將命令1052記入到命令隊列1053。5.b.在詞匯連接之內(nèi)處理事件通過使用詞匯連接插件301，目的畫布1106接收現(xiàn)有的事件，例如鼠標事件、鍵盤事件、拖動和放置事件、以及詞匯的特有事件。這些事件接著被通知到連接器1104。更具體地說，詞匯連接插件301內(nèi)的事件流經(jīng)過源窗格1103、詞匯畫布1104、目的窗格1105、目的畫布1106、目的DOM樹和連接器樹1104，如圖21所示。6.程序調用器及其與其他組件之間的關系。在圖14(a)中更加詳細地顯示了程序調用器103及其與其他組件之間的關系。程序調用器103是在執(zhí)行環(huán)境中被執(zhí)行以啟動文檔處理和管理系統(tǒng)的基本程序。用戶應用程序106、服務代理104、命令調用器1051和資源109都被聯(lián)接到程序調用器103，如圖14(b)所示。如前所述，應用程序102是在執(zhí)行環(huán)境中運行的組件。同樣，服務代理104管理向系統(tǒng)增加各種功能的插件。另一方面，命令調用器1051維護用來執(zhí)行命令的類和函數(shù)，從而執(zhí)行用戶提供的指令。6.a.插件和服務下面將參照圖14(b)詳細描述服務代理104。如上所述，服務代理104管理向系統(tǒng)增加各種功能的插件(及相關服務)。服務1041在最底層，在該層中可以將特征增加到文檔處理和管理系統(tǒng)，或改變該系統(tǒng)中的特征?！胺铡庇蓛刹糠謽嫵煞辗N類401和服務提供器402。如圖14(c)所示，單個的服務種類401可具有多個相關的服務提供器402，這些多個服務提供器402中的每一個都可操作以執(zhí)行所有或部分的特定服務種類。另一方面，服務種類401則定義了服務的類型。服務可分為三種類型1)向系統(tǒng)提供特定特征的特征服務；2)應用程序服務，其是由文檔處理和管理系統(tǒng)運行的應用程序；以及3)提供在整個文檔處理和管理系統(tǒng)中需要的特征的環(huán)境服務。圖14(d)中示出了服務的例子。根據(jù)應用程序服務的種類，系統(tǒng)實用程序是相應服務提供器的示例。同樣，editlet206是一個種類，HTMLeditlet和SVGeditlet是相應的服務提供器。區(qū)工廠205是服務的另一種，并具有相應的服務提供器(未示出)。之前描述的向文檔處理和管理系統(tǒng)增加功能的插件可以看作是由幾個服務提供器402和與其相關的類構成的單元，如圖14(c)和14(d)所示。各個插件都應該具有在清單文件(manifestfile)中寫入的從屬和服務種類。6.b.程序調用器和應用程序之間的關系圖14(e)詳細顯示了程序調用器103和用戶應用程序106之間的關系。所需的文檔、數(shù)據(jù)等從存儲中載入。所有需要的插件載入到服務代理104。服務代理104管理并維護所有的插件?？晌锢淼貙⒉寮黾拥较到y(tǒng)，或者可從存儲中載入其功能。在載入插件的內(nèi)容后，服務代理104定義相應的插件。相應的用戶應用程序106被創(chuàng)建，接著被載入到執(zhí)行環(huán)境101并聯(lián)接到程序調用器103。7.應用程序服務和環(huán)境之間的關系圖15(a)進一步示出了載入程序調用器103中的應用程序服務的結構。作為命令子系統(tǒng)105組件的命令調用器1051調用或執(zhí)行程序調用器103內(nèi)的命令1052。命令1052則是用來在文檔處理和管理系統(tǒng)中處理文檔(例如，XML文檔)和編輯相應的XMLDOM樹的指令。命令調用器1051維護執(zhí)行命令1052所需的功能和類。服務調用器1041也在程序調用器103中執(zhí)行。用戶應用程序106連接到用戶界面107和核心組件110。核心組件110提供了一種在所有的窗格中共享文檔的方式。核心組件110還提供字體并作為用于窗格的工具包。圖15(a)和(b)顯示了框架1071、菜單欄1072和狀態(tài)欄1073之間的關系。8.應用程序核心圖16(a)進一步解釋了應用程序核心110，其保持所有文檔以及作為文檔一部分并屬于文檔的數(shù)據(jù)。核心組件110聯(lián)接到管理文檔1082的文檔管理器1081。文檔管理器1081是存儲到與文檔處理和管理系統(tǒng)關聯(lián)的存儲器中的所有文檔1082的所有者(proprietor)。為了便于在屏幕上顯示文檔，文檔管理器1081還連接到根窗格1084。剪貼板1085、快照1087、拖拉和放置601，覆蓋602的功能也被聯(lián)接到核心組件。如圖16(b)所示，快照1087用來撤消應用程序狀態(tài)。在用戶調用快照功能1087時，應用程序的當前狀態(tài)被檢測并存儲。所存儲的狀態(tài)的內(nèi)容在應用程序改變?yōu)榱硪粻顟B(tài)時被保存下來。在圖16(b)中示出了快照。在操作中，當應用程序從一個URL移動到另一個時，快照會記住先前的狀態(tài)，從而能夠無縫地執(zhí)行后退和前進操作。9.在文檔管理器中組織文檔圖17(a)更加詳細地描述了文檔管理器1081以及如何在文檔管理器中組織并保存文檔。如圖17(b)所示，文檔管理器1081管理文檔1082。在圖17(a)顯示的實施例中，多個文檔中的一個為根文檔701，其他的文檔為子文檔702。文檔管理器1081連接到根文檔701，根文檔701則連接到所有的子文檔702。如圖12和17(a)所示，文檔管理器1081耦合到文檔容器203，文檔容器203是容納所有文檔1082的對象。形成工具包(例如，XML工具包)201的一部分的工具(包括DOM服務703和IO管理器704)也提供給文檔管理器1081。再參照圖17(a)，DOM服務703基于由文檔管理器1081管理的文檔來創(chuàng)建DOM樹。各個文檔705，不管是根文檔701還是子文檔702都容納在相應的文檔容器203中。圖17(b)顯示了一組文檔A-E是如何以分級結構排列的實施例。文檔A為根文檔。文檔B-D是文檔A的子文檔。文檔E則是文檔D的子文檔。圖17(b)還顯示了如何將文檔的同一分級結構顯示在屏幕上的實施例。作為根文檔的文檔A顯示為基礎框架。文檔A的子文檔B-D顯示為在基礎框架A內(nèi)的子框架。文檔D的子文檔E在屏幕上顯示為子框架D的子框架。再參照圖17(a)，為各個文檔容器203創(chuàng)建撤消管理器706和撤消封裝器(wrapper)707。撤消管理器706和撤消封裝器707用來執(zhí)行可撤消的命令。使用該特征，可以撤消使用編輯操作對文檔所作的改變。子文檔中的改變也會涉及到根文檔。撤消操作考慮到了影響分級結構內(nèi)其他文檔的改變，并確保了在分級結構鏈中的所有文檔之間所維護的一致性，例如，如圖17(b)所示。撤消封裝器707將與容器203中的子文檔相關的撤消對象進行封裝，并將它們和與根文檔相關的撤消對象耦合。撤消封裝器707使得可撤消編輯接收器709能夠收集撤消對象。撤消管理器706和撤消封裝器707連接到可撤消編輯接收器708和可撤消編輯源708。本領域技術人員應該理解，文檔705可以是可撤消編輯源708，并因此可以是可撤消編輯對象。10.撤消命令和撤消框架圖18(a)和(b)進一步詳細地顯示了撤消框架和撤消命令。如圖18(a)所示，撤消命令801、重做命令802和可撤消編輯命令803是能夠排列在命令調用器1051中的命令(如圖11(b)所示)并且被相應地執(zhí)行?？沙废庉嬅?03還進一步聯(lián)接到可撤消編輯源708和可撤消編輯接收器709。例如，可撤消編輯命令是“foo”編輯命令803和“bar”編輯命令804。圖18(b)顯示了可撤消編輯命令的執(zhí)行。首先，假設用戶使用編輯命令來編輯文檔705。在第一步驟S1，可撤消編輯接收器709被聯(lián)接到可撤消編輯源708，而可撤消編輯源708為文檔705的DOM樹。在第二步驟S2，基于由用戶發(fā)出的命令，使用DOMAPI對文檔705進行編輯。在第三步驟S3，向變化事件監(jiān)聽器通知已經(jīng)發(fā)生了改變。即，在該步驟，監(jiān)控DOM樹中所有改變的監(jiān)聽器檢測編輯操作。在第四步驟S4，用撤消管理器706將可撤消的編輯存儲為對象。在第五步驟S5，可撤消編輯接收器709與源708分開，源708可以是文檔705本身。11.向系統(tǒng)載入文檔時需要的步驟上述幾個子部分描述了系統(tǒng)的各個組件和子組件。下面將描述在使用這些組件時用到的方法。圖19顯示了如何將文檔載入到文檔處理和管理系統(tǒng)中的總體圖。參照圖24-28詳細地描述各個步驟。簡言之，文檔處理和管理系統(tǒng)從由在文檔中包含的數(shù)據(jù)構成的二進制數(shù)據(jù)流創(chuàng)建DOM樹。為文檔中的感興趣的并位于“區(qū)”中的一部分創(chuàng)建頂節(jié)點，接著確定相應的“窗格”。所確定的窗格從頂節(jié)點和物理屏幕表面創(chuàng)建“區(qū)”和“畫布”?！皡^(qū)”為各個節(jié)點創(chuàng)建“方面”，并為它們提供所需信息。畫布創(chuàng)建用于呈現(xiàn)DOM樹的節(jié)點的數(shù)據(jù)結構。具體地，參照圖19(a)，在“步驟0”，表述SHTML和SVG內(nèi)容的復合文檔從存儲901載入。接著，為文檔創(chuàng)建DOM樹902。應該注意，DOM樹具有頂節(jié)點905(XHTML)，以及隨著DOM樹下降到其他分支，會遇到由雙線表示的邊界，接著是用于不同詞匯SVG的頂節(jié)點906。這種復合文檔的表述有助于理解用來呈現(xiàn)并最終顯示文檔的方式。接下來，創(chuàng)建保持文檔的相應文檔容器903。接著將文檔容器903聯(lián)接到文檔管理器904。DOM樹包括根節(jié)點，并且可選地包括多個次級節(jié)點。典型地，這種文檔包括文本和圖形。因此，DOM樹例如能夠具有XHTML子樹以及SVG子樹。XHTML子樹具有XHTML頂節(jié)點905。同樣，SVG子樹具有SVG頂節(jié)點906。再次參照圖19(a)，在步驟1，將頂節(jié)點聯(lián)接到窗格907(窗格907是屏幕的物理布局)。在步驟2，窗格907向應用程序核心908請求用于頂節(jié)點的區(qū)工廠。在步驟3，應用程序核心908返回區(qū)工廠以及editlet(其為用于頂節(jié)點906的畫布工廠)。在步驟4，窗格907創(chuàng)建區(qū)909，區(qū)909聯(lián)接至窗格。在步驟5，區(qū)909為各個節(jié)點創(chuàng)建“方面”，并聯(lián)接到相應的節(jié)點。在步驟6，窗格創(chuàng)建與其聯(lián)接的畫布910。在畫布910中包括各種命令。在步驟7中，畫布910則構建用于將文檔呈現(xiàn)在屏幕上的數(shù)據(jù)結構。在XHTML的情況下，這包括盒樹結構。圖19(b)使用MVC范例顯示了區(qū)的結構概要。在這種情況下，模型(M)包括區(qū)工廠創(chuàng)建的區(qū)和“方面”，這是因為它們是與文檔相關的輸入。視圖(V)對應于畫布和數(shù)據(jù)結構，以利用editlet將文檔在屏幕上呈現(xiàn)，這是由于這些呈現(xiàn)是用戶在屏幕上看到的輸出?？刂?C)包括畫布中所包含的命令，這是由于這些命令對文檔及其關系執(zhí)行控制操作。12.文檔的表述下面將使用圖20來描述復合文檔及其各種表述的實施例。在該實施例中使用的文檔包括文本和圖片。文本使用XHTML表述，而圖片用SVG表述。圖20詳細顯示了用于文檔組件的MVC表述以及相應對象的關系。對于該示例性的表述，文檔1001聯(lián)接到保持文檔1001的文檔容器1002。文檔用DOM樹1003表述。DOM樹1003包括頂節(jié)點1004和其他子節(jié)點，如之前參照圖19(a)所述這些節(jié)點具有相應的“方面”。頂節(jié)點用陰影圓圈表示。非頂節(jié)點用非陰影圓圈表示。用來編輯節(jié)點的“方面”用三角形表示，并被聯(lián)接到相應的節(jié)點。由于文檔具有文本和圖片，所以用于該文檔的DOM樹包括XHTML部分和SVG部分。頂節(jié)點1004是XHTML子樹的最頂部的節(jié)點。該節(jié)點被聯(lián)接到XHTML窗格1005，XHTML窗格1005是文檔XHTML部分的物理表述的最頂部窗格。該頂節(jié)點1004還聯(lián)接到XHTML區(qū)1006，其中XHTML區(qū)1006是文檔1001的DOM樹的一部分。與節(jié)點1004相對應的“方面”1041還聯(lián)接到XHTML區(qū)1006。XHTML區(qū)1006則聯(lián)接到XHTML窗格1005。XHTMLeditlet創(chuàng)建XHTML畫布1007，XHTML畫布1007是文檔的邏輯表述。XHTML畫布1007聯(lián)接到XHTML窗格1005。XHTML畫布1007為文檔1001的XHTML組件創(chuàng)建盒樹1009。如圖所示，盒樹通過htmlBox、bodyBox、headBox和/或tableBox的適當組合來表述。維護和呈現(xiàn)文檔的XHTML部分所需的各種命令1008也被增加到XHTML畫布1005。同樣，該文檔的SVG子樹的頂節(jié)點1010被聯(lián)接到SVG區(qū)1011，SVG區(qū)1011是文檔1001的DOM樹的、用于表述文檔的SVG組件的部分。頂節(jié)點1010被聯(lián)接到SVG窗格1013，SVG窗格1013是文檔的SVG部分的物理表述的最頂部窗格。表述文檔的SVG部分的邏輯表述的SVG畫布1012通過SVGeditlet創(chuàng)建，并被聯(lián)接到SVG窗格1013。用于將文檔的SVG部分呈現(xiàn)在屏幕上的數(shù)據(jù)結構和命令1014被聯(lián)接到SVG畫布1012。例如，這種數(shù)據(jù)結構可包括圓圈、線、矩形等，如圖所示。下面將使用先前描述的MVC范例，參照圖21(a)和21(b)進一步討論參照圖20描述的、用于對該示例性文檔進行表述的部件。圖21(a)提供了文檔1001的XHTM組件的MV關系的簡化圖。圖中的模型是用于文檔1001的XHTML組件的XHTM區(qū)1103。包括在XHTML區(qū)樹中的是幾個節(jié)點及其相應的“方面”。相應的XHTML區(qū)和窗格是MVC范例的模型(M)部分的一部分。MVC范例的視圖(V)部分是用于文檔1001的HTML組件的相應的XHTML畫布1102和盒樹。通過畫布以及其中所包含的命令，文檔的XHTML部分被呈現(xiàn)在屏幕上。例如鍵盤和鼠標輸入的事件以如圖所示的相反方向進行處理。也就是說，源窗格具有附加功能，以起到DOM保持器的作用。圖21(b)提供了在圖21(a)中示出的用于文檔1001的組件的詞匯連接。作為源DOM保持器的源窗格1103包含了用于文檔的源DOM樹。連接器樹1004通過連接器工廠創(chuàng)建，連接器樹1004又創(chuàng)建作為目的DOM樹保持器的目的窗格1105。目的窗格1105接著以盒樹的形式被布置為XHTML目的畫布1106。13.插件子系統(tǒng)、詞匯連接和連接器之間的關系圖22(a)-(c)分別顯示了與插件子系統(tǒng)、詞匯連接和連接器相關的附加細節(jié)。插件子系統(tǒng)被用來向文檔處理和管理系統(tǒng)增加功能，或與之交換功能。插件子系統(tǒng)包括服務代理1041。如圖22(a)所示，名稱為“MyOwnXMLvocabulary(我的XML詞匯)”VCD文件耦合至包括MyOwnXML連接器工廠樹和詞匯(區(qū)工廠，Editlet)的VC基本插件。聯(lián)接到服務代理1041的區(qū)工廠服務1201負責創(chuàng)建用于文檔的部分的區(qū)。editlet服務1202還被聯(lián)接到服務代理。editlet服務1202創(chuàng)建與區(qū)中的節(jié)點相對應的畫布。區(qū)工廠的實施例是分別創(chuàng)建XHTML區(qū)和SVG區(qū)的XHTML區(qū)工廠1211和SVG區(qū)工廠1212。如上參照示例性文檔所述，文檔的文本組件可通過創(chuàng)建XHTML區(qū)來表述，而圖片則可使用SVG區(qū)來表述。editlet服務的示例包括XHTMLeditlet1221和SVGeditlet1222。圖22(b)進一步詳細顯示了詞匯連接，如上所述，詞匯連接是文檔處理和管理系統(tǒng)的重要特征，其能夠使兩種不同方式的文檔的表述和顯示保持一致。能夠維護連接器工廠303的詞匯連接管理器是詞匯連接子系統(tǒng)的一部分，并耦合到VCD以接收詞匯連接描述符并生成詞匯連接命令301。如圖22(c)所示，連接器工廠303為文檔創(chuàng)建連接器304。如上所述，連接器觀察源DOM中的節(jié)點，并修改目的DOM中的節(jié)點，以維護兩種表述之間的一致性。模板表述用于一些節(jié)點的轉換規(guī)則。事實上，詞匯連接描述符文件是表示一些規(guī)則的一系列模板，這些規(guī)則用于將滿足某種路徑或規(guī)則的元素或元素集合轉換為其他的元素。詞匯模板305和命令模板3131都聯(lián)接到詞匯連接管理器302。詞匯連接管理器302是在VCD文件中所有部分的管理器對象。為一個VCD文件創(chuàng)建一個詞匯連接管理器對象。圖22(c)表示了連接器的附加細節(jié)。連接器工廠303從源文檔中創(chuàng)建連接器。連接器工廠聯(lián)接于詞匯、模板和元素模板，并分別創(chuàng)建詞匯連接器、模板連接器和元素連接器。詞匯連接管理器302維護連接器工廠303。為了創(chuàng)建詞匯，讀取相應的VCD文件。接著創(chuàng)建連接器工廠303。該連接器工廠303與負責創(chuàng)建區(qū)的區(qū)工廠205和負責創(chuàng)建畫布的editlet服務206相關聯(lián)。接著，用于目標詞匯的editlet服務創(chuàng)建詞匯連接畫布。詞匯連接畫布為目的DOM樹創(chuàng)建節(jié)點。詞匯連接畫布為源DOM樹或區(qū)中的頂點元素創(chuàng)建連接器。接著，根據(jù)需要遞歸地創(chuàng)建子連接器。通過VCD文件中的一組模板創(chuàng)建連接器樹。模板是用于將標記語言的元素轉換為其他元素的規(guī)則集合。例如，各個模板與源DOM樹或區(qū)相匹配。在正確匹配時，創(chuàng)建頂點連接器。例如，模板“A/*/D”監(jiān)測所有從節(jié)點A開始、在節(jié)點D結束的樹分支，而不考慮節(jié)點A和節(jié)點D之間的節(jié)點。同樣，“//B”對應于所有來自根節(jié)點的“B”節(jié)點。14.VCD文件相關的連接器樹的示例下面將解釋與特定文檔相關的處理。名為MySampleXML的文檔被載入到文檔處理系統(tǒng)。圖23顯示了使用詞匯連接管理器的VCD腳本和用于MySampleXJML的連接器工廠樹的實施例。在圖中顯示了腳本文件內(nèi)的詞匯部分、模板部分以及它們在詞匯連接管理器中的相應組件。在標簽“vcd:vocabulary”下提供了屬性match＝″sample:root″、label＝″MySampleXML″以及call-template＝″sampleTemplate″。與該實施例相對應，在MySampleXML的詞匯連接管理器中，詞匯包括頂點元素“sample:root”。相應的UI標注為“MySampleXML”。在模板部分，標簽為vcd:template，名稱為“sampletemplate”。15.如何將文件載入系統(tǒng)的詳細實施例圖24-28顯示了載入文檔MySampleXML的詳細描述。在步驟1，如圖24(a)所示，文檔從存儲1405中載入。DOM服務創(chuàng)建DOM樹和文檔管理器1406以及對應的文檔容器1401。文檔容器聯(lián)接到文檔管理器1406。文檔包括用于XHTML和MySampleXML的子樹。XHTML頂節(jié)點1403是用于XHTML的最頂部的節(jié)點，并具有標簽xhtml:html。另一方面，mysample頂節(jié)點1404對應于MySampleXML，并具有標簽sample:root。在步驟2，如圖24(b)所示，根窗格為文檔創(chuàng)建XTML區(qū)、“方面”和畫布。根據(jù)圖中示出的關系，在步驟1-5中創(chuàng)建與頂節(jié)點1403、其他節(jié)點以及它們相關的“方面”相應的窗格1407、XHTML區(qū)1408、XHTML畫布1409和盒樹1410。在步驟3，如圖24(c)所示，XHTML區(qū)域找到外來的標簽“sample:root”，并從html畫布上的區(qū)域創(chuàng)建子窗格。圖25顯示了步驟4，在步驟4中，子窗格1501獲取能夠處理“sample:root”標簽并創(chuàng)建適當?shù)膮^(qū)的相應的區(qū)工廠。這種區(qū)域工廠將在能夠實現(xiàn)區(qū)域工廠的詞匯中。區(qū)域工廠包括MySampIeXML中的詞匯部分的內(nèi)容。圖26顯示了步驟5，在步驟5中，與MySampleXML對應并與VC管理器相連的詞匯創(chuàng)建缺省的區(qū)1061。相應的editlet被創(chuàng)建并被提供給子窗格1501，以創(chuàng)建相應的畫布。editlet創(chuàng)建詞匯連接畫布。接著，editlet調用與連接器工廠樹耦合的模板部分。連接器工廠樹創(chuàng)建所有的連接器，接著將創(chuàng)建的連接器形成連接器樹(連接器樹形成VC畫布的一部分)。根據(jù)前面的描述，對于與文檔的XHTML內(nèi)容相關的頂節(jié)點，根窗格和XHTML區(qū)的關系以及XHTML畫布和盒樹之間的關系是顯而易見的。圖27基于如上所述的源DOM樹、VC畫布和目的DOM樹之間的對應關系顯示了步驟6。在步驟6中，各個連接器創(chuàng)建目的DOM對象。一些連接器包括xpath信息。xpath信息包括一個或多個xpath表達式，xpath表達式用來確定需要被監(jiān)測是否發(fā)生了改變/修改的源DOM樹的子集。圖28根據(jù)源、VC和目的關系顯示了步驟7。在步驟7中，詞匯從源DOM的窗格形成目的DOM樹的目的窗格。這基于源窗格來完成。接著，將目的樹的頂節(jié)點聯(lián)接到目的窗格以及相應的區(qū)。接著為目的窗格設置其自身的editlet，editlet則創(chuàng)建目的畫布，并構建數(shù)據(jù)結構和命令，從而以目的格式呈現(xiàn)文檔。圖29(a)顯示了發(fā)生于某節(jié)點的事件流，該節(jié)點不具有相應的源節(jié)點并僅依賴于目的樹。在第一步驟，畫布所獲取的事件(例如鼠標事件和鍵盤事件)通過目的樹，并被傳輸?shù)皆啬０暹B接器(ElementTemplateConnector)。元素模板連接器不具有相應的源節(jié)點，因此被傳送的事件并不是對源節(jié)點的編輯操作。如果所傳送的事件與命令模板(CommandTemplate)中描述的命令相匹配，則元素模板連接器在第二和第三步驟執(zhí)行相應的動作。否則，元素模板連接器忽略所傳送的事件。圖29(b)顯示了發(fā)生于某目的樹的節(jié)點的事件流，該目的樹的節(jié)點通過文本連接器(TextOfConnector)與源節(jié)點相關聯(lián)。文本連接器從由源DOM樹的XPath規(guī)定的節(jié)點獲取文本節(jié)點，并將該文本節(jié)點映射為目的DOM樹的節(jié)點。在第一步驟，畫布所獲取的事件(例如鼠標事件和鍵盤事件)通過目的樹，并被傳送到文本連接器。文本連接器將所傳送的事件映射為相應源節(jié)點的編輯命令，并將這些命令設置在隊列1053中。編輯命令是通過“方面”執(zhí)行的DOM的一組API調用。在第二步驟中，當執(zhí)行設置在隊列中的命令時，編輯源節(jié)點。在編輯源節(jié)點時，在第三步驟發(fā)出變化事件，并且將對源節(jié)點的修改通知到注冊為監(jiān)聽器的文本連接器。在第四步驟中，文本連接器重新建立目的樹，從而在相應的目的節(jié)點中反映出對源節(jié)點的修改。如果包含文本連接器的模板包括控制聲明，例如“foreach”和“forloop”，則連接器工廠重新評估控制聲明。在重建文本連接器后，重建目的樹。該實施方案提供了一種在處理文檔時分配適當?shù)奶幚韱卧蛳到y(tǒng)的方法。如參照圖24(a)所述的那樣，當載入文檔并生成DOM樹時，選擇頂節(jié)點處理單元。如參照圖19(a)所述的那樣，頂節(jié)點被傳送到根窗格，窗格擁有者選擇能處理該頂節(jié)點的處理單元。窗格擁有者預先注冊可由用于系統(tǒng)中存在的詞匯插件或VCD文件的各個處理單元處理的命名空間和頂節(jié)點元素名稱的條目，并根據(jù)由窗格傳送的命名空間和頂節(jié)點的元素名稱來選擇適當?shù)奶幚韱卧?。被選擇的處理單元提供區(qū)工廠和editlet，并分別由區(qū)工廠和editlet生成區(qū)和畫布。該處理的流程已參照圖19(a)至24(a)進行了說明。當區(qū)遇到對于該區(qū)而言未知的節(jié)點(即，該區(qū)不能向其聯(lián)接“方面”)時，雖然該區(qū)試圖向節(jié)點聯(lián)接“方面”，但是該區(qū)不能處理該節(jié)點。該區(qū)可忽略該節(jié)點或者可將對該節(jié)點的處理委托給另一處理單元。在后一種情況下，該區(qū)將該節(jié)點返回至窗格。該窗格為以該節(jié)點為頂節(jié)點的區(qū)生成子窗格，并將該節(jié)點和子窗格返回至父節(jié)點。窗格擁有者選擇能處理該節(jié)點的處理單元。通過這種方式，可向DOM樹中的各個節(jié)點分配至少一個處理單元，從而能使用分配的處理單元來處理DOM樹中的所有節(jié)點。處理單元是根據(jù)命名空間和頂節(jié)點的元素名稱來選擇的。也可考慮頂節(jié)點的屬性名稱和屬性值。還可同樣考慮對頂節(jié)點指定的全局屬性。作為頂節(jié)點的屬性或全局屬性，待選擇的候選處理單元可被明確指定?？商峁┝信e了能夠由處理單元進行處理的元素的表，用于選擇能夠處理頂節(jié)點下方的元素的處理單元。此外，可考慮該頂節(jié)點的祖先節(jié)點上的信息。在這一點上，DOM樹上的、作為主題節(jié)點(subjectnode)的后代節(jié)點或兄弟節(jié)點的任一節(jié)點可被稱為“祖先”或“后代”。例如，節(jié)點可參考其祖先的兄弟/姐妹。當將另一詞匯的全局屬性指定給一詞匯的元素時，僅能用于一個詞匯的處理單元可能無法處理該詞匯。為了解決這一問題，例如，如果指定了全局屬性，則可選擇用于全局屬性的處理單元，并將其與用于頂節(jié)點所屬詞匯的處理單元一起載入。在這種情況下，全局屬性處理單元和頂節(jié)點處理單元可依據(jù)多種因素、并根據(jù)一種或多種分配算法而并行處理、交替處理或選擇性地處理。如果選擇了多個能夠進行處理的處理單元，則可接受來自用戶的選擇指令，或者可參考歷史記錄來確定適當?shù)奶幚韱卧?。例如，對于一直使用某特定開發(fā)商的處理單元的用戶，該開發(fā)商的處理單元可以作為第一優(yōu)先級而選擇。在上述實施例中，盡管遇到了不能處理的節(jié)點的區(qū)將對該節(jié)點的處理委托給另一處理單元，但能夠處理節(jié)點的節(jié)點也可將對該節(jié)點的處理委托給另一處理單元。例如，當XHTML處理單元處理XHTML文檔時，如果用以對表進行處理的另一處理單元載入該系統(tǒng)中，則對表元素的處理可委托給所述另一處理單元。如果處理單元能夠處理的節(jié)點被嵌套入DOM樹，則被選擇的處理單元可搜索祖先節(jié)點，以檢查該處理單元能夠處理的節(jié)點，并指定能作為新的頂節(jié)點處理的最高級別的節(jié)點。該處理單元可確定是否逐個節(jié)點地將處理委托給另一處理單元。如果多個處理單元都能處理節(jié)點，那么可預先設定為待選擇的處理單元賦予第一優(yōu)先級的條件，或者可向用戶發(fā)出選擇哪個處理單元的詢問。如果一文檔中包含了多個標簽集，則用以確定處理單元的最佳組合的條件可在分配算法中預先設定。例如，可以為與相應DOM樹中的節(jié)點相關的各個元素分配候選處理單元，可以選擇處理單元的組合以使得處理單元的邊界最小化。例如，假設處理系統(tǒng)A能夠處理標簽a和b，處理系統(tǒng)B能夠處理標簽b、d和e，處理系統(tǒng)C能夠處理標簽a、c和e，那么，當待處理的文檔包含自最高級別降序排列的標簽a、c、d和e時，最高級別的標簽“a”可由處理系統(tǒng)A或C來處理，標簽“c”可由處理系統(tǒng)C來處理、標簽“d”可由處理系統(tǒng)B來處理、標簽“e”可由處理系統(tǒng)B或C來處理。因此，處理系統(tǒng)C被分配給標簽“a”和“c”，而處理系統(tǒng)B被分配給標簽“d”和“e”。在分配處理單元時的其他考慮包括整個系統(tǒng)的資源消耗的優(yōu)化或響應性能的優(yōu)化。換句話說，對處理單元的選擇可基于一種或多種分配算法和/或標準。此外，在多個候選單元都能處理給定節(jié)點的情況下，多個處理單元可并行地進行處理，但僅被選擇的一個或多個結果可顯示給用戶，而其他結果則簡單地運行于后臺。區(qū)邊界并非必須與命名空間邊界相匹配。區(qū)邊界并非必須與標簽集邊界相匹配。例如，當提供了既能處理SHTML又能處理SVG的詞匯插件時，可通過使用單個詞匯插件來處理包含XHTML和SVG的復合文檔?？商峁┨幚韱卧獊硪噪娮訑?shù)據(jù)表應用的方式僅處理XHTML的表部分。換句話說，處理單元可能能夠處理多個詞匯、標簽集和標記語言。因而，如根據(jù)前述的能力已清楚說明的那樣，復合文檔的片段可被多個處理單元處理，這些單元可相互共享處理共用詞匯和/或標簽的能力。此外，這些處理單元中可具有共用或共享的能力，以處理撤消步驟。這種共用能力可操作以在共用顯示媒介上執(zhí)行聚焦管理和定位管理，并可被調整以處理對復合文檔進行處理時的暫停和恢復。這種共用能力可通過排列命令來操作。處理單元還可在文件名或文檔文件的擴展名的基礎上選擇。另外，處理單元可在處理細節(jié)的基礎上選擇。例如，在瀏覽文檔的情況下，可選擇專用于瀏覽的處理單元。在編輯文檔的情況下，可選擇能夠進行編輯的處理單元。以這種方式，通過在載入文檔后可插入地分配適當?shù)奶幚韱卧?，包含詞匯的任意組合的文檔能被正確地處理。即使是在文檔載入之后，當前處理單元也能被另一處理單元取代。上面基于僅為說明性的實施方案描述了本發(fā)明。本領域的技術人員應該理解，還可以對上述的各個組件和處理的組合進行其他各種修改，并且這些修改落入本發(fā)明的保護范圍。盡管通過處理XML文檔的實施例解釋了上述實施方案，但根據(jù)該實施方案的文檔處理裝置20還能夠類似地處理以其他標記語言(例如SGML和HTML)描述的文檔。權利要求1.一種文檔處理裝置，其可操作以處理具有一個或多個詞匯的復合文檔，用于顯示給用戶以進行編輯，從而有利于對所述復合文檔進行編輯，所述文檔處理裝置包括多個處理單元，所述多個處理單元中的每一個可操作以在預定標簽集的基礎上對文檔或文檔的一部分進行處理；以及顯示處理裝置，其響應于所述多個處理單元，用于為在單一顯示媒介上向所述用戶顯示所述復合文檔做準備。2.如權利要求1所述的文檔處理裝置，還包括詞匯轉換器，當所述復合文檔包括了所述多個處理單元中的至少一個單元不能處理的標簽集所定義的部分時，所述詞匯轉換器可操作以將用于該部分的標簽集映射為能夠由所述多個處理單元中的至少一個來處理的標簽集。3.如權利要求1所述的文檔處理裝置，其中，當所述復合文檔包括了所述多個處理單元中的至少一個單元不能處理的標簽集所定義的部分時，所述文檔處理裝置將該部分呈現(xiàn)為源顯示或者樹顯示。4.如權利要求1到3中任一項所述的文檔處理裝置，其中，所述顯示處理裝置可操作以呈現(xiàn)與所述復合文檔待編輯的部分相對應的編輯菜單。5.如權利要求1到4中任一項所述的文檔處理裝置，其中，對于包括多種標簽集的復合文檔，能夠對用于第一種標簽集的數(shù)據(jù)進行處理的處理單元可操作以訪問所述復合文檔的、由不同于所述第一標簽集的第二標簽集構成的部分的數(shù)據(jù)。6.如權利要求1到4中任一項所述的文檔處理裝置，其中，所述復合文檔由多個元素表述，所述多個元素中的每一個包含選擇信息；根據(jù)從一元素中獲取的選擇信息，將所述多個處理單元中能夠處理所述文檔中的該元素的一個處理單元選為選定的處理單元。7.如權利要求6所述的文檔處理裝置，其中，從所述元素中獲取的所述選擇信息包括元素名和元素命名空間的至少其中之一。8.如權利要求6或7所述的文檔處理裝置，其中，從所述元素中獲取的所述選擇信息包括所述元素中所包含的屬性的屬性名和屬性值的至少其中之一。9.如權利要求6到8中任一項所述的文檔處理裝置，其中，被選擇來處理元素的處理單元從所述元素向其子元素按順序地確定元素是否能夠處理，當存在不能處理的元素時，所述處理單元可操作以至少委托另一個處理單元作為選定的處理單元處理所述元素，或者制止所述元素的處理。10.如權利要求9所述的文檔處理裝置，其中，當所述處理單元能夠處理元素，且另一個處理單元也能夠處理所述元素時，所述處理單元能夠選擇是由所述處理單元還是由所述另一個處理單元作為選定的處理單元來處理所述元素。11.如權利要求1到4中任一項所述的文檔處理裝置，還包括管理單元，所述管理單元用于生成和管理具有與文檔對象模型相符的格式的數(shù)據(jù)，所述文檔對象模型被定義成提供一種訪問方法，用來以處理數(shù)據(jù)方式處理所述文檔，其中，所述管理單元生成對應于所述文檔的文檔對象模型數(shù)據(jù)；以及根據(jù)從表述所述文檔對象模型數(shù)據(jù)的DOM樹的子樹的頂節(jié)點中獲得的信息，將一處理單元選為選定的處理單元。12.如權利要求11所述的文檔處理裝置，其中，所述選定的處理單元從所述頂節(jié)點向所述頂節(jié)點的子節(jié)點增加對象，所述增加的對象包括專用于所述節(jié)點的s，并且所述選定的處理單元委托另一個處理單元對不能增加所述對象的節(jié)點進行處理。13.如權利要求6到12中任一項所述的文檔處理裝置，其中，所述處理單元中的至少一個可操作以處理多個標簽集。14.一種文檔處理方法，用于對具有一個或多個詞匯的復合文檔進行處理以有利于對所述復合文檔進行編輯，所述方法包括提供多個處理，所述多個處理中的每一個在用于顯示的預定標簽集的基礎上對文檔或文檔的一部分進行處理；處理所述文檔的所述多個標簽集以在共用的顯示媒介上進行顯示；以及對用戶輸入進行響應以編輯所述文檔。15.一種計算機程序產(chǎn)品，其可操作以控制計算機執(zhí)行用于處理具有一個或多個詞匯的復合文檔的方法，以有利于對所述復合文檔進行編輯，包括提供多個處理，所述多個處理中的每一個在用于顯示的預定標簽集的基礎上對文檔或文檔的一部分進行處理；處理所述文檔的所述多個標簽集以在共用的顯示媒介上進行顯示；以及對用戶輸入進行響應以編輯所述文檔。16.一種用于編輯和/或顯示具有多個詞匯的復合文檔的方法，包括載入待處理的所述復合文檔；從所述復合文檔生成DOM樹；通過參考所述復合文檔的命名空間或元素的至少其中之一，確定所述復合文檔由哪個或哪些詞匯描述；如果對應于所述詞匯的詞匯處理部件是可用的，則操作所述詞匯處理部件以顯示和/或編輯所述文檔；如果所述詞匯處理部件是不可用的，則確定是否存在相應的定義文件；以及如果存在所述定義文件，則獲取所述定義文件并生成相應的目的樹，從而能夠通過與所述詞匯對應的、映射的處理部件來顯示和/或編輯所述文檔。17.如權利要求16所述的方法，其中，對于多個詞匯中的每一個，通過與各詞匯相對應的處理部件來顯示和/或編輯所述復合文檔的相關部分。18.如權利要求16所述的方法，其中，如果不存在所述定義文件，則顯示所述復合文檔的源或樹結構，并在顯示媒介中執(zhí)行編輯。19.如權利要求17所述的方法，其中，所述復合文檔的至少一部分能夠通過多個處理部件來顯示和/或編輯。20.如權利要求17所述的方法，其中，所述復合文檔的至少兩部分能夠通過共用的處理部件來顯示和/或編輯。21.一種用于處理復合文檔以顯示給用戶從而有利于顯示所述復合文檔的方法，所述復合文檔具有至少兩個標簽集并能夠分為分離的片段，所述方法包括根據(jù)所述片段邏輯地分割所述文檔；為至少兩個片段中的每一個分配至少一個對應的處理部件；使用至少一個對應的處理部件分別處理所述片段中的至少兩個，所述處理部件的每一個可操作以處理預定的標簽集；以及在共用的編輯顯示器上顯示對所述至少兩個片段進行處理的結果。22.如權利要求21所述的方法，還包括在存儲器中將所述復合文檔表示為具有多個節(jié)點的DOM樹；以及執(zhí)行所述處理步驟作為對所述DOM樹的至少一部分進行修改。23.如權利要求22所述的方法，其中，所述DOM樹包括多個元素節(jié)點，所述分割步驟在與至少一個所述元素節(jié)點相對應的信息的基礎上執(zhí)行。24.如權利要求23所述的方法，其中，與所述元素節(jié)點相對應的所述信息包括命名空間名和元素名的至少其中之一。25.如權利要求23所述的方法，還包括為所述DOM樹中的每個節(jié)點分配至少一個處理部件，以及其中，所述處理步驟包括使用所述分配的處理部件來處理所述DOM樹中的所有節(jié)點。26.如權利要求22所述的方法，其中，將多個編輯處理部件分配給給定節(jié)點，以及對所述給定節(jié)點通過所述多個處理部件執(zhí)行所述處理步驟；以及其中，對所述多個處理部件中的至少一個執(zhí)行所述顯示步驟，而對所述多個處理部件中的至少還有一個不執(zhí)行所述顯示步驟。27.如權利要求21所述的方法，其中，所述分配步驟根據(jù)至少兩個分配標準的其中之一來執(zhí)行。28.如權利要求21所述的方法，其中，至少一個所述處理部件能夠由用戶選擇。29.如權利要求21所述的方法，其中，所述分配步驟基于使資源消耗優(yōu)化的處理部件。30.如權利要求21所述的方法，其中，所述分配步驟基于提供最佳響應性能的編輯處理部件。31.如權利要求21所述的方法，其中，所述分配步驟基于由用戶預先指定的兩個或多個處理部件。32.如權利要求21所述的方法，其中，所述處理步驟包括通過參考DOM樹，用對應的處理部件和不對應的處理部件中的一個處理所述復合文檔的片段。33.如權利要求32所述的方法，其中，多個處理部件相互共享共用部件。34.如權利要求33所述的方法，其中，多個處理部件的所述共用部件可操作以處理撤消步驟。35.如權利要求33所述的方法，其中，多個處理部件的所述共用部件可通過排列命令來操作。36.如權利要求33所述的方法，其中，多個處理部件的所述共用部件可操作以執(zhí)行共用顯示媒介上的聚焦管理和位置管理。37.如權利要求33所述的方法，其中，多個處理部件的所述共用部件可操作以暫停和恢復對復合文檔的處理。38.如權利要求22所述的方法，還包括如果使用所述多個處理部件不能為所有節(jié)點執(zhí)行所述分配步驟，則委派源顯示處理部件處理不具有相應處理部件的節(jié)點。39.如權利要求22所述的方法，還包括如果不能通過所述多個處理部件為所有節(jié)點執(zhí)行所述分配步驟，通過將結構轉換為相應的處理部件不存在的部件執(zhí)行待分配給現(xiàn)存的處理部件的處理。40.如權利要求21所述的方法，還包括至少根據(jù)與所述共用顯示媒介上的當前編輯相對應的處理部件，切換用戶界面的一部分。全文摘要用于對以多種標記語言描述的、通過標簽集且使用插件來表述的文檔進行處理的文檔處理裝置，例如HTML單元和SVG單元。在待處理的文檔以多個標簽集來描述的情況下，文檔選擇能夠在元素名和元素的命名空間基礎上對文檔中所包含的元素進行處理的處理系統(tǒng)。選定的處理系統(tǒng)從所述元素向該元素的子孫元素按順序地確定元素是否能夠處理，處理系統(tǒng)將元素的處理委托給另一處理系統(tǒng)。因此，適當?shù)奶幚硐到y(tǒng)被分配給每個元素。文檔編號G06F17/22GK1947114SQ20058001214公開日2007年4月11日申請日期2005年4月8日優(yōu)先權日2004年4月8日發(fā)明者和家伸明,大島教雄,藤卷祐介,檜山正幸申請人:佳思騰軟件公司