專利名稱：在標(biāo)記語言環(huán)境中利用新片段和新方案來創(chuàng)建新文檔的文檔處理和管理方法
技術(shù)領(lǐng)域：
本發(fā)明涉及以標(biāo)記語言編碼(例如XML)表述的文檔的處理，特別涉及新XML文檔的有效生成。
背景技術(shù)：
概要互聯(lián)網(wǎng)的出現(xiàn)導(dǎo)致由用戶處理和管理的文檔的數(shù)目近乎指數(shù)增長。形成互聯(lián)網(wǎng)核心的萬維網(wǎng)聯(lián)合會(亦即通常所說的Web)包括由這些文檔構(gòu)成的大規(guī)模數(shù)據(jù)中心庫。除了文檔，Web還提供用于這些文檔的信息檢索系統(tǒng)。這些文檔通常為標(biāo)記語言格式，一種簡單且常用的標(biāo)記語言是超文本標(biāo)記語言(HTML)。這種文檔還包括指向可能位于該Web其它部分中的其它文檔的鏈接?？蓴U展標(biāo)記語言(XML)是另一種更高級、更常用的標(biāo)記語言。用于訪問和查看該文檔Web的簡單瀏覽器用(面向?qū)ο蟮?編程語言(例如Java)來開發(fā)。
以標(biāo)記語言為格式的文檔通常在瀏覽器和其它應(yīng)用程序中表述為樹型數(shù)據(jù)結(jié)構(gòu)的格式。這種表述與文檔的語法分析樹相對應(yīng)。文檔對象模型(DOM)是一種眾所周知的用于表述和操作文檔的基于樹的數(shù)據(jù)結(jié)構(gòu)模型。文檔對象模型提供了用于表述文檔的標(biāo)準對象集合，包括HTML和XML文檔。DOM包括兩個基本組件，即，如何將表述文檔中組件的對象進行組合的標(biāo)準模型，以及用于訪問和操作它們的標(biāo)準接口。
應(yīng)用程序開發(fā)者能夠支持DOM作為其自身的特定數(shù)據(jù)結(jié)構(gòu)的接口和應(yīng)用程序接口(API)。另一方面，創(chuàng)建文檔的應(yīng)用程序開發(fā)者可使用標(biāo)準DOM接口而不是使用其自身API的特定接口。因此，由于這種能夠提供標(biāo)準的能力，DOM能有效地增加各種環(huán)境中、尤其是Web上的文檔的互操作性。已經(jīng)定義了DOM的幾種變化，由不同的編程環(huán)境和應(yīng)用程序來使用。
DOM樹是基于相應(yīng)的DOM的內(nèi)容對文檔的分級表述。DOM樹包括“根”以及從根產(chǎn)生的一個或多個“節(jié)點”。在某些情況下，根表述整個文檔。中間節(jié)點可表述元素，諸如表及表中的行和列。DOM樹的“葉子”通常表述數(shù)據(jù)，例如不可進一步分解的文本項目或圖像。DOM樹中的各個節(jié)點可與屬性相關(guān)聯(lián)，屬性描述了由節(jié)點表述的元素的參數(shù)，例如字體、大小、顏色、縮進等。
雖然HTML是一種創(chuàng)建文檔的常用語言，但它是格式和版式語言。HTML不是一種數(shù)據(jù)描述語言。表述HTML文檔的DOM樹的節(jié)點是與HTML格式標(biāo)簽相對應(yīng)的預(yù)先定義的元素。由于HTML通常不提供任何數(shù)據(jù)描述，也不提供任何對數(shù)據(jù)的標(biāo)簽/標(biāo)注，因此，常常難以對HTML文檔中的數(shù)據(jù)進行查詢。
網(wǎng)絡(luò)設(shè)計者的目標(biāo)是使得Web文檔能夠被軟件應(yīng)用程序查詢或處理。獨立顯示的分級組織的語言能夠通過這種方式查詢和處理。諸如XML(可擴展標(biāo)記語言)的標(biāo)記語言能夠提供這些特征。
與HTML相反，眾所周知，XML的優(yōu)點是使得文檔設(shè)計者能夠使用可自由定義的“標(biāo)簽”來對數(shù)據(jù)元素進行標(biāo)注。上述數(shù)據(jù)元素可進行分級組織。另外，XML文檔可包含文檔類型定義(DTD)，它是對文檔中所使用的“語法”(標(biāo)簽及其相互關(guān)系)的描述。使用CSS(層疊樣式表)或XSL(XML樣式語言)，以定義結(jié)構(gòu)化的XML文檔的顯示方法。與DOM、HTML、XML、CSS、XSL有關(guān)的其它信息以及相關(guān)語言特征也可從Web獲取，例如，http://www.w3.org/TR/。
XPath提供了用于對XML文檔的部分進行尋址的公共的語法和語義。所述功能的一個示例是對與XML文檔相對應(yīng)的DOM樹進行遍歷。它提供了用于操作與XML文檔的各種表述相關(guān)聯(lián)的字符串、數(shù)字和布爾字符的基本工具。XPath對XML文檔的摘要、邏輯結(jié)構(gòu)(例如，DOM樹)、而不是其表面語法進行操作。這種表面語法例如可以包括序列中的線位置或字符位置。使用XPath，能夠在分級結(jié)構(gòu)中(例如，在XML文檔的DOM樹中)進行定位。除了用于尋址的用途之外，XPath還被設(shè)計用來測試DOM樹中的節(jié)點是否與某個模式相匹配。
其它涉及XPath的細節(jié)可在http://www.w3.org/TR/XPath中找到。
假設(shè)XML的有益效果和特征已經(jīng)公知，需要一種能夠?qū)?biāo)記語言(例如，XML)構(gòu)建的文檔進行處理的有效的文檔處理和管理系統(tǒng)，并提供一種用于創(chuàng)建和修改這些文檔的友好的用戶界面。
可擴展標(biāo)記語言(XML)特別適合作為用于復(fù)雜文檔的格式，或者特別適合用于這種情況的格式，即，某個文檔的相關(guān)數(shù)據(jù)與其它文檔的數(shù)據(jù)通過網(wǎng)絡(luò)等共用的情況。已經(jīng)開發(fā)出許多用于創(chuàng)建、顯示和編輯XML文檔的應(yīng)用程序(例如，參見日本已公開的專利申請No.2001-290804)。
可隨意地定義詞匯。因此理論上，可能存在無限多個詞匯。然而，不可能單獨提供這些詞匯專用的顯示/編輯環(huán)境。在相關(guān)技術(shù)中，如果以不具有專用編輯環(huán)境的詞匯來描述文檔，那么由文本數(shù)據(jù)構(gòu)成的文檔的源代碼(source)可直接使用文本編輯器等進行編輯。
用于處理和管理XML文檔的現(xiàn)有的應(yīng)用程序具有妨礙其被廣泛接受的顯著的局限性。例如，在某些現(xiàn)有技術(shù)的XML文檔處理系統(tǒng)中，可以看到表達內(nèi)容的XML文檔與其顯示方法無關(guān)的特征。雖然該特征可能在表面上被視為一種優(yōu)勢，但是它實際上是不利的，這是因為用戶不能直接對其進行編輯。為了解決這一問題，某些現(xiàn)有技術(shù)的XML文檔處理系統(tǒng)特別設(shè)計了用于接收XML輸入的屏幕。但是，這種屏幕設(shè)計的靈活性是有限的。這是因為這種XML文檔處理系統(tǒng)的屏幕設(shè)計必須預(yù)先進行硬編碼(hard code)。
由于這一局限性，XSLT作為用于樣式表語言的標(biāo)準之一被開發(fā)。這種技術(shù)能夠?qū)⒂脩魪挠簿幋a工作中釋放出來，并且與顯示XML文檔的可應(yīng)用方法相兼容。然而，利用XSLT，不能夠僅利用XML文檔的顯示版本來實現(xiàn)對該XML文檔的編輯。
此外，現(xiàn)有技術(shù)的XML處理系統(tǒng)依賴于“架構(gòu)(schema)”的設(shè)置。因此，一旦確定了架構(gòu)，那么僅僅那些與來自頂層的架構(gòu)結(jié)構(gòu)相對應(yīng)的XML文檔能夠由處理系統(tǒng)來處理。換言之，這種系統(tǒng)是過度限制性的、硬性(rigid)系統(tǒng)。
在已公開的系統(tǒng)中，不存在上述限制。整個XML文檔的結(jié)構(gòu)不需要硬性確定。通過將具有各種結(jié)構(gòu)的復(fù)合XML文檔分為多個較小的部分，能夠安全地處理該復(fù)合XML文檔。將所述較小的部分單獨分配到編輯模塊，從而能夠獲得更大的靈活性。另外，所述編輯模塊可以優(yōu)選用插件來表述。此外，不受硬編碼限制，用戶能夠?qū)崿F(xiàn)靈活的屏幕設(shè)計。簡言之，可以實現(xiàn)WYSIWYG編輯。
利用被稱作模型-視圖-控制器(Model-View-Controllers，MVC)的眾所周知的圖形用戶界面(GUI)范例，對本文中所描述的系統(tǒng)的某些組件進行描述。所述MVC范例提供了一種將應(yīng)用程序(或甚至是一個應(yīng)用程序的接口)分解為三部分(即，模型、視圖和控制器)的方法。最初開發(fā)MVC是為了將傳統(tǒng)的輸入、處理和輸出任務(wù)映射到GUI領(lǐng)域。
輸入-＞處理-＞輸出控制器-＞模型-＞視圖根據(jù)所述MVC范例，用戶輸入、外界建模、以及對用戶的視覺反饋被分離，并通過模型(M)、視窗(V)以及控制器(C)對象來處理?？刂破骺刹僮饕越忉屳斎?例如用戶的鼠標(biāo)和鍵盤輸入)，并將這些用戶動作映射為發(fā)送至模型和/或視窗的命令，以實現(xiàn)適當(dāng)?shù)母淖?。模型可操作以管理一個或多個數(shù)據(jù)元素、響應(yīng)對其狀態(tài)的詢問、并響應(yīng)指令以改變狀態(tài)。視窗可操作以管理顯示的矩形區(qū)域，并負責(zé)通過圖形和文本的組合將數(shù)據(jù)顯現(xiàn)給用戶。
通常，每個XML文檔必須具有兩個組件XML聲明和根元素。在生成新文檔的過程中，首先必須創(chuàng)建具有適當(dāng)?shù)穆暶骱透氐摹⑿碌目瞻椎腦ML文檔。但是，空XML文檔的生成會遇到重大障礙。首先，完全空的XML文檔是不可能存在的，因為每個文檔必須至少具有根元素，以便被識別為XML文檔。其次，在創(chuàng)建新XML文檔時，需要提供標(biāo)簽或者在形成文檔的框架之后創(chuàng)建標(biāo)簽。再次，與采用標(biāo)記語言(例如XML)書寫的文檔有關(guān)的“命名空間”的使用給根據(jù)根元素被適當(dāng)指派的舊文檔來創(chuàng)建新文檔帶來了問題。標(biāo)記語言將利用詞匯來定義文檔的成分。例如，詞匯可以作為表述XML文檔的DOM樹的子樹出現(xiàn)。“詞匯”是屬于命名空間的一組標(biāo)簽(例如XML標(biāo)簽)。但是，在本領(lǐng)域中可以理解的是，命名空間是唯一的名稱(標(biāo)簽)的集合，因此命名空間中的兩個名稱是不能夠相同的。由于相同名稱的根元素將隨著命名空間的不同而完全不同，因此在一個或多個公共名稱的基礎(chǔ)上，生成具有期望的根元素的文檔是不能夠可靠地實現(xiàn)的。
因此，需要在使用標(biāo)記語言、尤其是XML的文檔處理和管理環(huán)境中，提供容易地、可靠地生成具有期望的根元素的新文檔的能力。

發(fā)明內(nèi)容
本發(fā)明涉及創(chuàng)建至少具有根元素和聲明的新標(biāo)記語言文檔的方法。該方法包括從存儲中檢索新片段標(biāo)記語言文檔，所述新片段標(biāo)記語言文檔包括用于其自身具有根元素的新標(biāo)記語言文件的至少一個標(biāo)記語言模板。然后，選擇至少一個標(biāo)記語言模板，并且利用被選擇的標(biāo)記語言模板來創(chuàng)建標(biāo)記語言文檔。
本發(fā)明進一步涉及一種文檔處理系統(tǒng)，其可操作以向用戶提供創(chuàng)建至少具有根元素和聲明的新標(biāo)記語言文檔的能力。所述文檔處理系統(tǒng)包括至少一個存儲器，用于至少存儲標(biāo)記語言形式的文檔模板，并且所述文檔模板包括根部、聲明和至少相關(guān)的名稱屬性。還包括至少一個處理器，其操作以在指定的名稱屬性的基礎(chǔ)上，搜索存儲器以查找標(biāo)記語言形式的至少一個文檔模板，并且提取出具有一個或多個匹配名稱屬性的一個或多個文檔模板。該系統(tǒng)具有至少一個顯示裝置，用于顯示來自存儲器的文件形式的日記應(yīng)用程序，所述文件為詞匯連接描述符文件，并且包含標(biāo)記語言形式的至少一個候選模板。最后，該系統(tǒng)至少具有用戶輸入，用于使用戶能夠從被顯示的候選模板中選擇文檔模板。
本發(fā)明還包括一種文檔處理裝置，其可操作以向用戶提供創(chuàng)建至少具有根元素和聲明的新標(biāo)記語言文檔的能力。這種裝置具有存儲器，用于至少存儲標(biāo)記語言形式的文檔模板，并且所述文檔模板包括根部、聲明和至少相關(guān)的名稱屬性；以及處理器，其操作以在指定的名稱屬性的基礎(chǔ)上，搜索存儲器以查找標(biāo)記語言形式的至少一個文檔模板，并且提取出具有一個或多個匹配名稱屬性的一個或多個文檔模板。該裝置包括顯示裝置，用于顯示來自存儲器的文件形式的日記應(yīng)用程序，所述文件為詞匯連接描述符文件，并且包含標(biāo)記語言形式的至少一個候選模板；以及用戶輸入，用于使用戶能夠從被顯示的候選模板中選擇文檔模板。
本發(fā)明還包括一種用于創(chuàng)建至少具有根元素和聲明的新標(biāo)記語言文檔的用戶界面。該界面以新片段標(biāo)記語言文檔的顯示的形式嵌入，其中所述新片段標(biāo)記語言文檔包括用于新標(biāo)記語言文件的至少一個標(biāo)記語言模板。還具有用戶輸入，用于檢測所述至少一個標(biāo)記語言模板，其中，所述用戶輸入操作以用于在所述至少一個模板中選擇標(biāo)記語言模板，從而創(chuàng)建標(biāo)記語言文檔。
本發(fā)明的進一步的特征在于一種程序員界面，用于向用戶提供創(chuàng)建至少具有根元素和聲明的新標(biāo)記語言文檔的能力。所述程序員界面具有日記應(yīng)用程序的顯示，其中所述日記應(yīng)用程序具有詞匯連接描述符文件的形式。還具有程序員輸入，用于輸入至少一個新片段，所述至少一個新片段聯(lián)合名稱屬性來表述用于新標(biāo)記語言文件的標(biāo)記語言文檔模板，并且程序員輸入用于存儲至少一個新片段及其相關(guān)的名稱屬性。
本發(fā)明的再一個特征在于一種具有存儲介質(zhì)形式的產(chǎn)品，其中記錄有用于使計算機執(zhí)行用于創(chuàng)建至少具有根元素和聲明的新標(biāo)記語言文檔的方法的程序。所述方法包括檢索新片段標(biāo)記語言文檔，所述新片段標(biāo)記語言文檔包括用于新標(biāo)記語言文件的至少一個標(biāo)記語言模板；以及檢測所述至少一個標(biāo)記語言模板。被檢測的標(biāo)記語言模板被用來創(chuàng)建標(biāo)記語言文檔。


下面參照附圖來詳細描述本發(fā)明的實施方案，在附圖中，相同的參考標(biāo)記指代相同的元件，其中圖1(a)示出了能夠作為所公開的文檔處理和管理系統(tǒng)的一個示例性實現(xiàn)的基礎(chǔ)的組件的傳統(tǒng)結(jié)構(gòu)；圖1(b)-(c)示出了示例性的文檔處理和管理系統(tǒng)的總體方框圖；圖2示出了文檔管理器的示例性實現(xiàn)的進一步細節(jié)；圖3示出了詞匯連接子系統(tǒng)300的示例性實現(xiàn)的進一步細節(jié)；圖4(a)示出了程序調(diào)用器的示例性實現(xiàn)及其與其它組件的關(guān)系的進一步細節(jié)；圖4(b)示出了服務(wù)代理(broker)的示例性實現(xiàn)及其與其它組件的關(guān)系的進一步細節(jié)；圖4(c)示出了服務(wù)的示例性實現(xiàn)的進一步細節(jié)；圖4(d)示出了服務(wù)的實施例；圖4(e)示出了程序調(diào)用器103與用戶應(yīng)用程序106之間的關(guān)系的進一步細節(jié)；圖5(a)提供了載入程序調(diào)用器上的應(yīng)用程序服務(wù)的結(jié)構(gòu)的進一步細節(jié)；圖5(b)示出了框架、菜單欄和狀態(tài)欄之間的關(guān)系的實施例；圖6(a)示出了涉及應(yīng)用程序核心的示例性實現(xiàn)的進一步細節(jié)；圖6(b)示出了涉及快照(snap shot)的示例性實現(xiàn)的進一步細節(jié)；圖7(a)示出了涉及文檔管理器的示例性實現(xiàn)的進一步細節(jié)；圖7(b)示出了一組文檔A-E如何排列為分級結(jié)構(gòu)的實施例；圖7(c)示出了如圖7(b)所示的文檔的分級結(jié)構(gòu)在屏幕上如何顯示的實施例；圖8(a)和8(b)提供了撤消框架和撤消命令的示例性實現(xiàn)的進一步細節(jié)；圖9(a)示出了文檔如何載入如圖1(b)-(c)所示的文檔處理和管理系統(tǒng)中的總體圖；圖9(b)示出了使用MVC范例的區(qū)的結(jié)構(gòu)的概要；圖10示出了文檔及其多種表述的實施例；圖11(a)示出了如圖10所示的文檔的XHTM組件的MV關(guān)系的簡化視圖；圖11(b)示出了用于如圖11(a)所示的文檔的詞匯連接；圖12(a)-12(c)示出了分別涉及插件子系統(tǒng)、詞匯連接與連接器的示例性實現(xiàn)的進一步細節(jié)；圖13示出了用于文件MySampleXML的使用詞匯連接管理器的VCD腳本和連接器工廠樹的實施例；圖14(a)-(c)示出了將示例文檔MySampleXML載入圖1的示例性文檔處理和管理系統(tǒng)中的步驟0-3；圖15示出了將示例文檔MySampleXML載入圖1的示例性文檔處理和管理系統(tǒng)中的步驟4；圖16示出了將示例文檔MySampleXML載入圖1的示例性文檔處理和管理系統(tǒng)中的步驟5；圖17(a)示出了將示例文檔MySampleXML載入圖1(b)的示例性文檔處理和管理系統(tǒng)中的步驟6；圖17(b)示出了將示例文檔MySampleXML載入圖1(b)的示例性文檔處理和管理系統(tǒng)中的步驟7；圖18(a)示出了在不具有相應(yīng)的源節(jié)點而僅依賴于目的樹的節(jié)點上發(fā)生的事件流；圖18(b)示出了在通過TextOfConnector與源節(jié)點相關(guān)的目的樹的節(jié)點上發(fā)生的事件流；圖19(a)是圖解說明在本發(fā)明的示例性環(huán)境中用于工作區(qū)的目錄系統(tǒng)的屏幕截圖；圖19(b)是圖解說明利用片段和/或方案來生成新文檔的步驟的流程圖；圖19(c)是圖解說明程序員采取步驟以設(shè)置一個或多個片段或改變片段的流程圖；
圖20是示例性日記應(yīng)用程序、特別是XML轉(zhuǎn)換腳本(例如包含兩個新片段的詞匯連接描述(VCD)文件)的屏幕截圖；圖21是用于圖20的示例性VCD文件的源代碼的屏幕截圖；以及圖22是在選擇了圖20的兩個新片段中的一個片段之后載入的新文檔的屏幕截圖。
具體實施例方式
下面參照附圖詳細描述本發(fā)明的示例性實施方案。
權(quán)利要求僅表示本發(fā)明的邊界和界限。所討論的實現(xiàn)、實施方案和優(yōu)點僅是示例性的，因而不應(yīng)當(dāng)被解釋成是對本發(fā)明的限制。本發(fā)明的說明書是示意性的，而不是要限制權(quán)利要求的范圍。對本領(lǐng)域的技術(shù)人員來說，許多替換、修改和改變都將是顯而易見的。
圖1(a)圖解說明了能夠作為在本文中隨后詳細描述類型的文檔處理和管理系統(tǒng)的基礎(chǔ)的組件的傳統(tǒng)結(jié)構(gòu)。裝置10包括具有CPU形式或微處理器形式的處理器11，處理器11通過通信路徑13(通常實現(xiàn)為總線)耦合至可為任何當(dāng)前或?qū)砟塬@得的ROM和/或RAM存儲形式的存儲器12。用戶輸入14(例如鼠標(biāo)、鍵盤、語音識別系統(tǒng)或類似設(shè)備)的I/O接口16以及顯示設(shè)備15(或其它用戶接口)也耦合至總線用于與處理器11和存儲器12通信。如本領(lǐng)域所公知的那樣，諸如打印機、通信調(diào)制解調(diào)器等的其它設(shè)備可耦合至該裝置。該裝置可為獨立設(shè)備或者具有將多個終端以及一個或多個服務(wù)器耦合在一起的聯(lián)網(wǎng)形式，或者以本領(lǐng)域公知的多種設(shè)置方式的其中之一。本發(fā)明并不受這些組件的結(jié)構(gòu)、它們的集中式或分布式體系結(jié)構(gòu)或者多種組件的通信方式的限制。
另外，應(yīng)該注意到，本文所討論的系統(tǒng)和示例性實現(xiàn)包括幾種具有多種功能的組件和子組件。應(yīng)該注意到，這些組件和子組件可僅使用硬件、僅使用軟件以及使用硬件和軟件的組合來實現(xiàn)，以提供上述的多種功能。另外，硬件、軟件及其組合可使用通用計算裝置或使用專用硬件或使用通用計算裝置和專用硬件的組合來實現(xiàn)。因此，組件或子組件的結(jié)構(gòu)包括運行特定軟件的通用/專用計算裝置，以提供該組件或子組件的功能。
圖1(b)示出了一種示例性文檔處理和管理系統(tǒng)的總體方框圖。文檔在上述文檔處理和管理系統(tǒng)中被創(chuàng)建和編輯。這些文檔能夠以具有標(biāo)記語言的特征的任何語言來表述(例如XML)。同樣，為方便起見，已經(jīng)創(chuàng)建了用于特定組件和子組件的術(shù)語和名稱。但是，這些不應(yīng)被視作對本文公開的一般教導(dǎo)范圍造成了限制。
所述文檔處理和管理系統(tǒng)可被視為具有兩個基本組件。一個組件是“執(zhí)行環(huán)境”101，它是處理和管理系統(tǒng)運行的環(huán)境。例如，執(zhí)行環(huán)境提供了協(xié)助系統(tǒng)以及用戶對文檔進行處理和管理的基本效用和功能。另一組件是“應(yīng)用程序組件”102，它由在執(zhí)行環(huán)境中運行的應(yīng)用程序構(gòu)成。這些應(yīng)用程序包括文檔本身及其各種表述。
執(zhí)行環(huán)境執(zhí)行環(huán)境101的關(guān)鍵組件是程序調(diào)用器103。程序調(diào)用器103是被訪問以啟動文檔處理和管理系統(tǒng)的基本程序。例如，當(dāng)用戶登錄并啟動文檔處理和管理系統(tǒng)時，程序調(diào)用器103被執(zhí)行。程序調(diào)用器103能夠(例如但并非限制)讀取并處理作為插件增加至文檔處理和管理系統(tǒng)的功能、啟動并運行應(yīng)用程序、以及讀取與文檔相關(guān)的性質(zhì)。當(dāng)用戶希望發(fā)起計劃在執(zhí)行環(huán)境中運行的應(yīng)用程序時，程序調(diào)用器103找到、發(fā)起然后執(zhí)行該應(yīng)用程序。例如，當(dāng)用戶希望對已經(jīng)載入到系統(tǒng)中的文檔進行編輯(它是執(zhí)行環(huán)境中的一種應(yīng)用程序)時，程序調(diào)用器103首先找到該文檔，然后執(zhí)行用于載入和編輯該文檔所必需的功能。
程序調(diào)用器103聯(lián)接至幾個組件，例如插件子系統(tǒng)104、命令子系統(tǒng)105以及資源模塊109。這些組件將隨后進行更詳細描述。
插件子系統(tǒng)插件子系統(tǒng)104是向文檔處理和管理系統(tǒng)增加功能的一種高度靈活和有效的設(shè)備。插件子系統(tǒng)104也能夠被用來修改和去除文檔處理和管理系統(tǒng)中存在的功能。此外，可使用插件子系統(tǒng)增加或修改多種功能。例如，如隨后將詳細描述的那樣，插件子系統(tǒng)可用于增加功能“editlet”，其可操作以有助于在屏幕上呈現(xiàn)文檔。插件editlet也有助于對增加至系統(tǒng)的詞匯進行編輯。
插件子系統(tǒng)104包括服務(wù)代理1041。服務(wù)代理1041管理增加至文檔處理和管理系統(tǒng)的插件，從而代理已增加至文檔處理和管理系統(tǒng)的服務(wù)。
代表期望功能的單個功能以“服務(wù)”1042的形式被增加至系統(tǒng)。服務(wù)1042的可用類型包括但不限于應(yīng)用程序服務(wù)、區(qū)工廠服務(wù)、editlet服務(wù)、命令工廠服務(wù)、連接xpath服務(wù)、CSS計算服務(wù)等。這些服務(wù)及其與系統(tǒng)其余部分的關(guān)系將隨后詳細描述，以更好地理解文檔處理和管理系統(tǒng)。
插件和服務(wù)之間的關(guān)系是，插件是可包括一個或多個服務(wù)提供器的單元，各個服務(wù)提供器具有與之相關(guān)的一個或多個類別的服務(wù)。例如，使用具有適當(dāng)軟件應(yīng)用程序的單個插件，能將多個服務(wù)中的一個服務(wù)增加至系統(tǒng)，從而向系統(tǒng)增加相應(yīng)的功能。
命令子系統(tǒng)命令子系統(tǒng)105被用來執(zhí)行與文檔的處理相關(guān)的命令形式的指令。用戶可通過執(zhí)行一系列指令而執(zhí)行對文檔的操作。例如，通過發(fā)出命令形式的指令，用戶在文檔管理系統(tǒng)中處理XML文檔，并編輯與該XML文檔相對應(yīng)的XML DOM樹。這些命令可利用鍵盤敲打、鼠標(biāo)點擊或其它有效的用戶接口動作而輸入。有時，能夠通過命令來執(zhí)行一個以上的指令。在這種情況下，這些指令被封裝成單個命令并連續(xù)執(zhí)行。例如，用戶可能希望將錯誤詞語替換為正確詞語。在這種情況下，第一指令可用以在文檔中找尋錯誤詞語。第二指令可用以刪除該錯誤詞語。第三指令可用以輸入正確詞語。這三個指令可被封裝成單個命令。
在某些示例中，命令可具有相關(guān)功能，例如，下面將要詳細討論的“撤消”功能。這些功能可隨后分配給用來創(chuàng)建對象的基類。
命令子系統(tǒng)105的一個組件是命令調(diào)用器1051，命令調(diào)用器1051可操作為選擇性地提供并執(zhí)行命令。雖然圖1(b)中僅示出了一個命令調(diào)用器，但也可使用一個以上的命令調(diào)用器并同時執(zhí)行一個以上的命令。命令調(diào)用器1051維護執(zhí)行命令所需的功能和類。在操作中，要執(zhí)行的命令1052被置于隊列1053中。命令調(diào)用器創(chuàng)建連續(xù)執(zhí)行的命令線程。如果在命令調(diào)用器中沒有正在執(zhí)行的命令，則由命令調(diào)用器1051執(zhí)行待執(zhí)行的命令1052。如果命令調(diào)用器正在執(zhí)行命令，則新的命令被置于命令隊列1053的末尾。不過，對于各命令調(diào)用器1051而言，一次僅執(zhí)行一個命令。如果指定的命令執(zhí)行失敗，則命令調(diào)用器1051執(zhí)行命令異常。
可由命令調(diào)用器1051執(zhí)行的命令的類型包括但不限于可撤消命令1054、異步命令1055以及詞匯連接命令1056。可撤消命令1054是那些如果用戶希望就能夠回退其效果的命令。可撤消命令的示例為剪切、復(fù)制、插入文本等。在操作中，當(dāng)用戶突出文檔的一部分并向該部分應(yīng)用剪切命令時，如果需要，通過使用可撤消命令，可使得被剪切的部分“恢復(fù)原樣(uncut)”。
詞匯連接命令1056被載入詞匯連接描述符腳本文件中。詞匯連接命令1056是能夠由程序員定義的用戶指定命令。這些命令可以是更抽象命令的組合，例如，用于增加XML片段、刪除XML片段、設(shè)置屬性等。這些命令特別涉及對文檔進行編輯。
異步命令1055是用于載入或保存由系統(tǒng)執(zhí)行的文檔的命令。異步命令1055與可撤消命令或VC命令異步地執(zhí)行。與可撤消命令不同，異步命令不能被取消。
異步命令1055的級別低于所述詞匯連接命令的級別。所述異步命令是對于所述文檔處理和管理系統(tǒng)更具體的命令。異步命令被直接記入到命令調(diào)用器1051。另一方面，將詞匯連接命令1056解釋和轉(zhuǎn)換為異步命令，然后再將所述異步命令記入到命令調(diào)用器1051。
資源資源109是向不同的類提供某些功能的對象。例如，串資源、圖標(biāo)和設(shè)定鍵綁定是系統(tǒng)中使用的資源。
應(yīng)用程序組件應(yīng)用程序組件102，即文檔處理系統(tǒng)的第二個主要特征，在執(zhí)行環(huán)境101中運行。概括而言，應(yīng)用程序組件102包括實際文檔，實際文檔包括其在系統(tǒng)內(nèi)的多個邏輯和物理表述。應(yīng)用程序組件102還包括系統(tǒng)的、用來管理文檔的組件。應(yīng)用程序組件102進一步包括用戶應(yīng)用程序106、應(yīng)用程序核心108、用戶界面107以及核心組件110。
用戶應(yīng)用程序用戶應(yīng)用程序106連同程序調(diào)用器103一起被載入到系統(tǒng)中。用戶應(yīng)用程序106是將文檔、文檔的多種表述以及與文檔進行交互所需的用戶界面特征結(jié)合在一起的粘合劑(glue)。例如，用戶可能希望創(chuàng)建作為工程(project)一部分的一套文檔。載入這些文檔，創(chuàng)建用于文檔的適當(dāng)表述，增加作為用戶應(yīng)用程序106一部分的用戶界面功能。換言之，用戶應(yīng)用程序106將文檔及其表述的各個方面結(jié)合在一起使得用戶能夠與形成工程一部分的文檔進行交互。一旦創(chuàng)建了用戶應(yīng)用程序106，每當(dāng)用戶希望與形成工程一部分的文檔進行交互時，用戶就能夠簡單地將用戶應(yīng)用程序106載入到執(zhí)行環(huán)境中。
核心組件核心組件110提供了在多個窗格之間共享文檔的一種方法。如將在隨后詳細討論的那樣，窗格表述DOM樹，并處理屏幕的物理布局。例如，物理屏幕包括在屏幕內(nèi)的多個窗格用于描述各條信息。實際上，由用戶在屏幕上查看的文檔可在一個或多個窗格中顯示。此外，兩個不同的文檔可以出現(xiàn)在屏幕上的兩個不同窗格中。
屏幕的物理布局還可以具有樹型形式，如圖1(c)所示。因此，如果組件1083要作為窗格顯示在屏幕上，則該窗格可被實現(xiàn)為根窗格1084。作為一種選擇，它也可以是子窗格1085。根窗格1084是窗格樹根部的窗格，而子窗格1085是除了根窗格1084之外的任何窗格。
核心組件110也提供字體，并充當(dāng)用于文檔的多個功能性操作的源，例如，工具包(toolkit)。由核心組件110執(zhí)行的任務(wù)的一個示例是在多個窗格之間移動鼠標(biāo)光標(biāo)。被執(zhí)行的任務(wù)的另一個示例是標(biāo)記一個窗格中的文檔的一部分，并將其復(fù)制到包含不同文檔的另一窗格上。
應(yīng)用程序核心如上所述，應(yīng)用程序組件102由被系統(tǒng)處理和管理的文檔組成。應(yīng)用程序組件102包括對于系統(tǒng)內(nèi)的文檔的多種邏輯和物理表述。應(yīng)用程序核心108是應(yīng)用程序組件102的組件。其功能是保持實際文檔及其內(nèi)的所有數(shù)據(jù)。應(yīng)用程序核心108包括文檔管理器1081和文檔1082本身。
文檔管理器1081的多個方面將在隨后進行更詳細的描述。所述文檔管理器管理文檔1082。所述文檔管理器也連接至根窗格1084、子窗格1085、剪貼板實用程序1086以及快照實用程序1087。剪貼板實用程序1086提供了保持用戶決定增加至剪貼板的部分文檔的一種方法。例如，用戶可能希望剪切文檔的一部分，并將其保存到新的文檔上，用于稍后查看。在這種情況下，剪切的部分被增加至剪貼板。
快照實用程序1087也將在稍后描述，從而當(dāng)應(yīng)用程序從一個狀態(tài)變?yōu)榱硪粻顟B(tài)時，能夠記住應(yīng)用程序的當(dāng)前狀態(tài)。
用戶界面應(yīng)用程序102的另一組件是用戶界面107，其為用戶提供一種與系統(tǒng)進行物理交互的方式。例如，以物理接口1070來實現(xiàn)用戶界面時，用戶使用用戶界面上載、刪除、編輯和管理文檔。用戶界面包括框架1071、菜單欄1072、狀態(tài)欄1073以及URL欄1074。
如通常公知的那樣，框架可被視為物理屏幕的活動區(qū)域。菜單欄1072是屏幕的、包括為用戶提供選項的菜單的區(qū)域。狀態(tài)欄1073是屏幕的、顯示應(yīng)用程序的執(zhí)行狀態(tài)的區(qū)域。URL欄1074提供了輸入用于在互聯(lián)網(wǎng)上定位的URL地址的區(qū)域。
文檔管理器和相關(guān)的數(shù)據(jù)結(jié)構(gòu)圖2示出了文檔管理器1081的進一步細節(jié)。圖2包括被用來在文檔處理和管理系統(tǒng)內(nèi)表述文檔的數(shù)據(jù)結(jié)構(gòu)和組件。為了更好的理解，在這部分描述的組件通過利用模型-視圖-控制器(MVC)表述范例來進行描述。
文檔管理器1081包括文檔容器(containter)203，文檔容器203保持并容納文檔處理和管理系統(tǒng)中的所有文檔。聯(lián)接至文檔管理器1081的工具包201為文檔管理器1081的使用提供了各種工具。例如，“DOM服務(wù)”是由工具包201提供的能夠提供創(chuàng)建、維護和管理與文檔相對應(yīng)的DOM所需的所有功能的工具。作為工具包201提供的另一工具的“IO管理器”分別管理向系統(tǒng)的輸入和來自系統(tǒng)的輸出。同樣地，“流處理器”是一種以比特流方式來處理文檔上載的工具。這些工具形成了工具包201的組件，不過并未在圖中明確示出或指定附圖標(biāo)記。
根據(jù)MVC范例表述，模型(M)包括文檔的DOM樹模型202。如上所述，所有文檔均在文檔處理和管理系統(tǒng)中被表述為DOM樹。文檔也形成文檔容器203的一部分。
DOM模型和區(qū)DOM是由W3C構(gòu)建的標(biāo)準。DOM標(biāo)準定義了用于對節(jié)點進行操作的標(biāo)準接口。在每個詞匯或每個節(jié)點的基礎(chǔ)上，在所述標(biāo)準內(nèi)提供了特定的操作。這些操作優(yōu)選地被提供為API。文檔處理/管理系統(tǒng)提供了這種作為“方面(facet)”的節(jié)點特定API。每個“方面”都聯(lián)接到節(jié)點。通過將這種“方面”連接到節(jié)點，提供了符合DOM標(biāo)準的有用的API。通過在已應(yīng)用的標(biāo)準DOM之上增加特定的API而不是為每個詞匯實現(xiàn)特定的DOM，可集中處理多種詞匯，并且可以正確地處理其中采用詞匯的任意組合的文檔。通常，DOM可以被示意性地表述為DOM樹。
表述文檔的DOM樹是具有節(jié)點2021的樹。作為DOM樹的子集的區(qū)209包括該DOM樹內(nèi)部的一個或多個所關(guān)注的節(jié)點。例如，僅文檔的一部分可在屏幕上顯現(xiàn)。文檔可見的這一部分可使用“區(qū)”209來表述。利用被稱作“區(qū)工廠”205的插件來創(chuàng)建、操作和處理區(qū)。雖然區(qū)表述DOM的一部分，但它也可使用一個以上的“命名空間”。如本領(lǐng)域中公知的那樣，命名空間是名稱的匯集或集合，這些名稱在該命名空間中是唯一。換言之，一個命名空間中不能夠出現(xiàn)兩個相同的名稱。
“方面”及其與區(qū)的關(guān)系“方面”2022是MVC范例的模型(M)部分內(nèi)的另一組件。它被用來編輯區(qū)中的節(jié)點?！胺矫妗?022使用不會影響區(qū)本身的內(nèi)容的執(zhí)行過程來組織對于DOM的訪問。如以下將說明的那樣，這些過程執(zhí)行與節(jié)點相關(guān)的有意義且有用的操作。
各個節(jié)點2021具有相應(yīng)的2022。通過利用“方面”來執(zhí)行操作而不是直接對DOM中的節(jié)點進行操作，DOM的完整性得以確保。否則，如果直接對節(jié)點執(zhí)行操作，那么幾個插件可能同時對DOM進行改變，從而造成不一致性。
“詞匯”是屬于命名空間的標(biāo)簽(例如XML標(biāo)簽)的集合。如上所述，命名空間具有唯一的名稱集(在該特定情況下為標(biāo)簽集)。詞匯表現(xiàn)為表述XML文檔的DOM樹的子樹。這種子樹包括區(qū)。在特定實施例中，標(biāo)簽集的邊界由區(qū)來限定。區(qū)209是利用被稱作“區(qū)工廠服務(wù)”205的服務(wù)而創(chuàng)建的。如上所述，區(qū)209是對表述文檔的DOM樹的一部分的內(nèi)部表述。為了提供對該文檔的上述部分的訪問，需要邏輯表述。這種邏輯表述通知計算機關(guān)于文檔如何在屏幕上進行邏輯顯示?！爱嫴肌?10是一種可操作為提供與區(qū)相對應(yīng)的邏輯布局的服務(wù)。
另一方面，窗格(例如窗格211)是與由畫布210提供的邏輯布局相對應(yīng)的物理屏幕布局。實際上，用戶僅能看見以字符和圖片形式呈現(xiàn)在顯示屏上的文檔。因此，文檔必須通過用于在屏幕上描繪字符和圖片的處理來呈現(xiàn)在屏幕上。根據(jù)由窗格211提供的物理布局，文檔由畫布210呈現(xiàn)在屏幕上。
與區(qū)209相對應(yīng)的畫布210是利用“editlet服務(wù)”206來創(chuàng)建的。文檔的DOM是利用editlet服務(wù)206和畫布210來編輯的。為了維護原始文檔的完整性，editlet服務(wù)206和畫布服務(wù)210使用與區(qū)209中的一個或多個節(jié)點相對應(yīng)的“方面”。這些服務(wù)并不直接操作區(qū)和DOM中的節(jié)點?！胺矫妗笔抢脕碜訫VC范例的(C)組件(即控制器)的命令207來操作的。
用戶通常通過例如移動屏幕上的光標(biāo)和/或鍵入命令而與屏幕進行交互。提供屏幕的邏輯布局的畫布2010接收這些光標(biāo)操作。然后，畫布2010使得對“方面”采取相應(yīng)的動作。給定這一關(guān)系，光標(biāo)子系統(tǒng)204即作為用于文檔管理器1081的MVC范例的控制器(C)。
畫布2010也具有處理事件的任務(wù)。例如，畫布2010處理諸如鼠標(biāo)點擊、焦點移動和類似的用戶發(fā)起的動作等事件。
區(qū)、“方面”、畫布和窗格之間的關(guān)系概述文檔管理和處理系統(tǒng)內(nèi)的文檔可從至少四個角度來觀察，即1)用來保持文檔管理系統(tǒng)中的文檔的內(nèi)容和結(jié)構(gòu)的數(shù)據(jù)結(jié)構(gòu)；2)不會影響文檔完整性就能編輯文檔內(nèi)容的方式；3)文檔在屏幕上的邏輯布局；以及4)文檔在屏幕上的物理布局。區(qū)、“方面”、畫布和窗格分別表述與上述四個方面相對應(yīng)的文檔管理系統(tǒng)的組件。
撤消系統(tǒng)如上所述，人們希望對文檔的任何改變(例如，編輯)應(yīng)該是可撤消的。例如，用戶可執(zhí)行編輯操作，然后決定撤消該改變。參照圖2，撤消子系統(tǒng)212是文檔管理器的可撤消組件。撤消管理器2121保存可能被用戶撤消的、對文檔執(zhí)行的所有操作。例如，用戶可執(zhí)行命令來將文檔中的詞匯替換成另一個詞語。之后，該用戶可改變主意并決定保留原來的詞語。撤消子系統(tǒng)212協(xié)助上述操作。撤消管理器2121保存上述可撤消編輯2122的操作。
光標(biāo)子系統(tǒng)如上所述，MVC的控制器部分可包括光標(biāo)子系統(tǒng)204。該光標(biāo)子系統(tǒng)204從用戶處接收輸入。這些輸入通常具有命令和/或編輯操作的性質(zhì)。因此，光標(biāo)子系統(tǒng)204可被視作是與文檔管理器1081相關(guān)的MVC范例的控制器(C)部分。
視圖如上所述，畫布2010表述要顯現(xiàn)在屏幕上的文檔的邏輯布局。對于XHTML文檔的特定實施例而言，畫布可包括盒樹(box tree)，該盒樹是文檔在屏幕上如何被查看的邏輯表述。上述盒樹可包含在與文檔管理器1081有關(guān)的MVC范例的視圖(V)部分中。
詞匯連接文檔處理管理系統(tǒng)的一個重要特征是，能夠以兩種不同的方式(例如，以兩種標(biāo)記語言)來表述和顯示文檔，從而使得兩種不同的表述自動保持一致。
標(biāo)記語言文檔(例如XML文檔)基于通過文檔類型定義限定的詞匯創(chuàng)建。詞匯則是一組標(biāo)簽集，并可以任意定義，這就使得詞匯的數(shù)量可能是無限的。但是，為多個可能的詞匯中的每一個都提供專用的單獨處理和管理環(huán)境是不切實際的。詞匯連接是解決這種問題的一種方式。
例如，文檔可以利用兩種或更多標(biāo)記語言來表述。這些文檔例如可以是XHTML(可擴展超文本標(biāo)記語言)、SVG(可縮放矢量圖形)、MathML(數(shù)學(xué)標(biāo)記語言)或其他的標(biāo)記語言。換句話說，標(biāo)記語言可以視為和XML中的詞匯和標(biāo)簽集相同。
詞匯可以使用詞匯插件來實現(xiàn)。在文檔處理和管理系統(tǒng)中，以插件不可用的詞匯所描述的文檔可以通過將該文檔映射為插件可用的另一詞匯來顯示。因此，以非插件的詞匯描述的文檔仍然是可以正確顯示的。
詞匯連接包括獲取定義文件、在定義文件之間進行映射、以及生成定義文件的能力。用某種詞匯描述的文檔能夠映射為另外的詞匯。因此，詞匯連接提供了通過與文檔已被映射成的詞匯相對應(yīng)的顯示和編輯插件來顯示或編輯文檔的能力。
應(yīng)該認識到，各個文檔在文檔處理和管理系統(tǒng)中被描述為通常具有多個節(jié)點的DOM樹。“定義文件”為各個節(jié)點描述了該節(jié)點與其他節(jié)點之間的連接。規(guī)定了是否可以對各個節(jié)點的元素值和屬性值進行編輯。還描述了使用節(jié)點的元素值和屬性值的運算表達式。
利用映射特征，通過參考定義文件創(chuàng)建目的DOM樹。因此，源DOM樹和目的DOM樹之間的關(guān)系被建立并維護。詞匯連接監(jiān)控源DOM樹和目的DOM樹之間的連接。在從用戶接收到編輯指令后，詞匯連接修改源DOM樹中的相關(guān)節(jié)點。發(fā)出表示已經(jīng)修改了源DOM樹的“變化事件”，并且相應(yīng)地修改目的DOM樹。
通過使用詞匯連接，僅對于少量用戶熟知的相對次要的詞匯可以被轉(zhuǎn)換為其他主要的詞匯。因此，即便是對于那些僅有少量用戶使用的次要詞匯，也可以準確地顯示文檔，并提供理想的編輯環(huán)境。
因此，作為文檔管理系統(tǒng)一部分的詞匯連接子系統(tǒng)提供了能夠?qū)ξ臋n進行多種表述的功能。
圖3顯示了詞匯連接(VC)子系統(tǒng)300。VC子系統(tǒng)提供了一種維護同一文檔的兩種可替換表述之間的一致性的方式。在圖中具有與上面描述和標(biāo)識相同的組件，這些組件相互連接從而實現(xiàn)上述目的。例如，兩種表述可以是同一文檔以兩種不同詞匯實現(xiàn)的可替換表述。如上所述，其中一種可以是源DOM樹，而另一種是目DOM樹。
詞匯連接子系統(tǒng)利用被稱為“詞匯連接”301的插件在文檔處理和管理系統(tǒng)中實現(xiàn)詞匯連接子系統(tǒng)300的功能。將被表述的文檔的各詞匯305都需要相應(yīng)的插件。例如，如果文檔的一部分以HTML表述，而其他部分以SVG表述，則需要相應(yīng)的HTML詞匯插件和SVG詞匯插件。
詞匯連接插件301為區(qū)209或窗格211創(chuàng)建與適當(dāng)詞匯305的文檔相對應(yīng)的適當(dāng)?shù)脑~匯連接畫布310。使用詞匯連接301，利用轉(zhuǎn)換規(guī)則，對源DOM樹的區(qū)209的改變被轉(zhuǎn)換到另一DOM樹306的相應(yīng)區(qū)。轉(zhuǎn)換規(guī)則以詞匯連接描述符(VCD)的形式給出。對于與源和目的DOM之間的這種轉(zhuǎn)換相對應(yīng)的各個VCD文件，創(chuàng)建相應(yīng)的詞匯連接管理器302。
連接器連接器304連接源DOM樹中的源節(jié)點和目的DOM樹中的目的節(jié)點。連接器304可操作以觀察源DOM樹中的源節(jié)點，和與該源節(jié)點相對應(yīng)的、對源文檔的修改(變化)。接著，連接器304修改相應(yīng)的目的DOM樹中的節(jié)點。只有連接器304是能夠修改目的DOM樹的對象。例如，如果用戶僅能夠?qū)υ次臋n和相應(yīng)的源DOM樹進行修改，則連接器304對目的DOM樹進行相應(yīng)的修改。
連接器304被邏輯地鏈接在一起以形成樹結(jié)構(gòu)。連接器304形成的樹被稱為“連接器樹”。連接器304通過一種服務(wù)而創(chuàng)建，該服務(wù)被稱為“連接器工廠”303服務(wù)。連接器工廠303從源文檔創(chuàng)建連接器304，并將連接器304以連接器樹的形式鏈接起來。詞匯連接管理器302維護連接器工廠303。
如上所述，詞匯是命名空間中的標(biāo)簽集。如圖3所示，通過詞匯連接301為文檔創(chuàng)建詞匯305。這通過分析文檔文件以及為源DOM和目的DOM之間的轉(zhuǎn)換創(chuàng)建適當(dāng)?shù)脑~匯連接管理器302來實現(xiàn)。此外，在創(chuàng)建連接器的連接器工廠303、創(chuàng)建區(qū)209的區(qū)工廠服務(wù)205和創(chuàng)建與區(qū)中的節(jié)點相對應(yīng)的畫布的editlet服務(wù)206之間建立適當(dāng)?shù)年P(guān)聯(lián)。當(dāng)用戶從系統(tǒng)中除去或刪除文檔時，對應(yīng)的詞匯連接管理器302被刪除。
詞匯305接著創(chuàng)建詞匯連接畫布。此外，連接器304和目的DOM樹306被相應(yīng)地創(chuàng)建。
應(yīng)該理解，源DOM和畫布分別對應(yīng)于模型(M)和視圖(V)。然而，僅當(dāng)目標(biāo)詞匯能夠在屏幕上呈現(xiàn)時，這種呈現(xiàn)才有意義。這種顯示通過詞匯插件來實現(xiàn)。詞匯插件提供用于主要的詞匯，例如XHTML、SVG和MathML。詞匯插件相對于目標(biāo)詞匯使用。它們提供了一種使用詞匯連接描述符在詞匯之間進行映射的方式。
僅在目標(biāo)詞匯可被映射并具有預(yù)定的屏幕呈現(xiàn)方式時，這種映射才有意義。這種呈現(xiàn)方式為工業(yè)標(biāo)準，例如由諸如W3C組織定義的XHTML。
在需要詞匯連接時，使用詞匯連接畫布。在這種情況下，由于不能夠為源直接創(chuàng)建視圖，因此，不創(chuàng)建源畫布。在這種情況下，使用連接器樹來創(chuàng)建詞匯連接畫布。這種詞匯連接畫布僅僅處理事件轉(zhuǎn)換，而并不會有助于將文檔呈現(xiàn)在屏幕上。
目的區(qū)、窗格以及畫布如上所述，詞匯連接子系統(tǒng)的目的在于創(chuàng)建并同時維護對同一文檔的兩種替換表述。第二替換表述還可以是先前被引入作為目的DOM樹的DOM樹形式。為了瀏覽第二種表述的文檔，需要目的區(qū)、畫布和窗格。
在創(chuàng)建詞匯連接畫布后，創(chuàng)建相應(yīng)的目的窗格307。此外，相關(guān)的目的畫布308和相應(yīng)的盒樹309被創(chuàng)建。同樣，詞匯連接畫布還與源文檔的窗格211和區(qū)209關(guān)聯(lián)。
目的畫布308提供了文檔的第二種表述方式的邏輯布局。具體地，目的畫布308提供了用戶界面功能，例如光標(biāo)和選擇(selection)，用于以目的表述的方式呈現(xiàn)文檔。在目的畫布308中發(fā)生的事件被提供到連接器。目的畫布308向連接器304通知鼠標(biāo)事件、鍵盤事件、拖動和放置事件、以及通知文檔的目的(或第二種)表述的詞匯的特有事件。
詞匯連接命令子系統(tǒng)圖3中的詞匯連接子系統(tǒng)300的一部分是詞匯連接命令子系統(tǒng)313。詞匯連接命令子系統(tǒng)313創(chuàng)建詞匯連接命令315，詞匯連接命令315用來執(zhí)行與詞匯連接子系統(tǒng)300相關(guān)的指令?？赏ㄟ^內(nèi)建的命令模板3131來創(chuàng)建詞匯連接命令，和/或可通過在腳本系統(tǒng)314中使用腳本語言從無到有地創(chuàng)建命令而創(chuàng)建詞匯連接命令。
命令模板的例子包括“If”命令模板、“When”命令模板、“Insertfragment”命令模板等。這些模板被用來創(chuàng)建詞匯連接命令。
XPath子系統(tǒng)XPath子系統(tǒng)316是文檔處理和管理系統(tǒng)的一個關(guān)鍵組件，因為它有助于實現(xiàn)詞匯連接。連接器304通常包括XPath信息。如上所述，詞匯連接的任務(wù)是將源DOM樹中的變化反映到目的DOM樹中。XPath信息包括一個或多個用來確定源DOM樹中需要被觀察以確定改變/修改的子集的XPath表達式。
源DOM樹、目的DOM樹和連接器樹的概述源DOM樹是對轉(zhuǎn)換為另一種詞匯之前以一種詞匯表述的文檔進行表述的DOM樹或區(qū)。在源DOM樹中的節(jié)點被稱為源節(jié)點。
另一方面，目的DOM樹則表示用于在利用映射進行轉(zhuǎn)換之后以另一種詞匯表述的同一文檔的DOM樹或區(qū)，該映射已在前面結(jié)合詞匯連接描述。目的DOM樹中的節(jié)點被稱為目的節(jié)點。
連接器樹是基于連接器的分級表述，用來表述源節(jié)點和目的節(jié)點之間的連接。連接器觀察源節(jié)點和對源文檔進行的修改。連接器隨后修改目的DOM樹。事實上，只有連接器是能夠修改目的DOM樹的對象。
文檔處理和管理系統(tǒng)中的事件流為了能夠使用，程序必需對來自用戶的命令進行響應(yīng)。事件是一種描述和執(zhí)行用戶對程序?qū)嵤┑膭幼鞯姆绞?。許多高級語言例如JAVA依靠描述用戶動作的事件。在現(xiàn)有技術(shù)中，程序不得不主動收集用于理解用戶動作和通過自身執(zhí)行用戶動作的信息。這可能意味著，例如，在對程序初始化后，程序進入重復(fù)地查看用戶是否對屏幕、鍵盤和鼠標(biāo)等執(zhí)行了任何動作、并接著采取適當(dāng)動作的循環(huán)。然而，這種處理可能難以操控。此外，這種處理在等候用戶作某些事情時，還需要執(zhí)行循環(huán)的程序，從而消耗了CPU周期。
許多語言通過包含不同的范例來解決這些問題，其中的一個范例構(gòu)成了所有現(xiàn)代的window系統(tǒng)的基礎(chǔ)事件驅(qū)動程序。在這種范例中，所有的用戶動作屬于被稱為“事件”的事務(wù)的抽象集合。一種事件足夠詳細地描述了特殊的用戶動作。在感興趣的事件發(fā)生時，這種系統(tǒng)通知程序，而不是程序主動地收集用戶生成的事件。以這種方式處理用戶交互的程序被稱為“事件驅(qū)動”。
這通常使用事件類來進行處理，其中事件類捕獲了所有用戶生成事件的基礎(chǔ)特性。
文檔處理和管理系統(tǒng)定義和使用其自身的事件以及處理這些事件的方式。幾種類型的事件被使用。例如，鼠標(biāo)事件是來自用戶的鼠標(biāo)動作的事件。與鼠標(biāo)有關(guān)的用戶動作由畫布210傳遞到鼠標(biāo)事件。因此，畫布可以被認為是用戶與系統(tǒng)交互的最前沿。如果需要，最前沿的畫布將把其與事件有關(guān)的內(nèi)容傳遞到其下級(children)。
另一方面，按鍵事件從畫布210產(chǎn)生。按鍵事件具有瞬時的焦點，即，按鍵事件涉及任意瞬時的活動。進入到畫布210的按鍵事件接著被傳遞到其上級(parent)。鍵盤輸入通過能夠處理字符串插入的不同事件而被處理。在使用鍵盤插入字符時，將觸發(fā)處理字符串插入的事件。其他的“事件”包括例如拖動事件、放置事件和其他能夠以與鼠標(biāo)事件相似的方式處理的事件。
在詞匯連接之外處理事件使用事件線程對事件進行傳遞。在接收到事件后，畫布210改變其狀態(tài)。如果需要，畫布210將命令1052記入到命令隊列1053。
在詞匯連接之內(nèi)處理事件通過使用詞匯連接插件301，目的畫布1106接收現(xiàn)有的事件，例如鼠標(biāo)事件、鍵盤事件、拖動和放置事件、以及詞匯的特有事件。這些事件接著被通知到連接器1104。更具體地說，詞匯連接插件301內(nèi)的事件流經(jīng)過源窗格1103、詞匯畫布1104、目的窗格1105、目的畫布1106、目的DOM樹和連接器樹1104，如圖11所示。
程序調(diào)用器及其與其他組件之間的關(guān)系在圖4(a)中更加詳細地顯示了程序調(diào)用器103及其與其他組件之間的關(guān)系。程序調(diào)用器103是在執(zhí)行環(huán)境中被執(zhí)行以啟動文檔處理和管理系統(tǒng)的基本程序。用戶應(yīng)用程序106、服務(wù)代理1041、命令調(diào)用器1051和資源109都被聯(lián)接到程序調(diào)用器103，如圖1B所示。如前所述，應(yīng)用程序102是在執(zhí)行環(huán)境中運行的組件。同樣，服務(wù)代理1041管理向系統(tǒng)增加各種功能的插件。另一方面，命令調(diào)用器1051維護用來執(zhí)行命令的類和函數(shù)，從而執(zhí)行用戶提供的指令。
插件和服務(wù)下面將參照圖4(b)詳細描述服務(wù)代理1041。如上所述，服務(wù)代理1041管理向系統(tǒng)增加各種功能的插件(及相關(guān)服務(wù))。服務(wù)1042在最底層，在該層中可以將特征增加到文檔處理和管理系統(tǒng)，或改變該系統(tǒng)中的特征?！胺?wù)”由兩部分構(gòu)成服務(wù)種類401和服務(wù)提供器402。如圖4(c)所示，單個的服務(wù)種類401可具有多個相關(guān)的服務(wù)提供器402，這些多個服務(wù)提供器402中的每一個都可操作以執(zhí)行所有或部分的特定服務(wù)種類。另一方面，服務(wù)種類401則定義了服務(wù)的類型。
服務(wù)可分為三種類型1) 向系統(tǒng)提供特定特征的特征服務(wù)；2)應(yīng)用程序服務(wù)，其是由文檔處理和管理系統(tǒng)運行的應(yīng)用程序；以及3)提供在整個文檔處理和管理系統(tǒng)中需要的特征的環(huán)境服務(wù)。
圖4(d)中示出了服務(wù)的例子。根據(jù)應(yīng)用程序服務(wù)的種類，系統(tǒng)實用程序是相應(yīng)服務(wù)提供器的示例。同樣，editlet 206是一個種類，HTML editlet和SVG editlet是相應(yīng)的服務(wù)提供器。區(qū)工廠205是服務(wù)的另一種，并具有相應(yīng)的服務(wù)提供器(未示出)。
之前描述的向文檔處理和管理系統(tǒng)增加功能的插件可以看作是由幾個服務(wù)提供器402和與其相關(guān)的類構(gòu)成的單元，如圖4(c)和4(d)所示。各個插件都應(yīng)該具有在清單文件(manifest file)中寫入的從屬和服務(wù)種類。
程序調(diào)用器和應(yīng)用程序之間的關(guān)系圖4(e)詳細顯示了程序調(diào)用器103和用戶應(yīng)用程序106之間的關(guān)系。所需的文檔、數(shù)據(jù)等從存儲中載入。所有需要的插件載入到服務(wù)代理1041。服務(wù)代理1041管理并維護所有的插件。可物理地將插件增加到系統(tǒng)，或者可從存儲中載入其功能。在載入插件的內(nèi)容后，服務(wù)代理1041定義相應(yīng)的插件。相應(yīng)的用戶應(yīng)用程序106被創(chuàng)建，接著被載入到執(zhí)行環(huán)境101并聯(lián)接到程序調(diào)用器103。
應(yīng)用程序服務(wù)和環(huán)境之間的關(guān)系圖5(a)進一步示出了載入程序調(diào)用器103中的應(yīng)用程序服務(wù)的結(jié)構(gòu)。作為命令子系統(tǒng)105組件的命令調(diào)用器1051調(diào)用或執(zhí)行程序調(diào)用器103內(nèi)的命令1052。命令1052則是用來在文檔處理和管理系統(tǒng)中處理文檔(例如，XML文檔)和編輯相應(yīng)的XML DOM樹的指令。命令調(diào)用器1051維護執(zhí)行命令1052所需的功能和類。
服務(wù)調(diào)用器1041也在程序調(diào)用器103中執(zhí)行。用戶應(yīng)用程序106連接到用戶界面107和核心組件110。核心組件110提供了一種在所有的窗格中共享文檔的方式。核心組件110還提供字體并作為用于窗格的工具包。
圖5(a)和5(b)顯示了框架1071、菜單欄1072和狀態(tài)欄1073之間的關(guān)系。
應(yīng)用程序核心圖6(a)進一步解釋了應(yīng)用程序核心110，其保持所有文檔以及作為文檔一部分并屬于文檔的數(shù)據(jù)。應(yīng)用程序核心110聯(lián)接到管理文檔1082的文檔管理器1081。文檔管理器1081是存儲到與文檔處理和管理系統(tǒng)關(guān)聯(lián)的存儲器中的所有文檔1082的所有者(proprietor)。
為了便于在屏幕上顯示文檔，文檔管理器1081還連接到根窗格1084。剪貼板1086、快照1087、拖拉和放置601，覆蓋602的功能也被聯(lián)接到所述應(yīng)用程序核心。
如圖16(a)所示，快照1087用來撤消應(yīng)用程序狀態(tài)。在用戶調(diào)用快照功能1087時，應(yīng)用程序的當(dāng)前狀態(tài)被檢測并存儲。所存儲的狀態(tài)的內(nèi)容在應(yīng)用程序改變?yōu)榱硪粻顟B(tài)時被保存下來。在圖6(b)中示出了快照。在操作中，當(dāng)應(yīng)用程序從一個URL移動到另一個時，快照會記住先前的狀態(tài)，從而能夠無縫地執(zhí)行后退和前進操作。
在文檔管理器中組織文檔圖7(a)更加詳細地描述了文檔管理器1081以及如何在文檔管理器中組織并保存文檔。如圖7(b)所示，文檔管理器1081管理文檔1082。在圖7(a)顯示的實施例中，多個文檔中的一個為根文檔701，其他的文檔為子文檔702。文檔管理器1081連接到根文檔701，根文檔701則連接到所有的子文檔702。
如圖2和7(a)所示，文檔管理器1081耦合到文檔容器203，文檔容器203是容納所有文檔1082的對象。形成工具包(例如，XML工具包)201的一部分的工具(包括DOM服務(wù)703和IO管理器704)也提供給文檔管理器1081。再參照圖7(a)，DOM服務(wù)703基于由文檔管理器1081管理的文檔來創(chuàng)建DOM樹。各個文檔705，不管是根文檔701還是子文檔702都容納在相應(yīng)的文檔容器203中。
圖7(b)顯示了一組文檔A-E是如何以分級結(jié)構(gòu)排列的實施例。文檔A為根文檔。文檔B-D是文檔A的子文檔。文檔E則是文檔D的子文檔。圖7(c)顯示了如何將文檔的同一分級結(jié)構(gòu)顯示在屏幕上的實施例。作為根文檔的文檔A顯示為基礎(chǔ)框架。文檔A的子文檔B-D顯示為在基礎(chǔ)框架A內(nèi)的子框架。文檔D的子文檔E在屏幕上顯示為子框架D的子框架。
再參照圖7(a)，為各個文檔容器203創(chuàng)建撤消管理器706和撤消封裝器(wrapper)707。撤消管理器706和撤消封裝器707用來執(zhí)行可撤消的命令。使用該特征，可以撤消使用編輯操作對文檔所作的改變。子文檔中的改變也會涉及到根文檔。撤消操作考慮到了影響分級結(jié)構(gòu)內(nèi)其他文檔的改變，并確保了在分級結(jié)構(gòu)鏈中的所有文檔之間所維護的一致性，例如，如圖7(c)所示。
撤消封裝器707將與容器203中的子文檔相關(guān)的撤消對象進行封裝，并將它們和與根文檔相關(guān)的撤消對象耦合。撤消封裝器707使得可撤消編輯接收器709能夠收集撤消對象。撤消管理器706和撤消封裝器707連接到可撤消編輯接收器708和可撤消編輯源708。本領(lǐng)域技術(shù)人員應(yīng)該理解，文檔705可以是可撤消編輯源708，并因此可以是可撤消編輯對象。
撤消命令和撤消框架圖8(a)和8(b)進一步詳細地顯示了撤消框架和撤消命令。如圖8(a)所示，撤消命令801、重做命令802和可撤消編輯命令803是能夠排列在命令調(diào)用器1051中的命令(如圖1(b)所示)并且被相應(yīng)地執(zhí)行。可撤消編輯命令803還進一步聯(lián)接到可撤消編輯源708和可撤消編輯接收器709。例如，可撤消編輯命令是“foo”編輯命令803和“bar”編輯命令804。
可撤消編輯命令的執(zhí)行圖8(b)顯示了可撤消編輯命令的執(zhí)行。首先，假設(shè)用戶使用編輯命令來編輯文檔705。在第一步驟S1，可撤消編輯接收器709被聯(lián)接到可撤消編輯源708，而可撤消編輯源708為文檔705的DOM樹。在第二步驟S2，基于由用戶發(fā)出的命令，使用DOM API對文檔705進行編輯。在第三步驟S3，向變化事件監(jiān)聽器通知已經(jīng)發(fā)生了改變。即，在該步驟，監(jiān)控DOM樹中所有改變的監(jiān)聽器檢測編輯操作。在第四步驟S4，用撤消管理器706將可撤消的編輯存儲為對象。在第五步驟S5，可撤消編輯接收器709與源708分開，源708可以是文檔705本身。
向系統(tǒng)載入文檔時需要的步驟上述幾個子部分描述了系統(tǒng)的各個組件和子組件。下面將描述在使用這些組件時用到的方法。圖9顯示了如何將文檔載入到文檔處理和管理系統(tǒng)中的總體圖。參照圖14-18詳細地描述各個步驟。
簡言之，文檔處理和管理系統(tǒng)從由在文檔中包含的數(shù)據(jù)構(gòu)成的二進制數(shù)據(jù)流創(chuàng)建DOM樹。為文檔中的感興趣的并位于“區(qū)”中的一部分創(chuàng)建頂節(jié)點，接著確定相應(yīng)的“窗格”。所確定的窗格從頂節(jié)點和物理屏幕表面創(chuàng)建“區(qū)”和“畫布”?！皡^(qū)”為各個節(jié)點創(chuàng)建“方面”，并為它們提供所需信息。畫布創(chuàng)建用于呈現(xiàn)DOM樹的節(jié)點的數(shù)據(jù)結(jié)構(gòu)。
具體地，參照圖19(a)，在“步驟0”，表述SHTML和SVG內(nèi)容的復(fù)雜文檔從存儲901載入。接著，為文檔創(chuàng)建DOM樹902。應(yīng)該注意，DOM樹具有頂節(jié)點905(XHTML)，以及隨著DOM樹下降到其他分支，會遇到由雙線表示的邊界，接著是用于不同詞匯SVG的頂節(jié)點906。這種復(fù)雜文檔的表述有助于理解用來呈現(xiàn)并最終顯示文檔的方式。
接下來，創(chuàng)建保持文檔的相應(yīng)文檔容器903。接著將文檔容器903聯(lián)接到文檔管理器904。DOM樹包括根節(jié)點，并且可選地包括多個次級節(jié)點。
典型地，這種文檔包括文本和圖形。因此，DOM樹例如能夠具有XHTML子樹以及SVG子樹。XHTML子樹具有XHTML頂節(jié)點905。同樣，SVG子樹具有SVG頂節(jié)點906。
再次參照圖9(a)，在步驟1，將頂節(jié)點聯(lián)接到窗格907(窗格907是屏幕的邏輯布局)。在步驟2，窗格907向應(yīng)用程序核心908請求用于頂節(jié)點的區(qū)工廠。在步驟3，應(yīng)用程序核心908返回區(qū)工廠以及editlet(其為用于頂節(jié)點906的畫布工廠)。
在步驟4，窗格907創(chuàng)建區(qū)909，區(qū)909聯(lián)接至窗格。在步驟5，區(qū)909為各個節(jié)點創(chuàng)建“方面”，并聯(lián)接到相應(yīng)的節(jié)點。在步驟6，窗格創(chuàng)建與其聯(lián)接的畫布910。在畫布910中包括各種命令。畫布910則構(gòu)建用于將文檔呈現(xiàn)在屏幕上的數(shù)據(jù)結(jié)構(gòu)。在XHTML的情況下，這包括盒樹結(jié)構(gòu)。
用于區(qū)的MVC圖9(b)使用MVC范例顯示了區(qū)的結(jié)構(gòu)概要。在這種情況下，模型(M)包括區(qū)和“方面”，這是因為它們是與文檔相關(guān)的輸入。視圖(V)對應(yīng)于畫布和數(shù)據(jù)結(jié)構(gòu)，以便將文檔在屏幕上呈現(xiàn)，這是由于這些是用戶在屏幕上看到的輸出?？刂?C)包括畫布中所包含的命令，這是由于這些命令對文檔及其關(guān)系執(zhí)行控制操作。
文檔的表述下面將使用圖10來描述復(fù)合文檔及其各種表述的實施例。在該實施例中使用的文檔包括文本和圖片。文本使用XHTML表述，而圖片用SVG表述。圖10詳細顯示了用于文檔組件的MVC表述以及相應(yīng)對象的關(guān)系。對于該示例性的表述，文檔1001聯(lián)接到保持文檔1001的文檔容器1002。文檔用DOM樹1003表述。DOM樹1003包括頂節(jié)點1004和其他子節(jié)點，如之前參照圖9(a)所述這些節(jié)點具有相應(yīng)的“方面”。
頂節(jié)點用陰影圓圈表示。非頂節(jié)點用非陰影圓圈表示。用來編輯節(jié)點的“方面”用三角形表示，并被聯(lián)接到相應(yīng)的節(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相對應(yīng)的“方面”1041還聯(lián)接到XHTML區(qū)1006。XHTML區(qū)1006則聯(lián)接到XHTML窗格1005。XHTML editlet創(chuàng)建XHTML畫布1007，XHTML畫布1007是文檔的邏輯表述。XHTML畫布1007聯(lián)接到XHTML窗格1005。XHTML畫布1007為文檔1001的XHTML組件創(chuàng)建盒樹1009。維護和呈現(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通過SVG editlet創(chuàng)建，并被聯(lián)接到SVG窗格1013。用于將文檔的SVG部分呈現(xiàn)在屏幕上的數(shù)據(jù)結(jié)構(gòu)和命令被聯(lián)接到所述SVG畫布。例如，這種數(shù)據(jù)結(jié)構(gòu)可包括圓圈、線、矩形等，如圖所示。
下面將使用先前描述的MVC范例，參照圖11(a)和11(b)進一步討論參照圖10描述的、用于對該示例性文檔進行表述的部件。圖11(a)提供了文檔1001的XHTM組件的MV關(guān)系的簡化圖。圖中的模型是用于文檔1001的XHTML組件的XHTM區(qū)1103。包括在XHTML區(qū)樹中的是幾個節(jié)點及其相應(yīng)的“方面”。相應(yīng)的XHTML區(qū)和窗格是MVC范例的模型(M)部分的一部分。MVC范例的視圖(V)部分是用于文檔1001的HTML組件的相應(yīng)的XHTML畫布1102和盒樹。通過畫布以及其中所包含的命令，文檔的XHTML部分被呈現(xiàn)在屏幕上。例如鍵盤和鼠標(biāo)輸入的事件以如圖所示的相反方向進行處理。
也就是說，源窗格具有附加功能，以起到DOM保持器的作用。圖11(b)提供了在圖11(a)中示出的用于文檔1001的組件的詞匯連接。作為源DOM保持器的源窗格1103包含了用于文檔的源DOM樹。連接器樹1004通過連接器工廠創(chuàng)建，連接器樹1004又創(chuàng)建作為目的DOM樹保持器的目的窗格1105。目的窗格1105接著以盒樹的形式被布置為XHTML目的畫布1106。
插件子系統(tǒng)、詞匯連接和連接器之間的關(guān)系圖12(a)-(c)分別顯示了與插件子系統(tǒng)、詞匯連接和連接器相關(guān)的附加細節(jié)。插件子系統(tǒng)被用來向文檔處理和管理系統(tǒng)增加功能，或與之交換功能。插件子系統(tǒng)包括服務(wù)代理1041。如圖12(a)所示，名稱為“My Own XML vocabulary(我的XML詞匯)”VCD文件耦合至包括MyOwnXML連接器工廠樹和詞匯(區(qū)工廠構(gòu)造器)的VC基本插件。聯(lián)接到服務(wù)代理1041的區(qū)工廠服務(wù)1201負責(zé)創(chuàng)建用于文檔的部分的區(qū)。editlet服務(wù)1202還被聯(lián)接到服務(wù)代理。editlet服務(wù)1202創(chuàng)建與區(qū)中的節(jié)點相對應(yīng)的畫布。
區(qū)工廠的實施例是分別創(chuàng)建XHTML區(qū)和SVG區(qū)的XHTML區(qū)工廠1211和SVG區(qū)工廠1212。如上參照示例性文檔所述，文檔的文本組件可通過創(chuàng)建XHTML區(qū)來表述，而圖片則可使用SVG區(qū)來表述。editlet服務(wù)的示例包括XHTML editlet 1221和SVG editlet 1222。
圖12(b)進一步詳細顯示了詞匯連接，如上所述，詞匯連接是文檔處理和管理系統(tǒng)的重要特征，其能夠使兩種不同方式的文檔的表述和顯示保持一致。能夠維護連接器工廠303的詞匯連接管理器是詞匯連接子系統(tǒng)的一部分，并耦合到VCD以接收詞匯連接描述符并生成詞匯連接命令301。如圖12(c)所示，連接器工廠303為文檔創(chuàng)建連接器304。如上所述，連接器觀察源DOM中的節(jié)點，并修改目的DOM中的節(jié)點，以維護兩種表述之間的一致性。
模板317表述用于一些節(jié)點的轉(zhuǎn)換規(guī)則。事實上，詞匯連接描述符文件是表示一些規(guī)則的一系列模板，這些規(guī)則用于將滿足某種路徑或規(guī)則的元素或元素集合轉(zhuǎn)換為其他的元素。詞匯模板305和命令模板3131都聯(lián)接到詞匯連接管理器302。詞匯連接管理器302是在VCD文件中所有部分的管理器對象。為一個VCD文件創(chuàng)建一個詞匯連接管理器對象。
圖12(c)表示了連接器的附加細節(jié)。連接器工廠303從源文檔中創(chuàng)建連接器。連接器工廠聯(lián)接于詞匯、模板和元素模板，并分別創(chuàng)建詞匯連接器、模板連接器和元素連接器。
詞匯連接管理器302維護連接器工廠303。為了創(chuàng)建詞匯，讀取相應(yīng)的VCD文件。接著創(chuàng)建連接器工廠303。該連接器工廠303與負責(zé)創(chuàng)建區(qū)的區(qū)工廠和負責(zé)創(chuàng)建畫布的editlet服務(wù)相關(guān)聯(lián)。
接著，用于目標(biāo)詞匯的editlet服務(wù)創(chuàng)建詞匯連接畫布。詞匯連接畫布為目的DOM樹創(chuàng)建節(jié)點。詞匯連接畫布為源DOM樹或區(qū)中的頂點元素創(chuàng)建連接器。接著，根據(jù)需要遞歸地創(chuàng)建子連接器。通過VCD文件中的一組模板創(chuàng)建連接器樹。
模板是用于將標(biāo)記語言的元素轉(zhuǎn)換為其他元素的規(guī)則集合。例如，各個模板與源DOM樹或區(qū)相匹配。在正確匹配時，創(chuàng)建頂點連接器。例如，模板“A/*/D”監(jiān)測所有從節(jié)點A開始、在節(jié)點D結(jié)束的樹分支，而不考慮節(jié)點A和節(jié)點D之間的節(jié)點。同樣，“//B”對應(yīng)于所有來自根節(jié)點的“B”節(jié)點。
VCD文件相關(guān)的連接器樹的示例下面將解釋與特定文檔相關(guān)的處理。名為MySampleXML的文檔被載入到文檔處理系統(tǒng)。圖13顯示了使用詞匯連接管理器的VCD腳本和用于文件MySampleXJML的連接器工廠樹的實施例。在圖中顯示了腳本文件內(nèi)的詞匯部分、模板部分以及它們在詞匯連接管理器中的相應(yīng)組件。在標(biāo)簽“vcd:vocabulary”下提供了屬性match＝″sample:root″、label＝″MySampleXML″以及call-template＝″sampleTemplate″。
與該實施例相對應(yīng)，在MySampleXML的詞匯連接管理器中，詞匯包括頂點元素“sample:root”。相應(yīng)的UI標(biāo)注為“MySampleXML”。在模板部分，標(biāo)簽為vcd:template，名稱為“sample template”。
如何將文件載入系統(tǒng)的詳細實施例圖14-18顯示了載入文檔MySampleXML的詳細描述。在步驟1，如圖14(a)所示，文檔從存儲1405中載入。DOM服務(wù)創(chuàng)建DOM樹和文檔管理器1406以及對應(yīng)的文檔容器1401。文檔容器聯(lián)接到文檔管理器1406。文檔包括用于XHTML和MySampleXML的子樹。XHTML頂節(jié)點1403是用于XHTML的最頂部的節(jié)點，并具有標(biāo)簽xhtml:html。另一方面，mysample頂節(jié)點1404對應(yīng)于MySampleXML，并具有標(biāo)簽sample:root。
在步驟2，如圖14(b)所示，根窗格為文檔創(chuàng)建XTML區(qū)、“方面”和畫布。創(chuàng)建與頂節(jié)點1403對應(yīng)的窗格1407、XHTML區(qū)1408、XHTML畫布1409和盒樹1410。
在步驟3，如圖14(c)所示，XHTML區(qū)域找到外來的標(biāo)簽“sample:root”，并從html畫布上的區(qū)域創(chuàng)建子窗格。
圖15顯示了步驟4，在步驟4中，子窗格獲取能夠處理“sample:root”標(biāo)簽并創(chuàng)建適當(dāng)?shù)膮^(qū)的相應(yīng)的區(qū)工廠。這種區(qū)域工廠將在能夠?qū)崿F(xiàn)區(qū)域工廠的詞匯中。區(qū)域工廠包括MySampleXML中的詞匯部分的內(nèi)容。
圖16顯示了步驟5，在步驟5中，與MySampleXML對應(yīng)的詞匯創(chuàng)建缺省的區(qū)1061。相應(yīng)的editlet被創(chuàng)建并被提供給子窗格1501，以創(chuàng)建相應(yīng)的畫布。editlet創(chuàng)建詞匯連接畫布。接著，editlet調(diào)用所述模板部分。所述連接器工廠樹也被包括在內(nèi)。連接器工廠樹創(chuàng)建所有的連接器，接著將創(chuàng)建的連接器形成連接器樹(連接器樹形成VC畫布的一部分)。根據(jù)前面的描述，對于與文檔的XHTML內(nèi)容相關(guān)的頂節(jié)點，根窗格和XHTML區(qū)的關(guān)系以及XHTML畫布和盒樹之間的關(guān)系是顯而易見的。
圖17(a)基于如上所述的源DOM樹、VC畫布和目的DOM樹之間的對應(yīng)關(guān)系顯示了步驟6。在步驟6中，各個連接器創(chuàng)建目的DOM對象。一些連接器包括XPath信息。XPath信息包括一個或多個XPath表達式，XPath表達式用來確定需要被監(jiān)測是否發(fā)生了改變/修改的源DOM樹的子集。
圖17(b)根據(jù)源、VC和目的關(guān)系顯示了步驟7。在步驟7中，詞匯從源DOM的窗格形成目的DOM樹的目的窗格。這基于源窗格來完成。接著，將目的樹的頂節(jié)點聯(lián)接到目的窗格以及相應(yīng)的區(qū)。接著為目的窗格設(shè)置其自身的editlet，editlet則創(chuàng)建目的畫布，并構(gòu)建數(shù)據(jù)結(jié)構(gòu)和命令，從而以目的格式呈現(xiàn)文檔。
圖18(a)顯示了發(fā)生于某節(jié)點的事件流，該節(jié)點不具有相應(yīng)的源節(jié)點并僅依賴于目的樹。畫布所獲取的事件(例如鼠標(biāo)事件和鍵盤事件)通過目的樹，并被傳輸?shù)皆啬０暹B接器(ElementTemplateConnector)。元素模板連接器不具有相應(yīng)的源節(jié)點，因此被傳送的事件并不是對源節(jié)點的編輯操作。如果所傳送的事件與命令模板(CommandTemplate)中描述的命令相匹配，則元素模板連接器執(zhí)行相應(yīng)的動作。否則，元素模板連接器忽略所傳送的事件。
圖18(b)顯示了發(fā)生于某目的樹的節(jié)點的事件流，該目的樹的節(jié)點通過文本連接器(TextOfConnector)與源節(jié)點相關(guān)聯(lián)。文本連接器從由源DOM樹的XPath規(guī)定的節(jié)點獲取文本節(jié)點，并將該文本節(jié)點映射為目的DOM樹的節(jié)點。畫布所獲取的事件(例如鼠標(biāo)事件和鍵盤事件)通過目的樹，并被傳送到文本連接器。文本連接器將所傳送的事件映射為相應(yīng)源節(jié)點的編輯命令，并將這些命令設(shè)置在隊列1053中。編輯命令是通過“方面”執(zhí)行的、與DOM有關(guān)的一組API調(diào)用。當(dāng)執(zhí)行設(shè)置在隊列中的命令時，編輯源節(jié)點。在編輯源節(jié)點時，發(fā)出變化事件，并且將對源節(jié)點的修改通知到注冊為監(jiān)聽器的文本連接器。文本連接器重新建立目的樹，從而在相應(yīng)的目的節(jié)點中反映出對源節(jié)點的修改。如果包含文本連接器的模板包括控制聲明，例如“foreach”和“for loop”，則連接器工廠重新評估控制聲明。在重建文本連接器后，重建目的樹。圖1(a)圖解說明了能夠作為在本文中隨后詳細描述類型的文檔處理和管理系統(tǒng)的基礎(chǔ)的組件的傳統(tǒng)結(jié)構(gòu)。裝置10包括具有CPU形式或微處理器形式的處理器11，處理器11通過通信路徑13(通常實現(xiàn)為總線)耦合至可為任何當(dāng)前或?qū)砟塬@得的ROM和/或RAM存儲形式的存儲器12。用戶輸入14(例如鼠標(biāo)、鍵盤、語音識別系統(tǒng)或類似設(shè)備)的I/O接口16以及顯示設(shè)備15(或其它用戶接口)也耦合至總線用于與處理器11和存儲器12通信。如本領(lǐng)域所公知的那樣，諸如打印機、通信調(diào)制解調(diào)器等的其它設(shè)備可耦合至該裝置。該裝置可為獨立設(shè)備或者具有將多個終端以及一個或多個服務(wù)器耦合在一起的聯(lián)網(wǎng)形式，或者以本領(lǐng)域公知的多種設(shè)置方式的其中之一。本發(fā)明并不受這些組件的結(jié)構(gòu)、它們的集中式或分布式體系結(jié)構(gòu)或者多種組件的通信方式的限制。
另外，應(yīng)該注意到，本文所討論的系統(tǒng)和示例性實現(xiàn)包括幾種具有多種功能的組件和子組件。應(yīng)該注意到，這些組件和子組件可僅使用硬件、僅使用軟件以及使用硬件和軟件的組合來實現(xiàn)，以提供上述的多種功能。另外，硬件、軟件及其組合可使用通用計算裝置或使用專用硬件或使用通用計算裝置和專用硬件的組合來實現(xiàn)。因此，組件或子組件的結(jié)構(gòu)包括運行特定軟件的通用/專用計算裝置，以提供該組件或子組件的功能。
圖1(b)示出了一種示例性文檔處理和管理系統(tǒng)的總體方框圖。文檔在上述文檔處理和管理系統(tǒng)中被創(chuàng)建和編輯。這些文檔能夠以具有標(biāo)記語言的特征的任何語言來表述(例如XML)。同樣，為方便起見，已經(jīng)創(chuàng)建了用于特定組件和子組件的術(shù)語和名稱。但是，這些不應(yīng)被視作對本文公開的一般教導(dǎo)范圍造成了限制。
所述文檔處理和管理系統(tǒng)可被視為具有兩個基本組件。一個組件是“執(zhí)行環(huán)境”101，它是處理和管理系統(tǒng)運行的環(huán)境。例如，執(zhí)行環(huán)境提供了協(xié)助系統(tǒng)以及用戶對文檔進行處理和管理的基本效用和功能。另一組件是“應(yīng)用程序組件”102，它由在執(zhí)行環(huán)境中運行的應(yīng)用程序構(gòu)成。這些應(yīng)用程序包括文檔本身及其各種表述。
執(zhí)行環(huán)境執(zhí)行環(huán)境101的關(guān)鍵組件是程序調(diào)用器103。程序調(diào)用器103是被訪問以啟動文檔處理和管理系統(tǒng)的基本程序。例如，當(dāng)用戶登錄并啟動文檔處理和管理系統(tǒng)時，程序調(diào)用器103被執(zhí)行。程序調(diào)用器103能夠(例如但并非限制)讀取并處理作為插件增加至文檔處理和管理系統(tǒng)的功能、啟動并運行應(yīng)用程序、以及讀取與文檔相關(guān)的性質(zhì)。當(dāng)用戶希望發(fā)起計劃在執(zhí)行環(huán)境中運行的應(yīng)用程序時，程序調(diào)用器103找到、發(fā)起然后執(zhí)行該應(yīng)用程序。例如，當(dāng)用戶希望對已經(jīng)載入到系統(tǒng)中的文檔進行編輯(它是執(zhí)行環(huán)境中的一種應(yīng)用程序)時，程序調(diào)用器103首先找到該文檔，然后執(zhí)行用于載入和編輯該文檔所必需的功能。
程序調(diào)用器103聯(lián)接至幾個組件，例如插件子系統(tǒng)104、命令子系統(tǒng)105以及資源模塊109。這些組件將隨后進行更詳細描述。
插件子系統(tǒng)插件子系統(tǒng)104是向文檔處理和管理系統(tǒng)增加功能的一種高度靈活和有效的設(shè)備。插件子系統(tǒng)104也能夠被用來修改和去除文檔處理和管理系統(tǒng)中存在的功能。此外，可使用插件子系統(tǒng)增加或修改多種功能。例如，如隨后將詳細描述的那樣，插件子系統(tǒng)可用于增加功能“editlet”，其可操作以有助于在屏幕上呈現(xiàn)文檔。插件editlet也有助于對增加至系統(tǒng)的詞匯進行編輯。
插件子系統(tǒng)104包括服務(wù)代理1041。服務(wù)代理1041管理增加至文檔處理和管理系統(tǒng)的插件，從而代理已增加至文檔處理和管理系統(tǒng)的服務(wù)。
代表期望功能的單個功能以“服務(wù)”1042的形式被增加至系統(tǒng)。服務(wù)1042的可用類型包括但不限于應(yīng)用程序服務(wù)、區(qū)工廠服務(wù)、editlet服務(wù)、命令工廠服務(wù)、連接xpath服務(wù)、CSS計算服務(wù)等。這些服務(wù)及其與系統(tǒng)其余部分的關(guān)系將隨后詳細描述，以更好地理解文檔處理和管理系統(tǒng)。
插件和服務(wù)之間的關(guān)系是，插件是可包括一個或多個服務(wù)提供器的單元，各個服務(wù)提供器具有與之相關(guān)的一個或多個類別的服務(wù)。例如，使用具有適當(dāng)軟件應(yīng)用程序的單個插件，能將多個服務(wù)中的一個服務(wù)增加至系統(tǒng)，從而向系統(tǒng)增加相應(yīng)的功能。
命令子系統(tǒng)命令子系統(tǒng)105被用來執(zhí)行與文檔的處理相關(guān)的命令形式的指令。用戶可通過執(zhí)行一系列指令而執(zhí)行對文檔的操作。例如，通過發(fā)出命令形式的指令，用戶在文檔管理系統(tǒng)中處理XML文檔，并編輯與該XML文檔相對應(yīng)的XML DOM樹。這些命令可利用鍵盤敲打、鼠標(biāo)點擊或其它有效的用戶接口動作而輸入。有時，能夠通過命令來執(zhí)行一個以上的指令。在這種情況下，這些指令被封裝成單個命令并連續(xù)執(zhí)行。例如，用戶可能希望將錯誤詞語替換為正確詞語。在這種情況下，第一指令可用以在文檔中找尋錯誤詞語。第二指令可用以刪除該錯誤詞語。第三指令可用以輸入正確詞語。這三個指令可被封裝成單個命令。
在某些示例中，命令可具有相關(guān)功能，例如，下面將要詳細討論的“撤消”功能。這些功能可隨后分配給用來創(chuàng)建對象的基類。
命令子系統(tǒng)105的一個組件是命令調(diào)用器1051，命令調(diào)用器1051可操作為選擇性地提供并執(zhí)行命令。雖然圖1(b)中僅示出了一個命令調(diào)用器，但也可使用一個以上的命令調(diào)用器并同時執(zhí)行一個以上的命令。命令調(diào)用器1051維護執(zhí)行命令所需的功能和類。在操作中，要執(zhí)行的命令1052被置于隊列1053中。命令調(diào)用器創(chuàng)建連續(xù)執(zhí)行的命令線程。如果在命令調(diào)用器中沒有正在執(zhí)行的命令，則由命令調(diào)用器1051執(zhí)行待執(zhí)行的命令1052。如果命令調(diào)用器正在執(zhí)行命令，則新的命令被置于命令隊列1053的末尾。不過，對于各命令調(diào)用器1051而言，一次僅執(zhí)行一個命令。如果指定的命令執(zhí)行失敗，則命令調(diào)用器1051執(zhí)行命令異常。
可由命令調(diào)用器1051執(zhí)行的命令的類型包括但不限于可撤消命令1054、異步命令1055以及詞匯連接命令1056。可撤消命令1054是那些如果用戶希望就能夠回退其效果的命令?？沙废畹氖纠秊榧羟?、復(fù)制、插入文本等。在操作中，當(dāng)用戶突出文檔的一部分并向該部分應(yīng)用剪切命令時，如果需要，通過使用可撤消命令，可使得被剪切的部分“恢復(fù)原樣(uncut)”。
詞匯連接命令1056被載入詞匯連接描述符腳本文件中。詞匯連接命令1056是能夠由程序員定義的用戶指定命令。這些命令可以是更抽象命令的組合，例如，用于增加XML片段、刪除XML片段、設(shè)置屬性等。這些命令特別涉及對文檔進行編輯。
異步命令1055是用于載入或保存由系統(tǒng)執(zhí)行的文檔的命令。異步命令1055與可撤消命令或VC命令異步地執(zhí)行。與可撤消命令不同，異步命令不能被取消。
異步命令1055的級別低于所述詞匯連接命令的級別。所述異步命令是對于所述文檔處理和管理系統(tǒng)更具體的命令。異步命令被直接記入到命令調(diào)用器1051。另一方面，將詞匯連接命令1056解釋和轉(zhuǎn)換為異步命令，然后再將所述異步命令記入到命令調(diào)用器1051。
資源資源109是向不同的類提供某些功能的對象。例如，串資源、圖標(biāo)和設(shè)定鍵綁定是系統(tǒng)中使用的資源。
應(yīng)用程序組件應(yīng)用程序組件102，即文檔處理系統(tǒng)的第二個主要特征，在執(zhí)行環(huán)境101中運行。概括而言，應(yīng)用程序組件102包括實際文檔，實際文檔包括其在系統(tǒng)內(nèi)的多個邏輯和物理表述。應(yīng)用程序組件102還包括系統(tǒng)的、用來管理文檔的組件。應(yīng)用程序組件102進一步包括用戶應(yīng)用程序106、應(yīng)用程序核心108、用戶界面107以及核心組件110。
用戶應(yīng)用程序用戶應(yīng)用程序106連同程序調(diào)用器103一起被載入到系統(tǒng)中。用戶應(yīng)用程序106是將文檔、文檔的多種表述以及與文檔進行交互所需的用戶界面特征結(jié)合在一起的粘合劑(glue)。例如，用戶可能希望創(chuàng)建作為工程(project)一部分的一套文檔。載入這些文檔，創(chuàng)建用于文檔的適當(dāng)表述，增加作為用戶應(yīng)用程序106一部分的用戶界面功能。換言之，用戶應(yīng)用程序106將文檔及其表述的各個方面結(jié)合在一起使得用戶能夠與形成工程一部分的文檔進行交互。一旦創(chuàng)建了用戶應(yīng)用程序106，每當(dāng)用戶希望與形成工程一部分的文檔進行交互時，用戶就能夠簡單地將用戶應(yīng)用程序106載入到執(zhí)行環(huán)境中。
核心組件核心組件110提供了在多個窗格之間共享文檔的一種方法。如將在隨后詳細討論的那樣，窗格表述DOM樹，并處理屏幕的物理布局。例如，物理屏幕包括在屏幕內(nèi)的多個窗格用于描述各條信息。實際上，由用戶在屏幕上查看的文檔可在一個或多個窗格中顯示。此外，兩個不同的文檔可以出現(xiàn)在屏幕上的兩個不同窗格中。
屏幕的物理布局還可以具有樹型形式，如圖1(c)所示。因此，如果組件1083要作為窗格顯示在屏幕上，則該窗格可被實現(xiàn)為根窗格1084。作為一種選擇，它也可以是子窗格1085。根窗格1084是窗格樹根部的窗格，而子窗格1085是除了根窗格1084之外的任何窗格。
核心組件110也提供字體，并充當(dāng)用于文檔的多個功能性操作的源，例如，工具包(toolkit)。由核心組件110執(zhí)行的任務(wù)的一個示例是在多個窗格之間移動鼠標(biāo)光標(biāo)。被執(zhí)行的任務(wù)的另一個示例是標(biāo)記一個窗格中的文檔的一部分，并將其復(fù)制到包含不同文檔的另一窗格上。
應(yīng)用程序核心如上所述，應(yīng)用程序組件102由被系統(tǒng)處理和管理的文檔組成。應(yīng)用程序組件102包括對于系統(tǒng)內(nèi)的文檔的多種邏輯和物理表述。應(yīng)用程序核心108是應(yīng)用程序組件102的組件。其功能是保持實際文檔及其內(nèi)的所有數(shù)據(jù)。應(yīng)用程序核心108包括文檔管理器1081和文檔1082本身。
文檔管理器1081的多個方面將在隨后進行更詳細的描述。所述文檔管理器管理文檔1082。所述文檔管理器也連接至根窗格1084、子窗格1085、剪貼板實用程序1086以及快照實用程序1087。剪貼板實用程序1086提供了保持用戶決定增加至剪貼板的部分文檔的一種方法。例如，用戶可能希望剪切文檔的一部分，并將其保存到新的文檔上，用于稍后查看。在這種情況下，剪切的部分被增加至剪貼板。
快照實用程序1087也將在稍后描述，從而當(dāng)應(yīng)用程序從一個狀態(tài)變?yōu)榱硪粻顟B(tài)時，能夠記住應(yīng)用程序的當(dāng)前狀態(tài)。
用戶界面應(yīng)用程序102的另一組件是用戶界面107，其為用戶提供一種與系統(tǒng)進行物理交互的方式。例如，以物理接口1070來實現(xiàn)用戶界面時，用戶使用用戶界面上載、刪除、編輯和管理文檔。用戶界面包括框架1071、菜單欄1072、狀態(tài)欄1073以及URL欄1074。
如通常公知的那樣，框架可被視為物理屏幕的活動區(qū)域。菜單欄1072是屏幕的、包括為用戶提供選項的菜單的區(qū)域。狀態(tài)欄1073是屏幕的、顯示應(yīng)用程序的執(zhí)行狀態(tài)的區(qū)域。URL欄1074提供了輸入用于在互聯(lián)網(wǎng)上定位的URL地址的區(qū)域。
文檔管理器和相關(guān)的數(shù)據(jù)結(jié)構(gòu)圖2示出了文檔管理器1081的進一步細節(jié)。圖2包括被用來在文檔處理和管理系統(tǒng)內(nèi)表述文檔的數(shù)據(jù)結(jié)構(gòu)和組件。為了更好的理解，在這部分描述的組件通過利用模型-視圖-控制器(MVC)表述范例來進行描述。
文檔管理器1081包括文檔容器(containter)203，文檔容器203保持并容納文檔處理和管理系統(tǒng)中的所有文檔。聯(lián)接至文檔管理器1081的工具包201為文檔管理器108 1的使用提供了各種工具。例如，“DOM服務(wù)”是由工具包201提供的能夠提供創(chuàng)建、維護和管理與文檔相對應(yīng)的DOM所需的所有功能的工具。作為工具包201提供的另一工具的“IO管理器”分別管理向系統(tǒng)的輸入和來自系統(tǒng)的輸出。同樣地，“流處理器”是一種以比特流方式來處理文檔上載的工具。這些工具形成了工具包201的組件，不過并未在圖中明確示出或指定附圖標(biāo)記。
根據(jù)MVC范例表述，模型(M)包括文檔的DOM樹模型202。如上所述，所有文檔均在文檔處理和管理系統(tǒng)中被表述為DOM樹。文檔也形成文檔容器203的一部分。
DOM模型和區(qū)DOM是由W3C構(gòu)建的標(biāo)準。DOM標(biāo)準定義了用于對節(jié)點進行操作的標(biāo)準接口。在每個詞匯或每個節(jié)點的基礎(chǔ)上，在所述標(biāo)準內(nèi)提供了特定的操作。這些操作優(yōu)選地被提供為API。文檔處理/管理系統(tǒng)提供了這種作為“方面(facet)”的節(jié)點特定API。每個“方面”都聯(lián)接到節(jié)點。通過將這種“方面”連接到節(jié)點，提供了符合DOM標(biāo)準的有用的API。通過在已應(yīng)用的標(biāo)準DOM之上增加特定的API而不是為每個詞匯實現(xiàn)特定的DOM，可集中處理多種詞匯，并且可以正確地處理其中采用詞匯的任意組合的文檔。通常，DOM可以被示意性地表述為DOM樹。
表述文檔的DOM樹是具有節(jié)點2021的樹。作為DOM樹的子集的區(qū)209包括該DOM樹內(nèi)部的一個或多個所關(guān)注的節(jié)點。例如，僅文檔的一部分可在屏幕上顯現(xiàn)。文檔可見的這一部分可使用“區(qū)”209來表述。利用被稱作“區(qū)工廠”205的插件來創(chuàng)建、操作和處理區(qū)。雖然區(qū)表述DOM的一部分，但它也可使用一個以上的“命名空間”。如本領(lǐng)域中公知的那樣，命名空間是名稱的匯集或集合，這些名稱在該命名空間中是唯一。換言之，一個命名空間中不能夠出現(xiàn)兩個相同的名稱。
“方面”及其與區(qū)的關(guān)系“方面”2022是MVC范例的模型(M)部分內(nèi)的另一組件。它被用來編輯區(qū)中的節(jié)點?！胺矫妗?022使用不會影響區(qū)本身的內(nèi)容的執(zhí)行過程來組織對于DOM的訪問。如以下將說明的那樣，這些過程執(zhí)行與節(jié)點相關(guān)的有意義且有用的操作。
各個節(jié)點2021具有相應(yīng)的2022。通過利用“方面”來執(zhí)行操作而不是直接對DOM中的節(jié)點進行操作，DOM的完整性得以確保。否則，如果直接對節(jié)點執(zhí)行操作，那么幾個插件可能同時對DOM進行改變，從而造成不一致性。
“詞匯”是屬于命名空間的標(biāo)簽(例如XML標(biāo)簽)的集合。如上所述，命名空間具有唯一的名稱集(在該特定情況下為標(biāo)簽集)。詞匯表現(xiàn)為表述XML文檔的DOM樹的子樹。這種子樹包括區(qū)。在特定實施例中，標(biāo)簽集的邊界由區(qū)來限定。區(qū)209是利用被稱作“區(qū)工廠服務(wù)”205的服務(wù)而創(chuàng)建的。如上所述，區(qū)209是對表述文檔的DOM樹的一部分的內(nèi)部表述。為了提供對該文檔的上述部分的訪問，需要邏輯表述。這種邏輯表述通知計算機關(guān)于文檔如何在屏幕上進行邏輯顯示?！爱嫴肌?10是一種可操作為提供與區(qū)相對應(yīng)的邏輯布局的服務(wù)。
另一方面，窗格(例如窗格211)是與由畫布210提供的邏輯布局相對應(yīng)的物理屏幕布局。實際上，用戶僅能看見以字符和圖片形式呈現(xiàn)在顯示屏上的文檔。因此，文檔必須通過用于在屏幕上描繪字符和圖片的處理來呈現(xiàn)在屏幕上。根據(jù)由窗格211提供的物理布局，文檔由畫布210呈現(xiàn)在屏幕上。
與區(qū)209相對應(yīng)的畫布210是利用“editlet服務(wù)”206來創(chuàng)建的。文檔的DOM是利用editlet服務(wù)206和畫布210來編輯的。為了維護原始文檔的完整性，editlet服務(wù)206和畫布服務(wù)210使用與區(qū)209中的一個或多個節(jié)點相對應(yīng)的“方面”。這些服務(wù)并不直接操作區(qū)和DOM中的節(jié)點?！胺矫妗笔抢脕碜訫VC范例的(C)組件(即控制器)的命令207來操作的。
用戶通常通過例如移動屏幕上的光標(biāo)和/或鍵入命令而與屏幕進行交互。提供屏幕的邏輯布局的畫布2010接收這些光標(biāo)操作。然后，畫布2010使得對“方面”采取相應(yīng)的動作。給定這一關(guān)系，光標(biāo)子系統(tǒng)204即作為用于文檔管理器1081的MVC范例的控制器(C)。
畫布2010也具有處理事件的任務(wù)。例如，畫布2010處理諸如鼠標(biāo)點擊、焦點移動和類似的用戶發(fā)起的動作等事件。
區(qū)、“方面”、畫布和窗格之間的關(guān)系概述文檔管理和處理系統(tǒng)內(nèi)的文檔可從至少四個角度來觀察，即1)用來保持文檔管理系統(tǒng)中的文檔的內(nèi)容和結(jié)構(gòu)的數(shù)據(jù)結(jié)構(gòu)；2) 不會影響文檔完整性就能編輯文檔內(nèi)容的方式；3)文檔在屏幕上的邏輯布局；以及4)文檔在屏幕上的物理布局。區(qū)、“方面”、畫布和窗格分別表述與上述四個方面相對應(yīng)的文檔管理系統(tǒng)的組件。
撤消系統(tǒng)如上所述，人們希望對文檔的任何改變(例如，編輯)應(yīng)該是可撤消的。例如，用戶可執(zhí)行編輯操作，然后決定撤消該改變。參照圖2，撤消子系統(tǒng)212是文檔管理器的可撤消組件。撤消管理器2121保存可能被用戶撤消的、對文檔執(zhí)行的所有操作。例如，用戶可執(zhí)行命令來將文檔中的詞匯替換成另一個詞語。之后，該用戶可改變主意并決定保留原來的詞語。撤消子系統(tǒng)212協(xié)助上述操作。撤消管理器2121保存上述可撤消編輯2122的操作。
光標(biāo)子系統(tǒng)如上所述，MVC的控制器部分可包括光標(biāo)子系統(tǒng)204。該光標(biāo)子系統(tǒng)204從用戶處接收輸入。這些輸入通常具有命令和/或編輯操作的性質(zhì)。因此，光標(biāo)子系統(tǒng)204可被視作是與文檔管理器1081相關(guān)的MVC范例的控制器(C)部分。
視圖如上所述，畫布2010表述要顯現(xiàn)在屏幕上的文檔的邏輯布局。對于XHTML文檔的特定實施例而言，畫布可包括盒樹(box tree)，該盒樹是文檔在屏幕上如何被查看的邏輯表述。上述盒樹可包含在與文檔管理器1081有關(guān)的MVC范例的視圖(V)部分中。
詞匯連接文檔處理管理系統(tǒng)的一個重要特征是，能夠以兩種不同的方式(例如，以兩種標(biāo)記語言)來表述和顯示文檔，從而使得兩種不同的表述自動保持一致。
標(biāo)記語言文檔(例如XML文檔)基于通過文檔類型定義限定的詞匯創(chuàng)建。詞匯則是一組標(biāo)簽集，并可以任意定義，這就使得詞匯的數(shù)量可能是無限的。但是，為多個可能的詞匯中的每一個都提供專用的單獨處理和管理環(huán)境是不切實際的。詞匯連接是解決這種問題的一種方式。
例如，文檔可以利用兩種或更多標(biāo)記語言來表述。這些文檔例如可以是XHTML(可擴展超文本標(biāo)記語言)、SVG(可縮放矢量圖形)、MathML(數(shù)學(xué)標(biāo)記語言)或其他的標(biāo)記語言。換句話說，標(biāo)記語言可以視為和XML中的詞匯和標(biāo)簽集相同。
詞匯可以使用詞匯插件來實現(xiàn)。在文檔處理和管理系統(tǒng)中，以插件不可用的詞匯所描述的文檔可以通過將該文檔映射為插件可用的另一詞匯來顯示。因此，以非插件的詞匯描述的文檔仍然是可以正確顯示的。
詞匯連接包括獲取定義文件、在定義文件之間進行映射、以及生成定義文件的能力。用某種詞匯描述的文檔能夠映射為另外的詞匯。因此，詞匯連接提供了通過與文檔已被映射成的詞匯相對應(yīng)的顯示和編輯插件來顯示或編輯文檔的能力。
應(yīng)該認識到，各個文檔在文檔處理和管理系統(tǒng)中被描述為通常具有多個節(jié)點的DOM樹?！岸x文件”為各個節(jié)點描述了該節(jié)點與其他節(jié)點之間的連接。規(guī)定了是否可以對各個節(jié)點的元素值和屬性值進行編輯。還描述了使用節(jié)點的元素值和屬性值的運算表達式。
利用映射特征，通過參考定義文件創(chuàng)建目的DOM樹。因此，源DOM樹和目的DOM樹之間的關(guān)系被建立并維護。詞匯連接監(jiān)控源DOM樹和目的DOM樹之間的連接。在從用戶接收到編輯指令后，詞匯連接修改源DOM樹中的相關(guān)節(jié)點。發(fā)出表示已經(jīng)修改了源DOM樹的“變化事件”，并且相應(yīng)地修改目的DOM樹。
通過使用詞匯連接，僅對于少量用戶熟知的相對次要的詞匯可以被轉(zhuǎn)換為其他主要的詞匯。因此，即便是對于那些僅有少量用戶使用的次要詞匯，也可以準確地顯示文檔，并提供理想的編輯環(huán)境。
因此，作為文檔管理系統(tǒng)一部分的詞匯連接子系統(tǒng)提供了能夠?qū)ξ臋n進行多種表述的功能。
圖3顯示了詞匯連接(VC)子系統(tǒng)300。VC子系統(tǒng)提供了一種維護同一文檔的兩種可替換表述之間的一致性的方式。在圖中具有與上面描述和標(biāo)識相同的組件，這些組件相互連接從而實現(xiàn)上述目的。例如，兩種表述可以是同一文檔以兩種不同詞匯實現(xiàn)的可替換表述。如上所述，其中一種可以是源DOM樹，而另一種是目DOM樹。
詞匯連接子系統(tǒng)利用被稱為“詞匯連接”301的插件在文檔處理和管理系統(tǒng)中實現(xiàn)詞匯連接子系統(tǒng)300的功能。將被表述的文檔的各詞匯305都需要相應(yīng)的插件。例如，如果文檔的一部分以HTML表述，而其他部分以SVG表述，則需要相應(yīng)的HTML詞匯插件和SVG詞匯插件。
詞匯連接插件301為區(qū)209或窗格211創(chuàng)建與適當(dāng)詞匯305的文檔相對應(yīng)的適當(dāng)?shù)脑~匯連接畫布310。使用詞匯連接301，利用轉(zhuǎn)換規(guī)則，對源DOM樹的區(qū)209的改變被轉(zhuǎn)換到另一DOM樹306的相應(yīng)區(qū)。轉(zhuǎn)換規(guī)則以詞匯連接描述符(VCD)的形式給出。對于與源和目的DOM之間的這種轉(zhuǎn)換相對應(yīng)的各個VCD文件，創(chuàng)建相應(yīng)的詞匯連接管理器302。
連接器連接器304連接源DOM樹中的源節(jié)點和目的DOM樹中的目的節(jié)點。連接器304可操作以觀察源DOM樹中的源節(jié)點，和與該源節(jié)點相對應(yīng)的、對源文檔的修改(變化)。接著，連接器304修改相應(yīng)的目的DOM樹中的節(jié)點。只有連接器304是能夠修改目的DOM樹的對象。例如，如果用戶僅能夠?qū)υ次臋n和相應(yīng)的源DOM樹進行修改，則連接器304對目的DOM樹進行相應(yīng)的修改。
連接器304被邏輯地鏈接在一起以形成樹結(jié)構(gòu)。連接器304形成的樹被稱為“連接器樹”。連接器304通過一種服務(wù)而創(chuàng)建，該服務(wù)被稱為“連接器工廠”303服務(wù)。連接器工廠303從源文檔創(chuàng)建連接器304，并將連接器304以連接器樹的形式鏈接起來。詞匯連接管理器302維護連接器工廠303。
如上所述，詞匯是命名空間中的標(biāo)簽集。如圖3所示，通過詞匯連接301為文檔創(chuàng)建詞匯305。這通過分析文檔文件以及為源DOM和目的DOM之間的轉(zhuǎn)換創(chuàng)建適當(dāng)?shù)脑~匯連接管理器302來實現(xiàn)。此外，在創(chuàng)建連接器的連接器工廠303、創(chuàng)建區(qū)209的區(qū)工廠服務(wù)205和創(chuàng)建與區(qū)中的節(jié)點相對應(yīng)的畫布的editlet服務(wù)206之間建立適當(dāng)?shù)年P(guān)聯(lián)。當(dāng)用戶從系統(tǒng)中除去或刪除文檔時，對應(yīng)的詞匯連接管理器302被刪除。
詞匯305接著創(chuàng)建詞匯連接畫布。此外，連接器304和目的DOM樹306被相應(yīng)地創(chuàng)建。
應(yīng)該理解，源DOM和畫布分別對應(yīng)于模型(M)和視圖(V)。然而，僅當(dāng)目標(biāo)詞匯能夠在屏幕上呈現(xiàn)時，這種呈現(xiàn)才有意義。這種顯示通過詞匯插件來實現(xiàn)。詞匯插件提供用于主要的詞匯，例如XHTML、SVG和MathML。詞匯插件相對于目標(biāo)詞匯使用。它們提供了一種使用詞匯連接描述符在詞匯之間進行映射的方式。
僅在目標(biāo)詞匯可被映射并具有預(yù)定的屏幕呈現(xiàn)方式時，這種映射才有意義。這種呈現(xiàn)方式為工業(yè)標(biāo)準，例如由諸如W3C組織定義的XHTML。
在需要詞匯連接時，使用詞匯連接畫布。在這種情況下，由于不能夠為源直接創(chuàng)建視圖，因此，不創(chuàng)建源畫布。在這種情況下，使用連接器樹來創(chuàng)建詞匯連接畫布。這種詞匯連接畫布僅僅處理事件轉(zhuǎn)換，而并不會有助于將文檔呈現(xiàn)在屏幕上。
目的區(qū)、窗格以及畫布如上所述，詞匯連接子系統(tǒng)的目的在于創(chuàng)建并同時維護對同一文檔的兩種替換表述。第二替換表述還可以是先前被引入作為目的DOM樹的DOM樹形式。為了瀏覽第二種表述的文檔，需要目的區(qū)、畫布和窗格。
在創(chuàng)建詞匯連接畫布后，創(chuàng)建相應(yīng)的目的窗格307。此外，相關(guān)的目的畫布308和相應(yīng)的盒樹309被創(chuàng)建。同樣，詞匯連接畫布還與源文檔的窗格211和區(qū)209關(guān)聯(lián)。
目的畫布308提供了文檔的第二種表述方式的邏輯布局。具體地，目的畫布308提供了用戶界面功能，例如光標(biāo)和選擇(selection)，用于以目的表述的方式呈現(xiàn)文檔。在目的畫布308中發(fā)生的事件被提供到連接器。目的畫布308向連接器304通知鼠標(biāo)事件、鍵盤事件、拖動和放置事件、以及通知文檔的目的(或第二種)表述的詞匯的特有事件。
詞匯連接命令子系統(tǒng)圖3中的詞匯連接子系統(tǒng)300的一部分是詞匯連接命令子系統(tǒng)313。詞匯連接命令子系統(tǒng)313創(chuàng)建詞匯連接命令315，詞匯連接命令315用來執(zhí)行與詞匯連接子系統(tǒng)300相關(guān)的指令?？赏ㄟ^內(nèi)建的命令模板3131來創(chuàng)建詞匯連接命令，和/或可通過在腳本系統(tǒng)314中使用腳本語言從無到有地創(chuàng)建命令而創(chuàng)建詞匯連接命令。
命令模板的例子包括“If”命令模板、“When”命令模板、“Insertfragment”命令模板等。這些模板被用來創(chuàng)建詞匯連接命令。
XPath子系統(tǒng)XPath子系統(tǒng)316是文檔處理和管理系統(tǒng)的一個關(guān)鍵組件，因為它有助于實現(xiàn)詞匯連接。連接器304通常包括XPath信息。如上所述，詞匯連接的任務(wù)是將源DOM樹中的變化反映到目的DOM樹中。XPath信息包括一個或多個用來確定源DOM樹中需要被觀察以確定改變/修改的子集的XPath表達式。
源DOM樹、目的DOM樹和連接器樹的概述源DOM樹是對轉(zhuǎn)換為另一種詞匯之前以一種詞匯表述的文檔進行表述的DOM樹或區(qū)。在源DOM樹中的節(jié)點被稱為源節(jié)點。
另一方面，目的DOM樹則表示用于在利用映射進行轉(zhuǎn)換之后以另一種詞匯表述的同一文檔的DOM樹或區(qū)，該映射已在前面結(jié)合詞匯連接描述。目的DOM樹中的節(jié)點被稱為目的節(jié)點。
連接器樹是基于連接器的分級表述，用來表述源節(jié)點和目的節(jié)點之間的連接。連接器觀察源節(jié)點和對源文檔進行的修改。連接器隨后修改目的DOM樹。事實上，只有連接器是能夠修改目的DOM樹的對象。
文檔處理和管理系統(tǒng)中的事件流為了能夠使用，程序必需對來自用戶的命令進行響應(yīng)。事件是一種描述和執(zhí)行用戶對程序?qū)嵤┑膭幼鞯姆绞?。許多高級語言例如JAVA依靠描述用戶動作的事件。在現(xiàn)有技術(shù)中，程序不得不主動收集用于理解用戶動作和通過自身執(zhí)行用戶動作的信息。這可能意味著，例如，在對程序初始化后，程序進入重復(fù)地查看用戶是否對屏幕、鍵盤和鼠標(biāo)等執(zhí)行了任何動作、并接著采取適當(dāng)動作的循環(huán)。然而，這種處理可能難以操控。此外，這種處理在等候用戶作某些事情時，還需要執(zhí)行循環(huán)的程序，從而消耗了CPU周期。
許多語言通過包含不同的范例來解決這些問題，其中的一個范例構(gòu)成了所有現(xiàn)代的window系統(tǒng)的基礎(chǔ)事件驅(qū)動程序。在這種范例中，所有的用戶動作屬于被稱為“事件”的事務(wù)的抽象集合。一種事件足夠詳細地描述了特殊的用戶動作。在感興趣的事件發(fā)生時，這種系統(tǒng)通知程序，而不是程序主動地收集用戶生成的事件。以這種方式處理用戶交互的程序被稱為“事件驅(qū)動”。
這通常使用事件類來進行處理，其中事件類捕獲了所有用戶生成事件的基礎(chǔ)特性。
文檔處理和管理系統(tǒng)定義和使用其自身的事件以及處理這些事件的方式。幾種類型的事件被使用。例如，鼠標(biāo)事件是來自用戶的鼠標(biāo)動作的事件。與鼠標(biāo)有關(guān)的用戶動作由畫布210傳遞到鼠標(biāo)事件。因此，畫布可以被認為是用戶與系統(tǒng)交互的最前沿。如果需要，最前沿的畫布將把其與事件有關(guān)的內(nèi)容傳遞到其下級(children)。
另一方面，按鍵事件從畫布210產(chǎn)生。按鍵事件具有瞬時的焦點，即，按鍵事件涉及任意瞬時的活動。進入到畫布210的按鍵事件接著被傳遞到其上級(parent)。鍵盤輸入通過能夠處理字符串插入的不同事件而被處理。在使用鍵盤插入字符時，將觸發(fā)處理字符串插入的事件。其他的“事件”包括例如拖動事件、放置事件和其他能夠以與鼠標(biāo)事件相似的方式處理的事件。
在詞匯連接之外處理事件使用事件線程對事件進行傳遞。在接收到事件后，畫布210改變其狀態(tài)。如果需要，畫布210將命令1052記入到命令隊列1053。
在詞匯連接之內(nèi)處理事件通過使用詞匯連接插件301，目的畫布1106接收現(xiàn)有的事件，例如鼠標(biāo)事件、鍵盤事件、拖動和放置事件、以及詞匯的特有事件。這些事件接著被通知到連接器1104。更具體地說，詞匯連接插件301內(nèi)的事件流經(jīng)過源窗格1103、詞匯畫布1104、目的窗格1105、目的畫布1106、目的DOM樹和連接器樹1104，如圖11所示。
程序調(diào)用器及其與其他組件之間的關(guān)系在圖4(a)中更加詳細地顯示了程序調(diào)用器103及其與其他組件之間的關(guān)系。程序調(diào)用器103是在執(zhí)行環(huán)境中被執(zhí)行以啟動文檔處理和管理系統(tǒng)的基本程序。用戶應(yīng)用程序106、服務(wù)代理1041、命令調(diào)用器1051和資源109都被聯(lián)接到程序調(diào)用器103，如圖1B所示。如前所述，應(yīng)用程序102是在執(zhí)行環(huán)境中運行的組件。同樣，服務(wù)代理1041管理向系統(tǒng)增加各種功能的插件。另一方面，命令調(diào)用器1051維護用來執(zhí)行命令的類和函數(shù)，從而執(zhí)行用戶提供的指令。
插件和服務(wù)下面將參照圖4(b)詳細描述服務(wù)代理1041。如上所述，服務(wù)代理1041管理向系統(tǒng)增加各種功能的插件(及相關(guān)服務(wù))。服務(wù)1042在最底層，在該層中可以將特征增加到文檔處理和管理系統(tǒng)，或改變該系統(tǒng)中的特征。“服務(wù)”由兩部分構(gòu)成服務(wù)種類401和服務(wù)提供器402。如圖4(c)所示，單個的服務(wù)種類401可具有多個相關(guān)的服務(wù)提供器402，這些多個服務(wù)提供器402中的每一個都可操作以執(zhí)行所有或部分的特定服務(wù)種類。另一方面，服務(wù)種類401則定義了服務(wù)的類型。
服務(wù)可分為三種類型1) 向系統(tǒng)提供特定特征的特征服務(wù)；2)應(yīng)用程序服務(wù)，其是由文檔處理和管理系統(tǒng)運行的應(yīng)用程序；以及3)提供在整個文檔處理和管理系統(tǒng)中需要的特征的環(huán)境服務(wù)。
圖4(d)中示出了服務(wù)的例子。根據(jù)應(yīng)用程序服務(wù)的種類，系統(tǒng)實用程序是相應(yīng)服務(wù)提供器的示例。同樣，editlet 206是一個種類，HTML editlet和SVG editlet是相應(yīng)的服務(wù)提供器。區(qū)工廠205是服務(wù)的另一種，并具有相應(yīng)的服務(wù)提供器(未示出)。
之前描述的向文檔處理和管理系統(tǒng)增加功能的插件可以看作是由幾個服務(wù)提供器402和與其相關(guān)的類構(gòu)成的單元，如圖4(c)和4(d)所示。各個插件都應(yīng)該具有在清單文件(manifest file)中寫入的從屬和服務(wù)種類。
程序調(diào)用器和應(yīng)用程序之間的關(guān)系圖4(e)詳細顯示了程序調(diào)用器103和用戶應(yīng)用程序106之間的關(guān)系。所需的文檔、數(shù)據(jù)等從存儲中載入。所有需要的插件載入到服務(wù)代理1041。服務(wù)代理1041管理并維護所有的插件?？晌锢淼貙⒉寮黾拥较到y(tǒng)，或者可從存儲中載入其功能。在載入插件的內(nèi)容后，服務(wù)代理1041定義相應(yīng)的插件。相應(yīng)的用戶應(yīng)用程序106被創(chuàng)建，接著被載入到執(zhí)行環(huán)境101并聯(lián)接到程序調(diào)用器103。
應(yīng)用程序服務(wù)和環(huán)境之間的關(guān)系圖5(a)進一步示出了載入程序調(diào)用器103中的應(yīng)用程序服務(wù)的結(jié)構(gòu)。作為命令子系統(tǒng)105組件的命令調(diào)用器1051調(diào)用或執(zhí)行程序調(diào)用器103內(nèi)的命令1052。命令1052則是用來在文檔處理和管理系統(tǒng)中處理文檔(例如，XML文檔)和編輯相應(yīng)的XML DOM樹的指令。命令調(diào)用器1051維護執(zhí)行命令1052所需的功能和類。
服務(wù)調(diào)用器1041也在程序調(diào)用器103中執(zhí)行。用戶應(yīng)用程序106連接到用戶界面107和核心組件110。核心組件110提供了一種在所有的窗格中共享文檔的方式。核心組件110還提供字體并作為用于窗格的工具包。
圖5(a)和5(b)顯示了框架1071、菜單欄1072和狀態(tài)欄1073之間的關(guān)系。
應(yīng)用程序核心圖6(a)進一步解釋了應(yīng)用程序核心110，其保持所有文檔以及作為文檔一部分并屬于文檔的數(shù)據(jù)。應(yīng)用程序核心110聯(lián)接到管理文檔1082的文檔管理器1081。文檔管理器1081是存儲到與文檔處理和管理系統(tǒng)關(guān)聯(lián)的存儲器中的所有文檔1082的所有者(proprietor)。
為了便于在屏幕上顯示文檔，文檔管理器1081還連接到根窗格1084。剪貼板1086、快照1087、拖拉和放置601，覆蓋602的功能也被聯(lián)接到所述應(yīng)用程序核心。
如圖16(a)所示，快照1087用來撤消應(yīng)用程序狀態(tài)。在用戶調(diào)用快照功能1087時，應(yīng)用程序的當(dāng)前狀態(tài)被檢測并存儲。所存儲的狀態(tài)的內(nèi)容在應(yīng)用程序改變?yōu)榱硪粻顟B(tài)時被保存下來。在圖6(b)中示出了快照。在操作中，當(dāng)應(yīng)用程序從一個URL移動到另一個時，快照會記住先前的狀態(tài)，從而能夠無縫地執(zhí)行后退和前進操作。
在文檔管理器中組織文檔圖7(a)更加詳細地描述了文檔管理器1081以及如何在文檔管理器中組織并保存文檔。如圖7(b)所示，文檔管理器1081管理文檔1082。在圖7(a)顯示的實施例中，多個文檔中的一個為根文檔701，其他的文檔為子文檔702。文檔管理器1081連接到根文檔701，根文檔701則連接到所有的子文檔702。
如圖2和7(a)所示，文檔管理器1081耦合到文檔容器203，文檔容器203是容納所有文檔1082的對象。形成工具包(例如，XML工具包)201的一部分的工具(包括DOM服務(wù)703和IO管理器704)也提供給文檔管理器1081。再參照圖7(a)，DOM服務(wù)703基于由文檔管理器1081管理的文檔來創(chuàng)建DOM樹。各個文檔705，不管是根文檔701還是子文檔702都容納在相應(yīng)的文檔容器203中。
圖7(b)顯示了一組文檔A-E是如何以分級結(jié)構(gòu)排列的實施例。文檔A為根文檔。文檔B-D是文檔A的子文檔。文檔E則是文檔D的子文檔。圖7(c)顯示了如何將文檔的同一分級結(jié)構(gòu)顯示在屏幕上的實施例。作為根文檔的文檔A顯示為基礎(chǔ)框架。文檔A的子文檔B-D顯示為在基礎(chǔ)框架A內(nèi)的子框架。文檔D的子文檔E在屏幕上顯示為子框架D的子框架。
再參照圖7(a)，為各個文檔容器203創(chuàng)建撤消管理器706和撤消封裝器(wrapper)707。撤消管理器706和撤消封裝器707用來執(zhí)行可撤消的命令。使用該特征，可以撤消使用編輯操作對文檔所作的改變。子文檔中的改變也會涉及到根文檔。撤消操作考慮到了影響分級結(jié)構(gòu)內(nèi)其他文檔的改變，并確保了在分級結(jié)構(gòu)鏈中的所有文檔之間所維護的一致性，例如，如圖7(c)所示。
撤消封裝器707將與容器203中的子文檔相關(guān)的撤消對象進行封裝，并將它們和與根文檔相關(guān)的撤消對象耦合。撤消封裝器707使得可撤消編輯接收器709能夠收集撤消對象。撤消管理器706和撤消封裝器707連接到可撤消編輯接收器708和可撤消編輯源708。本領(lǐng)域技術(shù)人員應(yīng)該理解，文檔705可以是可撤消編輯源708，并因此可以是可撤消編輯對象。
撤消命令和撤消框架圖8(a)和8(b)進一步詳細地顯示了撤消框架和撤消命令。如圖8(a)所示，撤消命令801、重做命令802和可撤消編輯命令803是能夠排列在命令調(diào)用器1051中的命令(如圖1(b)所示)并且被相應(yīng)地執(zhí)行?？沙废庉嬅?03還進一步聯(lián)接到可撤消編輯源708和可撤消編輯接收器709。例如，可撤消編輯命令是“foo”編輯命令803和“bar”編輯命令804。
可撤消編輯命令的執(zhí)行圖8(b)顯示了可撤消編輯命令的執(zhí)行。首先，假設(shè)用戶使用編輯命令來編輯文檔705。在第一步驟S1，可撤消編輯接收器709被聯(lián)接到可撤消編輯源708，而可撤消編輯源708為文檔705的DOM樹。在第二步驟S2，基于由用戶發(fā)出的命令，使用DOM API對文檔705進行編輯。在第三步驟S3，向變化事件監(jiān)聽器通知已經(jīng)發(fā)生了改變。即，在該步驟，監(jiān)控DOM樹中所有改變的監(jiān)聽器檢測編輯操作。在第四步驟S4，用撤消管理器706將可撤消的編輯存儲為對象。在第五步驟S5，可撤消編輯接收器709與源708分開，源708可以是文檔705本身。
向系統(tǒng)載入文檔時需要的步驟上述幾個子部分描述了系統(tǒng)的各個組件和子組件。下面將描述在使用這些組件時用到的方法。圖9顯示了如何將文檔載入到文檔處理和管理系統(tǒng)中的總體圖。參照圖14-18詳細地描述各個步驟。
簡言之，文檔處理和管理系統(tǒng)從由在文檔中包含的數(shù)據(jù)構(gòu)成的二進制數(shù)據(jù)流創(chuàng)建DOM樹。為文檔中的感興趣的并位于“區(qū)”中的一部分創(chuàng)建頂節(jié)點，接著確定相應(yīng)的“窗格”。所確定的窗格從頂節(jié)點和物理屏幕表面創(chuàng)建“區(qū)”和“畫布”?！皡^(qū)”為各個節(jié)點創(chuàng)建“方面”，并為它們提供所需信息。畫布創(chuàng)建用于呈現(xiàn)DOM樹的節(jié)點的數(shù)據(jù)結(jié)構(gòu)。
具體地，參照圖19(a)，在“步驟0”，表述SHTML和SVG內(nèi)容的復(fù)雜文檔從存儲901載入。接著，為文檔創(chuàng)建DOM樹902。應(yīng)該注意，DOM樹具有頂節(jié)點905(XHTML)，以及隨著DOM樹下降到其他分支，會遇到由雙線表示的邊界，接著是用于不同詞匯SVG的頂節(jié)點906。這種復(fù)雜文檔的表述有助于理解用來呈現(xiàn)并最終顯示文檔的方式。
接下來，創(chuàng)建保持文檔的相應(yīng)文檔容器903。接著將文檔容器903聯(lián)接到文檔管理器904。DOM樹包括根節(jié)點，并且可選地包括多個次級節(jié)點。
典型地，這種文檔包括文本和圖形。因此，DOM樹例如能夠具有XHTML子樹以及SVG子樹。XHTML子樹具有XHTML頂節(jié)點905。同樣，SVG子樹具有SVG頂節(jié)點906。
再次參照圖9(a)，在步驟1，將頂節(jié)點聯(lián)接到窗格907(窗格907是屏幕的邏輯布局)。在步驟2，窗格907向應(yīng)用程序核心908請求用于頂節(jié)點的區(qū)工廠。在步驟3，應(yīng)用程序核心908返回區(qū)工廠以及editlet(其為用于頂節(jié)點906的畫布工廠)。
在步驟4，窗格907創(chuàng)建區(qū)909，區(qū)909聯(lián)接至窗格。在步驟5，區(qū)909為各個節(jié)點創(chuàng)建“方面”，并聯(lián)接到相應(yīng)的節(jié)點。在步驟6，窗格創(chuàng)建與其聯(lián)接的畫布910。在畫布910中包括各種命令。畫布910則構(gòu)建用于將文檔呈現(xiàn)在屏幕上的數(shù)據(jù)結(jié)構(gòu)。在XHTML的情況下，這包括盒樹結(jié)構(gòu)。
用于區(qū)的MVC圖9(b)使用MVC范例顯示了區(qū)的結(jié)構(gòu)概要。在這種情況下，模型(M)包括區(qū)和“方面”，這是因為它們是與文檔相關(guān)的輸入。視圖(V)對應(yīng)于畫布和數(shù)據(jù)結(jié)構(gòu)，以便將文檔在屏幕上呈現(xiàn)，這是由于這些是用戶在屏幕上看到的輸出?？刂?C)包括畫布中所包含的命令，這是由于這些命令對文檔及其關(guān)系執(zhí)行控制操作。
文檔的表述下面將使用圖10來描述復(fù)合文檔及其各種表述的實施例。在該實施例中使用的文檔包括文本和圖片。文本使用XHTML表述，而圖片用SVG表述。圖10詳細顯示了用于文檔組件的MVC表述以及相應(yīng)對象的關(guān)系。對于該示例性的表述，文檔1001聯(lián)接到保持文檔1001的文檔容器1002。文檔用DOM樹1003表述。DOM樹1003包括頂節(jié)點1004和其他子節(jié)點，如之前參照圖9(a)所述這些節(jié)點具有相應(yīng)的“方面”。
頂節(jié)點用陰影圓圈表示。非頂節(jié)點用非陰影圓圈表示。用來編輯節(jié)點的“方面”用三角形表示，并被聯(lián)接到相應(yīng)的節(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相對應(yīng)的“方面”1041還聯(lián)接到XHTML區(qū)1006。XHTML區(qū)1006則聯(lián)接到XHTML窗格1005。XHTML editlet創(chuàng)建XHTML畫布1007，XHTML畫布1007是文檔的邏輯表述。XHTML畫布1007聯(lián)接到XHTML窗格1005。XHTML畫布1007為文檔1001的XHTML組件創(chuàng)建盒樹1009。維護和呈現(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通過SVG editlet創(chuàng)建，并被聯(lián)接到SVG窗格1013。用于將文檔的SVG部分呈現(xiàn)在屏幕上的數(shù)據(jù)結(jié)構(gòu)和命令被聯(lián)接到所述SVG畫布。例如，這種數(shù)據(jù)結(jié)構(gòu)可包括圓圈、線、矩形等，如圖所示。
下面將使用先前描述的MVC范例，參照圖11(a)和11(b)進一步討論參照圖10描述的、用于對該示例性文檔進行表述的部件。圖11(a)提供了文檔1001的XHTM組件的MV關(guān)系的簡化圖。圖中的模型是用于文檔1001的XHTML組件的XHTM區(qū)1103。包括在XHTML區(qū)樹中的是幾個節(jié)點及其相應(yīng)的“方面”。相應(yīng)的XHTML區(qū)和窗格是MVC范例的模型(M)部分的一部分。MVC范例的視圖(V)部分是用于文檔1001的HTML組件的相應(yīng)的XHTML畫布1102和盒樹。通過畫布以及其中所包含的命令，文檔的XHTML部分被呈現(xiàn)在屏幕上。例如鍵盤和鼠標(biāo)輸入的事件以如圖所示的相反方向進行處理。
也就是說，源窗格具有附加功能，以起到DOM保持器的作用。圖11(b)提供了在圖11(a)中示出的用于文檔1001的組件的詞匯連接。作為源DOM保持器的源窗格1103包含了用于文檔的源DOM樹。連接器樹1004通過連接器工廠創(chuàng)建，連接器樹1004又創(chuàng)建作為目的DOM樹保持器的目的窗格1105。目的窗格1105接著以盒樹的形式被布置為XHTML目的畫布1106。
插件子系統(tǒng)、詞匯連接和連接器之間的關(guān)系圖12(a)-(c)分別顯示了與插件子系統(tǒng)、詞匯連接和連接器相關(guān)的附加細節(jié)。插件子系統(tǒng)被用來向文檔處理和管理系統(tǒng)增加功能，或與之交換功能。插件子系統(tǒng)包括服務(wù)代理1041。如圖12(a)所示，名稱為“My Own XML vocabulary(我的XML詞匯)”VCD文件耦合至包括MyOwnXML連接器工廠樹和詞匯(區(qū)工廠構(gòu)造器)的VC基本插件。聯(lián)接到服務(wù)代理1041的區(qū)工廠服務(wù)1201負責(zé)創(chuàng)建用于文檔的部分的區(qū)。editlet服務(wù)1202還被聯(lián)接到服務(wù)代理。editlet服務(wù)1202創(chuàng)建與區(qū)中的節(jié)點相對應(yīng)的畫布。
區(qū)工廠的實施例是分別創(chuàng)建XHTML區(qū)和SVG區(qū)的XHTML區(qū)工廠1211和SVG區(qū)工廠1212。如上參照示例性文檔所述，文檔的文本組件可通過創(chuàng)建XHTML區(qū)來表述，而圖片則可使用SVG區(qū)來表述。editlet服務(wù)的示例包括XHTML editlet 1221和SVG editlet 1222。
圖12(b)進一步詳細顯示了詞匯連接，如上所述，詞匯連接是文檔處理和管理系統(tǒng)的重要特征，其能夠使兩種不同方式的文檔的表述和顯示保持一致。能夠維護連接器工廠303的詞匯連接管理器是詞匯連接子系統(tǒng)的一部分，并耦合到VCD以接收詞匯連接描述符并生成詞匯連接命令301。如圖12(c)所示，連接器工廠303為文檔創(chuàng)建連接器304。如上所述，連接器觀察源DOM中的節(jié)點，并修改目的DOM中的節(jié)點，以維護兩種表述之間的一致性。
模板317表述用于一些節(jié)點的轉(zhuǎn)換規(guī)則。事實上，詞匯連接描述符文件是表示一些規(guī)則的一系列模板，這些規(guī)則用于將滿足某種路徑或規(guī)則的元素或元素集合轉(zhuǎn)換為其他的元素。詞匯模板305和命令模板3131都聯(lián)接到詞匯連接管理器302。詞匯連接管理器302是在VCD文件中所有部分的管理器對象。為一個VCD文件創(chuàng)建一個詞匯連接管理器對象。
圖12(c)表示了連接器的附加細節(jié)。連接器工廠303從源文檔中創(chuàng)建連接器。連接器工廠聯(lián)接于詞匯、模板和元素模板，并分別創(chuàng)建詞匯連接器、模板連接器和元素連接器。
詞匯連接管理器302維護連接器工廠303。為了創(chuàng)建詞匯，讀取相應(yīng)的VCD文件。接著創(chuàng)建連接器工廠303。該連接器工廠303與負責(zé)創(chuàng)建區(qū)的區(qū)工廠和負責(zé)創(chuàng)建畫布的editlet服務(wù)相關(guān)聯(lián)。
接著，用于目標(biāo)詞匯的editlet服務(wù)創(chuàng)建詞匯連接畫布。詞匯連接畫布為目的DOM樹創(chuàng)建節(jié)點。詞匯連接畫布為源DOM樹或區(qū)中的頂點元素創(chuàng)建連接器。接著，根據(jù)需要遞歸地創(chuàng)建子連接器。通過VCD文件中的一組模板創(chuàng)建連接器樹。
模板是用于將標(biāo)記語言的元素轉(zhuǎn)換為其他元素的規(guī)則集合。例如，各個模板與源DOM樹或區(qū)相匹配。在正確匹配時，創(chuàng)建頂點連接器。例如，模板“A/*/D”監(jiān)測所有從節(jié)點A開始、在節(jié)點D結(jié)束的樹分支，而不考慮節(jié)點A和節(jié)點D之間的節(jié)點。同樣，“//B”對應(yīng)于所有來自根節(jié)點的“B”節(jié)點。
VCD文件相關(guān)的連接器樹的示例下面將解釋與特定文檔相關(guān)的處理。名為MySampleXML的文檔被載入到文檔處理系統(tǒng)。圖13顯示了使用詞匯連接管理器的VCD腳本和用于文件MySampleXJML的連接器工廠樹的實施例。在圖中顯示了腳本文件內(nèi)的詞匯部分、模板部分以及它們在詞匯連接管理器中的相應(yīng)組件。在標(biāo)簽“vcd:vocabulary”下提供了屬性match＝″sample:root″、label＝″MySampleXML″以及call-template＝″sampleTemplate″。
與該實施例相對應(yīng)，在MySampleXML的詞匯連接管理器中，詞匯包括頂點元素“sample:root”。相應(yīng)的UI標(biāo)注為“MySampleXML”。在模板部分，標(biāo)簽為vcd:template，名稱為“sample template”。
如何將文件載入系統(tǒng)的詳細實施例圖14-18顯示了載入文檔MySampleXML的詳細描述。在步驟1，如圖14(a)所示，文檔從存儲1405中載入。DOM服務(wù)創(chuàng)建DOM樹和文檔管理器1406以及對應(yīng)的文檔容器1401。文檔容器聯(lián)接到文檔管理器1406。文檔包括用于XHTML和MySampleXML的子樹。XHTML頂節(jié)點1403是用于XHTML的最頂部的節(jié)點，并具有標(biāo)簽xhtml:html。另一方面，mysample頂節(jié)點1404對應(yīng)于MySampleXML，并具有標(biāo)簽sample:root。
在步驟2，如圖14(b)所示，根窗格為文檔創(chuàng)建XTML區(qū)、“方面”和畫布。創(chuàng)建與頂節(jié)點1403對應(yīng)的窗格1407、XHTML區(qū)1408、XHTML畫布1409和盒樹1410。
在步驟3，如圖14(c)所示，XHTML區(qū)域找到外來的標(biāo)簽“sample:root”，并從html畫布上的區(qū)域創(chuàng)建子窗格。
圖15顯示了步驟4，在步驟4中，子窗格獲取能夠處理“sample:root”標(biāo)簽并創(chuàng)建適當(dāng)?shù)膮^(qū)的相應(yīng)的區(qū)工廠。這種區(qū)域工廠將在能夠?qū)崿F(xiàn)區(qū)域工廠的詞匯中。區(qū)域工廠包括MySampleXML中的詞匯部分的內(nèi)容。
圖16顯示了步驟5，在步驟5中，與MySampleXML對應(yīng)的詞匯創(chuàng)建缺省的區(qū)1061。相應(yīng)的editlet被創(chuàng)建并被提供給子窗格1501，以創(chuàng)建相應(yīng)的畫布。editlet創(chuàng)建詞匯連接畫布。接著，editlet調(diào)用所述模板部分。所述連接器工廠樹也被包括在內(nèi)。連接器工廠樹創(chuàng)建所有的連接器，接著將創(chuàng)建的連接器形成連接器樹(連接器樹形成VC畫布的一部分)。根據(jù)前面的描述，對于與文檔的XHTML內(nèi)容相關(guān)的頂節(jié)點，根窗格和XHTML區(qū)的關(guān)系以及XHTML畫布和盒樹之間的關(guān)系是顯而易見的。
圖17(a)基于如上所述的源DOM樹、VC畫布和目的DOM樹之間的對應(yīng)關(guān)系顯示了步驟6。在步驟6中，各個連接器創(chuàng)建目的DOM對象。一些連接器包括XPath信息。XPath信息包括一個或多個XPath表達式，XPath表達式用來確定需要被監(jiān)測是否發(fā)生了改變/修改的源DOM樹的子集。
圖17(b)根據(jù)源、VC和目的關(guān)系顯示了步驟7。在步驟7中，詞匯從源DOM的窗格形成目的DOM樹的目的窗格。這基于源窗格來完成。接著，將目的樹的頂節(jié)點聯(lián)接到目的窗格以及相應(yīng)的區(qū)。接著為目的窗格設(shè)置其自身的editlet，editlet則創(chuàng)建目的畫布，并構(gòu)建數(shù)據(jù)結(jié)構(gòu)和命令，從而以目的格式呈現(xiàn)文檔。
圖18(a)顯示了發(fā)生于某節(jié)點的事件流，該節(jié)點不具有相應(yīng)的源節(jié)點并僅依賴于目的樹。畫布所獲取的事件(例如鼠標(biāo)事件和鍵盤事件)通過目的樹，并被傳輸?shù)皆啬０暹B接器(ElementTemplateConnector)。元素模板連接器不具有相應(yīng)的源節(jié)點，因此被傳送的事件并不是對源節(jié)點的編輯操作。如果所傳送的事件與命令模板(CommandTemplate)中描述的命令相匹配，則元素模板連接器執(zhí)行相應(yīng)的動作。否則，元素模板連接器忽略所傳送的事件。
圖18(b)顯示了發(fā)生于某目的樹的節(jié)點的事件流，該目的樹的節(jié)點通過文本連接器(TextOfConnector)與源節(jié)點相關(guān)聯(lián)。文本連接器從由源DOM樹的XPath規(guī)定的節(jié)點獲取文本節(jié)點，并將該文本節(jié)點映射為目的DOM樹的節(jié)點。畫布所獲取的事件(例如鼠標(biāo)事件和鍵盤事件)通過目的樹，并被傳送到文本連接器。文本連接器將所傳送的事件映射為相應(yīng)源節(jié)點的編輯命令，并將這些命令設(shè)置在隊列1053中。編輯命令是通過“方面”執(zhí)行的、與DOM有關(guān)的一組API調(diào)用。當(dāng)執(zhí)行設(shè)置在隊列中的命令時，編輯源節(jié)點。在編輯源節(jié)點時，發(fā)出變化事件，并且將對源節(jié)點的修改通知到注冊為監(jiān)聽器的文本連接器。文本連接器重新建立目的樹，從而在相應(yīng)的目的節(jié)點中反映出對源節(jié)點的修改。如果包含文本連接器的模板包括控制聲明，例如“foreach”和“for loop”，則連接器工廠重新評估控制聲明。在重建文本連接器后，重建目的樹。
新方案/新片段操作的細節(jié)如已經(jīng)描述的那樣，整個系統(tǒng)的結(jié)構(gòu)由可以處理標(biāo)記語言文檔(例如XML)的框架組成。為了便于解釋本發(fā)明，將該框架命名為“chimaira”。假定系統(tǒng)采用整體的分級目錄結(jié)構(gòu)，那么chimaira框架將使目錄在整個系統(tǒng)的工作區(qū)目錄內(nèi)被創(chuàng)建，并且在附隨的實施例中為了方便而將其表示為“eclipse”。圖1 9A提供了用于說明示例性框架目錄的屏幕截圖，其中用于子目錄的各種術(shù)語(Ark2Exe、ArkPlace、SacParser等)涉及框架(chimaira)目錄內(nèi)的文件的非限定性實施例。如圖所示，除了庫目錄“Libraries.src”之外，幾乎所有以“.src”結(jié)尾的目錄都是由源代碼組成的目錄，并且?guī)缀跛械脑茨夸浂紝?yīng)于先前解釋的一個插件。
新的實例詞匯與本發(fā)明一起使用，其中新的實例詞匯的命名空間例如可像“http://xmhis.chimaira.org/new-instance”一樣構(gòu)造。如上所述，在上述命名空間中使用的術(shù)語“chimaira”表示系統(tǒng)的框架目錄。新的實例詞匯的命名空間可以包括“new-fragment(新片段)”元素，以作為最外面的元素。如下面將說明的那樣，new-fragment元素可以包括唯一的“name”和參照整個目錄結(jié)構(gòu)來指定文檔位置的“save URL”屬性。新的實例詞匯隨著新活動或新事件(例如新文檔)的識別而被識別，并且在新文檔中，new-fragment元素可以用來識別文檔源的位置。
根據(jù)本發(fā)明，生成新文檔的過程包括至少兩個基本步驟。第一步驟包括建立可訪問以用于文檔生成的一個或多個預(yù)定的模型。第二步驟包括隨后選擇用于文檔生成的一個或多個預(yù)定的模型或者在用于文檔生成的一個或多個預(yù)定的模型中進行選擇。兩個步驟的關(guān)鍵在于路徑的識別，而該路徑可以用來訪問用于文檔生成的期望模型，即“訪問路徑”。額外的有用的特征在于事先識別用于存儲新生成的文檔的路徑，即“保存路徑”。但是，本領(lǐng)域的技術(shù)人員可以理解的是，用于保存文檔的路徑可以在文檔生成之后由用戶指定。至少利用通往先前存儲的模型的預(yù)定訪問路徑、以及可選地利用用于保存新文檔的預(yù)先指定的保存路徑來創(chuàng)建新文檔的全部技術(shù)在本文中被稱作“新方案”技術(shù)。
本發(fā)明一般適于與標(biāo)記語言一起使用，并且特別適于與標(biāo)記語言XML一起使用。雖然下面的說明是針對XML給出的，但是它并不是要將本發(fā)明局限于XML，而僅是為了示意。
根據(jù)傳統(tǒng)的用來定義XML腳本的BNF一樣的腳本，根據(jù)本發(fā)明的示例性實施方案的“新方案”源代碼指令的一般結(jié)構(gòu)如下new-scheme＝″new:″<template-file-ρath>(″??？″|″！/？″)<new-scheme-query>
在示例性協(xié)議中，“<template-file-path>(模板文件路徑)”組件定義通往原始文檔所在位置的路徑，并且根據(jù)來自該路徑的文檔來創(chuàng)建新文檔或定位模板。所述路徑可以是絕對路徑或相對路徑。絕對路徑直接定義原始文檔或模板的位置。與先前對框架目錄結(jié)構(gòu)的描述一致，相對路徑首先通過將該XML編輯子系統(tǒng)創(chuàng)建的用戶文檔目錄作為根目錄來定義參考文檔或模板的位置，隨后可以檢查所述參考文檔或模板的位置以選擇期望的文檔或模板。為了說明但并非限制，在附隨的實施例中采用術(shù)語“userDoc”來識別XML編輯中所使用的根目錄。
圖19B示出了根據(jù)本發(fā)明的、用于檢索可用作生成新文檔的基礎(chǔ)的模板或舊文檔的示例性過程。在步驟1901，通過鼠標(biāo)、鍵盤等的操作來發(fā)出命令，開始用于生成新文檔的過程。一旦開始了該過程，那么用戶便在下一個步驟1902發(fā)出命令，以請求可用作新文檔的根的來源的可獲得的模板或舊文檔的列表。通常通過顯示上的唯一名稱來識別模板或舊文檔，并且所述名稱是與舊文檔或模板的被指定的路徑相關(guān)的。如說明的那樣，文檔將伴隨有標(biāo)簽，但是標(biāo)簽并沒有內(nèi)容。在步驟1903，用戶可以選擇與單個模板或舊文檔相關(guān)的名稱，在被指定路徑的基礎(chǔ)上檢索文檔，并且為了便于用戶回顧而優(yōu)選顯示文檔。在步驟1905，用戶確定該文檔或模板是否是最適合用戶要求的想要的文檔或模板。如果不是(N)，則重復(fù)該過程；如果是(Y)，則將該文檔或模板用作增加新文本或修改舊文檔內(nèi)容的基礎(chǔ)，如步驟1906所示。在創(chuàng)建/編輯過程開始之后的任何時間，都可以在步驟1907保存文檔。如隨后所討論的那樣，可以預(yù)先指定用于保存文檔的位置，或者在保存文檔時由用戶指定。
上述指令的“<new-scheme-query>(新方案詢問)”部分用于傳遞與新方案活動相關(guān)的可選的信息。在非限定性實施例中，所述詢問可包括以下配置new-scheme-query＝*(query-key″＝[″query-value″]；″)可以通過“query-key(詢問關(guān)鍵字)”和“query-value(詢問值)”來傳遞附加信息?！皅uery-key”伴有各自的“query-value”，而“query-value”包含用于管理新文檔的相關(guān)信息。如果新方案詢問具有出現(xiàn)一次以上的相同的關(guān)鍵字，則僅使用第一個值。
new-scheme-query特征的使用的非限定性實施例與可保存新文檔的位置的預(yù)先說明有關(guān)。特別地，詢問關(guān)鍵字/詢問值的組合可以用來識別save-URL。詢問關(guān)鍵字將提供新創(chuàng)建的文件的優(yōu)選的保存位置。詢問值在這種情況下將是被指定為絕對路徑或相對路徑的URL。如果指定相對路徑，則將“userDoc”目錄作為根目錄來計算路徑。
詢問關(guān)鍵字的使用的另一實施例是將在“template-file-path”中指定的文件的僅一部分用作模板。如隨后所討論的那樣，在這種情況下，詢問值將成為在模板文件中定義的片段的名稱。
如上所述，新的實例詞匯的命名空間可以包括“new-fragment”元素，以作為最外面的元素。根據(jù)本發(fā)明的示例性實施方案，“new-fragment”元素具有如下的屬性配置<new-fragmentname＝idsave-url＝url>
<！-Content:new-fragment-contents->
</new-fragment>
在前述的配置中，“name”屬性是用來指定“new-fragment”的ID。利用新方案服務(wù)的特征，可以將“name”作為檢索術(shù)語，以檢索用于定義新文檔的期望片段?！皀ame”被唯一指派用來區(qū)分不同的片段，其中每個片段在不同“標(biāo)簽”的基礎(chǔ)上定義具有不同特征的XML文檔。
在新方案服務(wù)中，“save-url”屬性具有與“save-url”詢問相同的功能。特別地，“save-url”屬性指定用于保存新創(chuàng)建文檔的優(yōu)選的位置。根據(jù)示例性的實施方案，如果既設(shè)定了用于新方案服務(wù)的“save-url”詢問又設(shè)定了用于新實例詞匯的“save-url”屬性，則使用用于新方案服務(wù)的“save-url”詢問。
XPath函數(shù)也可以與“save-url”屬性一起使用。如前所述，XPath函數(shù)用作訪問DOM的路徑，并且可通過監(jiān)控作為相關(guān)信息(例如，與通往DOM的訪問路徑相關(guān)的信息)的過濾器的變化事件而操作。在使用“save-url”屬性時，通過采用波形括號({})來表示路徑，以指定XPath函數(shù)。此外，如果使用XPath函數(shù)，那么“save-url”屬性將用作上下文節(jié)點。在“save-url”詢問中登記的URL可以是來自于其中包含“new-fragment”的文檔的絕對路徑或相對路徑。
“new-fragment-contents(新片段內(nèi)容)”中包含的元素是用來創(chuàng)建新文檔的片段。根據(jù)傳統(tǒng)的W3C標(biāo)準，這些片段中的每一個都在XML中定義，并且還必須滿足以下附加的標(biāo)準a)新片段元素可以具有作為孩子元素的零個或多個處理指令子句。
b)新片段元素必須具有一個孩子元素；并且該孩子元素不能大于1或0。
c)新片段元素除了具有空白之外，不必具有任何文本。
換句話說，每個新片段元素都包含沒有正文內(nèi)容的完整的XML文檔。
當(dāng)通過“new-scheme”服務(wù)來指定特殊的片段時，從新方案指定的文件開始，對具有給定的name屬性的片段執(zhí)行檢索。如果這種片段(具有name屬性)存在，那么被指定的“new-fragment”(新片段內(nèi)容)下方的元素將用來創(chuàng)建新文檔。在創(chuàng)建新文檔時，通過波形括號({})來識別XPath函數(shù)并將對其進行評估，其中XPath函數(shù)指定一個或多個xpath表達式，而xpath表達式用于確定源DOM樹的子集，并且需要監(jiān)測將會影響目的DOM樹的、源DOM樹的子集的改變/修改。例如，如果給定<？org.chimaira vocabulary-connection href＝″{functionrdocument-uriθ}″？>
則計算″{function:document-uri()}″并且實現(xiàn)<？org.chimaira vocabulary-connectionhref＝″file:///C:/Chimaira/doc/hoge/foo.vcd″？>
應(yīng)當(dāng)注意，出現(xiàn)在處理指令或?qū)傩詢?nèi)部的XPath函數(shù)將被評估，但是XPath函數(shù)的其他部分不會被評估。用于這些XPath函數(shù)的上下文節(jié)點是具有XPath函數(shù)的節(jié)點。
圖19C說明了程序員創(chuàng)建片段和相關(guān)屬性的過程。在步驟1951，程序員將日記應(yīng)用程序顯示為詞匯連接描述符文件，這一點與前面對整個系統(tǒng)的描述一致。在隨后的步驟1952，在VCD文件的基礎(chǔ)上，識別用于新文件的期望的標(biāo)記語言文檔模板。然后，在步驟1953，程序員將輸入至少一個新片段和附隨的唯一的name屬性，其中如上所述，該name屬性用于檢索。系統(tǒng)然后將所述至少一個片段和屬性存儲于具有適當(dāng)根目錄(例如，以userDoc作為根目錄)和指定路徑的框架目錄中的位置。
圖20說明了根據(jù)本發(fā)明的(日語)日記應(yīng)用程序2050。日記應(yīng)用程序2050是包含兩個“new-fragment”的XML轉(zhuǎn)換腳本(例如，VCD)文件。name屬性“goodDay”2060和“badDay”2070分別分配給所述兩個片段。
圖21說明了源代碼2150。從圖21中可以看出，陰暗部分2160涉及新片段“goodDay”并包括“save-url”部分2161，“save-url”部分2161將用于生成URL的函數(shù)指定為名稱(“nikki-”)2162、日期(“yyyy”)2163和url 2164的連接。在具有save-url部分2171的第二個陰暗部分2170中，在用于“badDay”的源代碼中出現(xiàn)了類似的配置，并且在此無需重復(fù)與名稱2172、日期2173和url 2174有關(guān)的細節(jié)。值得注意的是，屏幕示出了在術(shù)語“nikki”上執(zhí)行的“vcd:vocabulary”匹配2180，并且示出了將調(diào)用模板分配為來源于所選的片段的新文檔的“根”。
如圖22所示，例如，一選定“goodDay”，便根據(jù)結(jié)合圖9和圖14-18描述的過程而載入文檔2250。圖22中的文檔2250是新創(chuàng)建的文檔。對save-url選項進行設(shè)置，以便將該文件保存為“nikki-2004-05-17.xml”2260，并且對片段詢問進行設(shè)置，以便在存儲的文檔中使用具有名稱“goodDay”的片段2270。該名稱可稍后用來檢索和訪問作為另一個具有相同標(biāo)簽的新文檔的模板的文檔。在“save-url”目錄地址中將存儲位置2280指定為[file:c/eclipse/workspace/doc/samples/isc/mkki/nikki.vcd]假定載入新文檔2250，并且新文檔2250具有根據(jù)所選的片段或模板而指定的根，那么根據(jù)所公開的系統(tǒng)的基本范例，所述新文檔的建立將存在為源DOM和目的DOM。然后，當(dāng)通過復(fù)制、經(jīng)由鍵盤或其他來源的輸入而接收可以被解析成相關(guān)組件的數(shù)據(jù)流時，將通過增加相連的節(jié)點來修改源DOM，并且如已經(jīng)至少結(jié)合圖3描述的那樣，該修改將被傳送到目的DOM樹。
前述的實施方案和優(yōu)點僅是示例性的，并且不應(yīng)當(dāng)被解釋成是對本發(fā)明的限制。本發(fā)明的說明書是示意性的，而不是要限制權(quán)利要求的范圍。許多替換、修改和變換對于本領(lǐng)域的技術(shù)人員來說都將是顯而易見的。
權(quán)利要求
1.一種創(chuàng)建至少具有根元素和聲明的新標(biāo)記語言文檔的方法，包括檢索新片段標(biāo)記語言文檔，所述新片段標(biāo)記語言文檔包括用于新標(biāo)記語言文件的至少一個標(biāo)記語言模板；選擇所述至少一個標(biāo)記語言模板；以及利用所述至少一個模板中的標(biāo)記語言模板來創(chuàng)建標(biāo)記語言文檔。
2.如權(quán)利要求1所述的方法，其中所述檢索步驟包括檢索預(yù)先存在的標(biāo)記語言文檔；以及所述利用標(biāo)記語言模板的步驟包括指定新文檔的創(chuàng)建。
3.如權(quán)利要求2所述的方法，進一步包括一旦生成預(yù)先存在的標(biāo)記語言文檔，便在所述舊標(biāo)記語言文檔的腳本中嵌入至少一個標(biāo)記語言模板；以及存儲所述預(yù)先存在的標(biāo)記語言文檔和所述至少一個標(biāo)記語言模板。
4.如權(quán)利要求1所述的方法，進一步包括指定所述至少一個標(biāo)記語言模板之一；以及利用所述被指定的一個標(biāo)記語言模板來生成新標(biāo)記語言文檔。
5.如權(quán)利要求1所述的方法，進一步包括預(yù)先指定將所述新標(biāo)記語言文件保存在何處、以及使用什么文件名來保存所述新標(biāo)記語言文件。
6.如權(quán)利要求1所述的方法，其中所述標(biāo)記語言為XML。
7.如權(quán)利要求1所述的方法，其在使用多個命名空間的環(huán)境內(nèi)操作，其中各個所述命名空間都能夠在其中具有多個唯一的名稱、以及多個命名空間中的公共名稱，并且其中所述根元素可應(yīng)用于所述名稱之一，但是所述根元素會由于命名空間的不同而不同。
8.一種文檔處理系統(tǒng)，其可操作以向用戶提供創(chuàng)建至少具有根元素和聲明的新標(biāo)記語言文檔的能力，所述文檔處理系統(tǒng)包括至少一個存儲器，用于至少存儲標(biāo)記語言形式的文檔模板，并且所述文檔模板包括根部、聲明和至少相關(guān)的名稱屬性；至少一個處理器，其操作以在指定的名稱屬性的基礎(chǔ)上，搜索存儲器以查找標(biāo)記語言形式的至少一個文檔模板，并且提取出所述至少一個文檔模板；至少一個顯示裝置，用于顯示來自存儲器的文件形式的日記應(yīng)用程序，所述文件為詞匯連接描述符文件，并且包含標(biāo)記語言形式的至少一個模板；以及用戶輸入，用于使用戶能夠從所述被顯示至少一個模板中選擇文檔模板。
9.如權(quán)利要求8所述的系統(tǒng)，其中所述標(biāo)記語言為XML。
10.一種文檔處理裝置，其可操作以向用戶提供創(chuàng)建至少具有根元素和聲明的新標(biāo)記語言文檔的能力，所述文檔處理裝置包括存儲器，用于至少存儲標(biāo)記語言形式的文檔模板，并且所述文檔模板包括根部、聲明和至少相關(guān)的名稱屬性；處理器，其操作以在指定的名稱屬性的基礎(chǔ)上，搜索存儲器以查找標(biāo)記語言形式的至少一個文檔模板，并且提取出所述至少一個文檔模板；顯示裝置，用于顯示來自存儲器的文件形式的日記應(yīng)用程序，所述文件為詞匯連接描述符文件，并且包含標(biāo)記語言形式的至少一個模板；以及用戶輸入，用于使用戶能夠從所述被顯示的至少一個模板中選擇文檔模板。
11.如權(quán)利要求10所述的裝置，其中所述標(biāo)記語言為XML。
12.一種用于創(chuàng)建至少具有根元素和聲明的新標(biāo)記語言文檔的用戶界面，包括新片段標(biāo)記語言文檔的顯示，其中所述新片段標(biāo)記語言文檔包括用于新標(biāo)記語言文件的至少一個標(biāo)記語言模板；用戶輸入，用于檢測所述至少一個標(biāo)記語言模板；并且所述用戶輸入用于在所述至少一個模板中選擇標(biāo)記語言模板來創(chuàng)建標(biāo)記語言文檔。
13.如權(quán)利要求12所述的用戶界面，其中所述用戶輸入操作以控制預(yù)先存在的標(biāo)記語言文檔的檢索，并指定新文檔的創(chuàng)建。
14.如權(quán)利要求13所述的用戶界面，進一步包括預(yù)先存在的標(biāo)記語言文檔的顯示，其中所述用戶輸入操作以在所述預(yù)先存在的標(biāo)記語言文檔的腳本中嵌入至少一個標(biāo)記語言模板；并且所述用戶輸入操作以影響所述預(yù)先存在的標(biāo)記語言文檔和所述至少一個標(biāo)記語言模板的存儲。
15.如權(quán)利要求12所述的用戶界面，其中所述用戶輸入操作以指定所述至少一個標(biāo)記語言模板之一；以及促使利用所述被指定的一個標(biāo)記語言模板來生成新標(biāo)記語言文檔。
16.如權(quán)利要求12所述的用戶界面，其中所述用戶輸入操作以預(yù)先指定將所述新標(biāo)記語言文件保存在何處、以及使用什么文件名來保存所述新標(biāo)記語言文件。
17.如權(quán)利要求12所述的用戶界面，其中所述用戶輸入操作以促使載入包含至少一個片段的現(xiàn)有的標(biāo)記語言轉(zhuǎn)換腳本，以便隨后選擇期望的片段。
18.如權(quán)利要求12所述的用戶界面，其中所述標(biāo)記語言為XML。
19.一種程序員界面，用于向用戶提供創(chuàng)建至少具有根元素和聲明的新標(biāo)記語言文檔的能力，所述程序員界面包括日記應(yīng)用程序的顯示，其中所述日記應(yīng)用程序具有詞匯連接描述符文件的形式；程序員輸入，用于輸入至少一個新片段，所述至少一個新片段聯(lián)合名稱屬性來表述用于新標(biāo)記語言文件的標(biāo)記語言文檔模板；程序員輸入，用于存儲所述至少一個新片段及其相關(guān)的名稱屬性。
20.如權(quán)利要求19所述的程序員界面，其中所述標(biāo)記語言為XML。
21.一種存儲介質(zhì)，其中記錄有用于使計算機執(zhí)行用于創(chuàng)建至少具有根元素和聲明的新標(biāo)記語言文檔的方法的程序，所述方法包括檢索新片段標(biāo)記語言文檔，所述新片段標(biāo)記語言文檔包括用于新標(biāo)記語言文件的至少一個標(biāo)記語言模板；檢測所述至少一個標(biāo)記語言模板；以及利用所述至少一個模板中的標(biāo)記語言模板來創(chuàng)建標(biāo)記語言文檔。
22.如權(quán)利要求21所述的存儲介質(zhì)，其中根據(jù)所述方法所述檢索步驟包括檢索預(yù)先存在的標(biāo)記語言文檔；以及所述利用標(biāo)記語言模板的步驟包括指定新文檔的創(chuàng)建。
23.如權(quán)利要求22所述的存儲介質(zhì)，其中所述方法進一步包括一旦生成舊XML文檔，便在所述預(yù)先存在的標(biāo)記語言文檔的腳本中嵌入至少一個標(biāo)記語言模板；以及存儲所述預(yù)先存在的標(biāo)記語言文檔和所述至少一個標(biāo)記語言模板。
24.如權(quán)利要求21所述的存儲介質(zhì)，其中所述方法進一步包括指定所述至少一個標(biāo)記語言模板之一；以及利用所述被指定的一個標(biāo)記語言模板來生成新標(biāo)記語言文檔。
25.如權(quán)利要求21所述的存儲介質(zhì)，其中所述方法進一步包括預(yù)先指定將所述新標(biāo)記語言文件保存在何處、以及使用什么文件名來保存所述新標(biāo)記語言文件。
26.如權(quán)利要求21所述的存儲介質(zhì)，其中所述標(biāo)記語言為XML。
全文摘要
一種創(chuàng)建至少具有根元素和聲明的新XML文檔的方法。所述方法包括從存儲器中檢索新片段XML文檔，所述新片段XML文檔包括用于本身具有根元素的新XML文件的至少一個XML模板。然后選擇至少一個XML模板，并利用被選擇的XML模板來創(chuàng)建XML文檔。還提供了能夠?qū)崿F(xiàn)上述方法的用戶和程序員界面以及裝置和系統(tǒng)結(jié)構(gòu)。
文檔編號G06F15/00GK101073076SQ200580026208
公開日2007年11月14日 申請日期2005年8月2日 優(yōu)先權(quán)日2004年8月2日
發(fā)明者大島教雄 申請人:佳思騰軟件公司