用於在標記語言環境中將事件指派給動作的文檔處理和管理方法

2023-06-05 21:29:11 3

專利名稱：：用於在標記語言環境中將事件指派給動作的文檔處理和管理方法
技術領域：
：本發明涉及一種用於在標記語言環境中將至少一個事件指派給動作的方法。
背景技術：
：概要網際網路的出現導致由用戶處理和管理的文檔的數目近乎指數增長。形成網際網路核心的全球資訊網聯合會(亦即通常所說的Web)包括由這些文檔構成的大規模數據中心庫。除了文檔，Web還提供用於這些文檔的信息檢索系統。這些文檔通常為標記語言格式，一種簡單且常用的標記語言是超文本標記語言(HTML)。這種文檔還包括指向可能位於該Web其它部分中的其它文檔的連結。可擴展標記語言(XML)是另一種更高級、更常用的標記語言。用於訪問和查看該文檔Web的簡單瀏覽器用(面向對象的)程式語言(例如Java)來開發。以標記語言為格式的文檔通常在瀏覽器和其它應用程式中表述為樹型數據結構的格式。這種表述與文檔的語法分析樹相對應。文檔對象模型(DOM)是一種眾所周知的用於表述和操作文檔的基於樹的數據結構模型。文檔對象模型提供了用於表述文檔的標準對象集合，包括HTML和XML文檔。DOM包括兩個基本組件，即，如何將表述文檔中組件的對象進行組合的標準模型，以及用於訪問和操作它們的標準接口。應用程式開發者能夠支持DOM作為其自身的特定數據結構的接口和應用程式接口(API)。另一方面，創建文檔的應用程式開發者可使用標準DOM接口而不是使用其自身API的特定接口。因此，由於這種能夠提供標準的能力，DOM能有效地增加各種環境中、尤其是Web上的文檔的互操作性。已經定義了DOM的幾種變化，由不同的編程環境和應用程式來使用。DOM樹是基於相應的DOM的內容對文檔的分級表述。DOM樹包括「根」以及從根產生的一個或多個「節點」。在某些情況下，根表述整個文檔。中間節點可表述元素，諸如表及表中的行和列。DOM樹的「葉子」通常表述數據，例如不可進一步分解的文本項目或圖像。DOM樹中的各個節點可與屬性相關聯，屬性描述了由節點表述的元素的參數，例如字體、大小、顏色、縮進等。雖然HTML是一種創建文檔的常用語言，但它是格式和版式語言。HTML不是一種數據描述語言。表述HTML文檔的DOM樹的節點是與HTML格式標籤相對應的預先定義的元素。由於HTML通常不提供任何數據描述，也不提供任何對數據的標籤/標註，因此，常常難以對HTML文檔中的數據進行查詢。網絡設計者的目標是使得Web文檔能夠被軟體應用程式查詢或處理。獨立顯示的分級組織的語言能夠通過這種方式查詢和處理。諸如XML(可擴展標記語言)的標記語言能夠提供這些特徵。與HTML相反，眾所周知，XML的優點是使得文檔設計者能夠使用可自由定義的「標籤」來對數據元素進行標註。上述數據元素可進行分級組織。另外，XML文檔可包含文檔類型定義(DTD)，它是對文檔中所使用的「語法」(標籤及其相互關係)的描述。使用CSS(層疊樣式表)或XSL(XML樣式語言)，以定義結構化的XML文檔的顯示方法。與DOM、HTML、XML、CSS、XSL有關的其它信息以及相關語言特徵也可從Web獲取，例如，http//www.w3.org/TR/。XPath提供了用於對XML文檔的部分進行尋址的公共的語法和語義。所述功能的一個示例是對與XML文檔相對應的DOM樹進行遍歷。它提供了用於操作與XML文檔的各種表述相關聯的字符串、數字和布爾字符的基本工具。XPath對XML文檔的摘要、邏輯結構(例如，DOM樹)、而不是其表面語法進行操作。這種表面語法例如可以包括序列中的線位置或字符位置。使用XPath，能夠在分級結構中(例如，在XML文檔的DOM樹中)進行定位。除了用於尋址的用途之外，XPath還被設計用來測試DOM樹中的節點是否與某個模式相匹配。其它涉及XPath的細節可在http//www.w3.org/TR/XPath中找到。假設XML的有益效果和特徵已經公知，需要一種能夠對標記語言(例如，XML)構建的文檔進行處理的有效的文檔處理和管理系統，並提供一種用於創建和修改這些文檔的友好的用戶界面。可擴展標記語言(XML)特別適合作為用於複雜文檔的格式，或者特別適合用於這種情況的格式，即，某個文檔的相關數據與其它文檔的數據通過網絡等共用的情況。已經開發出許多用於創建、顯示和編輯XML文檔的應用程式(例如，參見日本已公開的專利申請No.2001-290804)。可隨意地定義詞彙。因此理論上，可能存在無限多個詞彙。然而，不可能單獨提供這些詞彙專用的顯示/編輯環境。在相關技術中，如果以不具有專用編輯環境的詞彙來描述文檔，那麼由文本數據構成的文檔的原始碼(source)可直接使用文本編輯器等進行編輯。用於處理和管理XML文檔的現有的應用程式具有妨礙其被廣泛接受的顯著的局限性。例如，在某些現有技術的XML文檔處理系統中，可以看到表達內容的XML文檔與其顯示方法無關的特徵。雖然該特徵可能在表面上被視為一種優勢，但是它實際上是不利的，這是因為用戶不能直接對其進行編輯。為了解決這一問題，某些現有技術的XML文檔處理系統特別設計了用於接收XML輸入的屏幕。但是，這種屏幕設計的靈活性是有限的。這是因為這種XML文檔處理系統的屏幕設計必須預先進行硬編碼(hardcode)。由於這一局限性，XSLT作為用於樣式表語言的標準之一被開發。這種技術能夠將用戶從硬編碼工作中釋放出來，並且與顯示XML文檔的可應用方法相兼容。然而，利用XSLT，不能夠僅利用XML文檔的顯示版本來實現對該XML文檔的編輯。此外，現有技術的XML處理系統依賴於「架構(schema)」的設置。因此，一旦確定了架構，那麼僅僅那些與來自頂層的架構結構相對應的XML文檔能夠由處理系統來處理。換言之，這種系統是過度限制性的、硬性(rigid)系統。在已公開的系統中，不存在上述限制。整個XML文檔的結構不需要硬性確定。通過將具有各種結構的複合XML文檔分為多個較小的部分，能夠安全地處理該複合XML文檔。將所述較小的部分單獨分配到編輯模塊，從而能夠獲得更大的靈活性。另外，所述編輯模塊可以優選用插件來表述。此外，不受硬編碼限制，用戶能夠實現靈活的屏幕設計。簡言之，可以實現WYSIWYG編輯。利用被稱作模型-視圖-控制器(Model-View-Controllers，MVC)的眾所周知的圖形用戶界面(GUI)範例，對本文中所描述的系統的某些組件進行描述。所述MVC範例提供了一種將應用程式(或甚至是一個應用程式的接口)分解為三部分(即，模型、視圖和控制器)的方法。最初開發MVC是為了將傳統的輸入、處理和輸出任務映射到GUI領域。輸入-處理-輸出控制器-模型-視圖根據所述MVC範例，用戶輸入、外界建模、以及對用戶的視覺反饋被分離，並通過模型(M)、視窗(V)以及控制器(C)對象來處理。控制器可操作以解釋輸入(例如用戶的滑鼠和鍵盤輸入)，並將這些用戶動作映射為發送至模型和/或視窗的命令，以實現適當的改變。模型可操作以管理一個或多個數據元素、響應對其狀態的詢問、並響應指令以改變狀態。視窗可操作以管理顯示的矩形區域，並負責通過圖形和文本的組合將數據顯現給用戶。在傳統技術中，存在的問題是如何容易地將特定的事件指派給期望的動作。通常，人們被限制採用預設設置，該預設設置已經預先確定了指派給特定動作的事件。因此，對於用戶來說沒有簡單的方式來將特定的事件指派給期望的動作。
發明內容為了實現本發明希望的目的，提供了本發明的以下方面。根據本發明的示例性實施方案，本發明提供了一種方法，包括在標記語言環境中，將至少一個事件指派給動作。此外，根據本發明的示例性實施方案，提供了一種用於創建與可擴展標記語言相關的環境的方法，其中用戶將至少兩個事件指派給動作，並且所述至少兩個事件通過所述標記語言而嵌套。此外，根據本發明的示例性實施方案，提供了一種電腦程式產品，包括計算機可讀介質，所述計算機可讀介質包括使計算機能夠實現在標記語言環境中將至少一個事件指派給動作的方法的指令。下面參照附圖來詳細描述本發明的實施方案，在附圖中，相同的參考標記指代相同的元件，其中圖1(a)示出了能夠作為所公開的文檔處理和管理系統的一個示例性實現的基礎的組件的傳統結構；圖1(b)和1(c)示出了示例性的文檔處理和管理系統的總體方框圖；圖2示出了文檔管理器的示例性實現的進一步細節；圖3示出了詞彙連接子系統300的示例性實現的進一步細節；圖4(a)示出了程序調用器的示例性實現及其與其它組件的關係的進一步細節；圖4(b)示出了服務代理(broker)的示例性實現及其與其它組件的關係的進一步細節；圖4(c)示出了服務的示例性實現的進一步細節；圖4(d)示出了服務的實施例；圖4(e)示出了程序調用器103與用戶應用程式106之間的關係的進一步細節；圖5(a)提供了載入程序調用器上的應用程式服務的結構的進一步細節；圖5(b)示出了框架、菜單欄和狀態欄之間的關係的實施例；圖6(a)示出了涉及應用程式核心的示例性實現的進一步細節；圖6(b)示出了涉及快照(snapshot)的示例性實現的進一步細節；圖7(a)示出了涉及文檔管理器的示例性實現的進一步細節；圖7(b)示出了一組文檔A-E如何排列為分級結構的實施例；圖7(c)示出了如圖7(b)所示的文檔的分級結構在屏幕上如何顯示的實施例；圖8(a)和8(b)提供了撤消框架和撤消命令的示例性實現的進一步細節；圖9(a)示出了文檔如何載入如圖1(b)和1(c)所示的文檔處理和管理系統中的總體圖；圖9(b)示出了使用MVC範例的區的結構的概要；圖10示出了根據本發明的文檔及其多種表述的實施例；圖11(a)示出了如圖10所示的文檔的XHTM組件的MV關係的簡化視圖；圖11(b)示出了用於如圖11(a)所示的文檔的詞彙連接；圖12(a)-12(c)示出了分別涉及插件子系統、詞彙連接與連接器的示例性實現的進一步細節；圖13示出了用於文件MySampleXML的使用詞彙連接管理器的VCD腳本和連接器工廠樹的實施例；圖14(a)-(c)示出了將示例文檔MySampleXML載入圖1(b)的示例性文檔處理和管理系統中的步驟0-3；圖15示出了將示例文檔MySampleXML載入圖1(b)的示例性文檔處理和管理系統中的步驟4；圖16示出了將示例文檔MySampleXML載入圖1(b)的示例性文檔處理和管理系統中的步驟5；圖17(a)示出了將示例文檔MySampleXML載入圖1(b)的示例性文檔處理和管理系統中的步驟6；圖17(b)示出了將示例文檔MySampleXML載入圖1(b)的示例性文檔處理和管理系統中的步驟7；圖18(a)示出了在不具有相應的源節點而僅依賴於目的樹的節點上發生的事件流；圖18(b)示出了在通過TextOfConnector與源節點相關的目的樹的節點上發生的事件流；圖19示出了包括用於演示本發明的示例性實施方案的圖片的網頁；圖20示出了包括用於演示本發明的示例性實施方案的可編輯區域的網頁；圖21示出了根據本發明的示例性實施方案的、按下「ENTER」鍵之後網頁的內容；圖22圖解說明了包括涉及下面的DIAGRAM1的XML代碼的詞彙連接描述符文件；圖23-24是用於說明本發明的各種示例性方面的XML呈現頁面。具體實施例方式下面參照附圖詳細描述本發明的示例性實施方案。權利要求僅表示本發明的邊界和界限。所討論的實現、實施方案和優點僅是示例性的，因而不應當被解釋成是對本發明的限制。本發明的說明書是示意性的，而不是要限制權利要求的範圍。對本領域的技術人員來說，許多替換、修改和改變都將是顯而易見的。圖1(a)圖解說明了能夠作為在本文中隨後詳細描述類型的文檔處理和管理系統的基礎的組件的傳統結構。裝置10包括具有CPU形式或微處理器形式的處理器11，處理器11通過通信路徑13(通常實現為總線)耦合至可為任何當前或將來能獲得的ROM和/或RAM存儲形式的存儲器12。用戶輸入14(例如滑鼠、鍵盤、語音識別系統或類似設備)的I/O接口16以及顯示設備15(或其它用戶接口)也耦合至總線用於與處理器11和存儲器12通信。如本領域所公知的那樣，諸如印表機、通信數據機等的其它設備可耦合至該裝置。該裝置可為獨立設備或者具有將多個終端以及一個或多個伺服器耦合在一起的聯網形式，或者以本領域公知的多種設置方式的其中之一。本發明並不受這些組件的結構、它們的集中式或分布式體系結構或者多種組件的通信方式的限制。另外，應該注意到，本文所討論的系統和示例性實現包括幾種具有多種功能的組件和子組件。應該注意到，這些組件和子組件可僅使用硬體、僅使用軟體以及使用硬體和軟體的組合來實現，以提供上述的多種功能。另外，硬體、軟體及其組合可使用通用計算裝置或使用專用硬體或使用通用計算裝置和專用硬體的組合來實現。因此，組件或子組件的結構包括運行特定軟體的通用/專用計算裝置，以提供該組件或子組件的功能。圖1(b)示出了一種示例性文檔處理和管理系統的總體方框圖。文檔在上述文檔處理和管理系統中被創建和編輯。這些文檔能夠以具有標記語言的特徵的任何語言來表述(例如XML)。同樣，為方便起見，已經創建了用於特定組件和子組件的術語和名稱。但是，這些不應被視作對本文公開的一般教導範圍造成了限制。所述文檔處理和管理系統可被視為具有兩個基本組件。一個組件是「執行環境」101，它是處理和管理系統運行的環境。例如，執行環境提供了協助系統以及用戶對文檔進行處理和管理的基本效用和功能。另一組件是「應用程式組件」102，它由在執行環境中運行的應用程式構成。這些應用程式包括文檔本身及其各種表述。執行環境執行環境101的關鍵組件是程序調用器103。程序調用器103是被訪問以啟動文檔處理和管理系統的基本程序。例如，當用戶登錄並啟動文檔處理和管理系統時，程序調用器103被執行。程序調用器103能夠(例如但並非限制)讀取並處理作為插件增加至文檔處理和管理系統的功能、啟動並運行應用程式、以及讀取與文檔相關的性質。當用戶希望發起計劃在執行環境中運行的應用程式時，程序調用器103找到、發起然後執行該應用程式。例如，當用戶希望對已經載入到系統中的文檔進行編輯(它是執行環境中的一種應用程式)時，程序調用器103首先找到該文檔，然後執行用於載入和編輯該文檔所必需的功能。程序調用器103聯接至幾個組件，例如插件子系統104、命令子系統105以及資源模塊109。這些組件將隨後進行更詳細描述。插件子系統插件子系統104是向文檔處理和管理系統增加功能的一種高度靈活和有效的設備。插件子系統104也能夠被用來修改和去除文檔處理和管理系統中存在的功能。此外，可使用插件子系統增加或修改多種功能。例如，如隨後將詳細描述的那樣，插件子系統可用於增加功能「editlet」，其可操作以有助於在屏幕上呈現文檔。插件editlet也有助於對增加至系統的詞彙進行編輯。插件子系統104包括服務代理1041。服務代理1041管理增加至文檔處理和管理系統的插件，從而代理已增加至文檔處理和管理系統的服務。代表期望功能的單個功能以「服務」1042的形式被增加至系統。服務1042的可用類型包括但不限於應用程式服務、區工廠服務、editlet服務、命令工廠服務、連接xpath服務、CSS計算服務等。這些服務及其與系統其餘部分的關係將隨後詳細描述，以更好地理解文檔處理和管理系統。插件和服務之間的關係是，插件是可包括一個或多個服務提供器的單元，各個服務提供器具有與之相關的一個或多個類別的服務。例如，使用具有適當軟體應用程式的單個插件，能將多個服務中的一個服務增加至系統，從而向系統增加相應的功能。命令子系統命令子系統105被用來執行與文檔的處理相關的命令形式的指令。用戶可通過執行一系列指令而執行對文檔的操作。例如，通過發出命令形式的指令，用戶在文檔管理系統中處理XML文檔，並編輯與該XML文檔相對應的XMLDOM樹。這些命令可利用鍵盤敲打、滑鼠點擊或其它有效的用戶接口動作而輸入。有時，能夠通過命令來執行一個以上的指令。在這種情況下，這些指令被封裝成單個命令並連續執行。例如，用戶可能希望將錯誤詞語替換為正確詞語。在這種情況下，第一指令可用以在文檔中找尋錯誤詞語。第二指令可用以刪除該錯誤詞語。第三指令可用以輸入正確詞語。這三個指令可被封裝成單個命令。在某些示例中，命令可具有相關功能，例如，下面將要詳細討論的「撤消」功能。這些功能可隨後分配給用來創建對象的基類。命令子系統105的一個組件是命令調用器1051，命令調用器1051可操作為選擇性地提供並執行命令。雖然圖1(b)中僅示出了一個命令調用器，但也可使用一個以上的命令調用器並同時執行一個以上的命令。命令調用器1051維護執行命令所需的功能和類。在操作中，要執行的命令1052被置於隊列1053中。命令調用器創建連續執行的命令線程。如果在命令調用器中沒有正在執行的命令，則由命令調用器1051執行待執行的命令1052。如果命令調用器正在執行命令，則新的命令被置於命令隊列1053的末尾。不過，對於各命令調用器1051而言，一次僅執行一個命令。如果指定的命令執行失敗，則命令調用器1051執行命令異常。可由命令調用器1051執行的命令的類型包括但不限於可撤消命令1054、異步命令1055以及詞彙連接命令1056。可撤消命令1054是那些如果用戶希望就能夠回退其效果的命令。可撤消命令的示例為剪切、複製、插入文本等。在操作中，當用戶突出文檔的一部分並向該部分應用剪切命令時，如果需要，通過使用可撤消命令，可使得被剪切的部分「恢復原樣(uncut)」。詞彙連接命令1056被載入詞彙連接描述符腳本文件中。詞彙連接命令1056是能夠由程式設計師定義的用戶指定命令。這些命令可以是更抽象命令的組合，例如，用於增加XML片段、刪除XML片段、設置屬性等。這些命令特別涉及對文檔進行編輯。異步命令1055是用於載入或保存由系統執行的文檔的命令。異步命令1055與可撤消命令或VC命令異步地執行。與可撤消命令不同，異步命令不能被取消。異步命令1055的級別低於所述詞彙連接命令的級別。所述異步命令是對於所述文檔處理和管理系統更具體的命令。異步命令被直接記入到命令調用器1051。另一方面，將詞彙連接命令1056解釋和轉換為異步命令，然後再將所述異步命令記入到命令調用器1051。資源資源109是向不同的類提供某些功能的對象。例如，串資源、圖標和設定鍵綁定是系統中使用的資源。應用程式組件應用程式組件102，即文檔處理系統的第二個主要特徵，在執行環境101中運行。概括而言，應用程式組件102包括實際文檔，實際文檔包括其在系統內的多個邏輯和物理表述。應用程式組件102還包括系統的、用來管理文檔的組件。應用程式組件102進一步包括用戶應用程式106、應用程式核心108、用戶界面107以及核心組件110。用戶應用程式用戶應用程式106連同程序調用器103一起被載入到系統中。用戶應用程式106是將文檔、文檔的多種表述以及與文檔進行交互所需的用戶界面特徵結合在一起的粘合劑(glue)。例如，用戶可能希望創建作為工程(project)一部分的一套文檔。載入這些文檔，創建用於文檔的適當表述，增加作為用戶應用程式106一部分的用戶界面功能。換言之，用戶應用程式106將文檔及其表述的各個方面結合在一起使得用戶能夠與形成工程一部分的文檔進行交互。一旦創建了用戶應用程式106，每當用戶希望與形成工程一部分的文檔進行交互時，用戶就能夠簡單地將用戶應用程式106載入到執行環境中。核心組件核心組件110提供了在多個窗格之間共享文檔的一種方法。如將在隨後詳細討論的那樣，窗格表述DOM樹，並處理屏幕的物理布局。例如，物理屏幕包括在屏幕內的多個窗格用於描述各條信息。實際上，由用戶在屏幕上查看的文檔可在一個或多個窗格中顯示。此外，兩個不同的文檔可以出現在屏幕上的兩個不同窗格中。屏幕的物理布局還可以具有樹型形式，如圖1(c)所示。因此，如果組件1083要作為窗格顯示在屏幕上，則該窗格可被實現為根窗格1084。作為一種選擇，它也可以是子窗格1085。根窗格1084是窗格樹根部的窗格，而子窗格1085是除了根窗格1084之外的任何窗格。核心組件110也提供字體，並充當用於文檔的多個功能性操作的源，例如，工具包(toolkit)。由核心組件110執行的任務的一個示例是在多個窗格之間移動滑鼠光標。被執行的任務的另一個示例是標記一個窗格中的文檔的一部分，並將其複製到包含不同文檔的另一窗格上。應用程式核心如上所述，應用程式組件102由被系統處理和管理的文檔組成。應用程式組件102包括對於系統內的文檔的多種邏輯和物理表述。應用程式核心108是應用程式組件102的組件。其功能是保持實際文檔及其內的所有數據。應用程式核心108包括文檔管理器1081和文檔1082本身。文檔管理器1081的多個方面將在隨後進行更詳細的描述。所述文檔管理器管理文檔1082。所述文檔管理器也連接至根窗格1084、子窗格1085、剪貼板實用程序1086以及快照實用程序1087。剪貼板實用程序1086提供了保持用戶決定增加至剪貼板的部分文檔的一種方法。例如，用戶可能希望剪切文檔的一部分，並將其保存到新的文檔上，用於稍後查看。在這種情況下，剪切的部分被增加至剪貼板。快照實用程序1087也將在稍後描述，從而當應用程式從一個狀態變為另一狀態時，能夠記住應用程式的當前狀態。用戶界面應用程式102的另一組件是用戶界面107，其為用戶提供一種與系統進行物理交互的方式。例如，以物理接口1070來實現用戶界面時，用戶使用用戶界面上載、刪除、編輯和管理文檔。用戶界面包括框架1071、菜單欄1072、狀態欄1073以及URL欄1074。如通常公知的那樣，框架可被視為物理屏幕的活動區域。菜單欄1072是屏幕的、包括為用戶提供選項的菜單的區域。狀態欄1073是屏幕的、顯示應用程式的執行狀態的區域。URL欄1074提供了輸入用於在網際網路上定位的URL地址的區域。文檔管理器和相關的數據結構圖2示出了文檔管理器1081的進一步細節。圖2包括被用來在文檔處理和管理系統內表述文檔的數據結構和組件。為了更好的理解，在這部分描述的組件通過利用模型-視圖-控制器(MVC)表述範例來進行描述。文檔管理器1081包括文檔容器(containter)203，文檔容器203保持並容納文檔處理和管理系統中的所有文檔。聯接至文檔管理器1081的工具包201為文檔管理器1081的使用提供了各種工具。例如，「DOM服務」是由工具包201提供的能夠提供創建、維護和管理與文檔相對應的DOM所需的所有功能的工具。作為工具包201提供的另一工具的「IO管理器」分別管理向系統的輸入和來自系統的輸出。同樣地，「流處理器」是一種以比特流方式來處理文檔上載的工具。這些工具形成了工具包201的組件，不過並未在圖中明確示出或指定附圖標記。根據MVC範例表述，模型(M)包括文檔的DOM樹模型202。如上所述，所有文檔均在文檔處理和管理系統中被表述為DOM樹。文檔也形成文檔容器203的一部分。DOM模型和區DOM是由W3C構建的標準。DOM標準定義了用於對節點進行操作的標準接口。在每個詞彙或每個節點的基礎上，在所述標準內提供了特定的操作。這些操作優選地被提供為API。文檔處理/管理系統提供了這種作為「方面(facet)」的節點特定API。每個「方面」都聯接到節點。通過將這種「方面」連接到節點，提供了符合DOM標準的有用的API。通過在已應用的標準DOM之上增加特定的API而不是為每個詞彙實現特定的DOM，可集中處理多種詞彙，並且可以正確地處理其中採用詞彙的任意組合的文檔。通常，DOM可以被示意性地表述為DOM樹。表述文檔的DOM樹是具有節點2021的樹。作為DOM樹的子集的區209包括該DOM樹內部的一個或多個所關注的節點。例如，僅文檔的一部分可在屏幕上顯現。文檔可見的這一部分可使用「區」209來表述。利用被稱作「區工廠」205的插件來創建、操作和處理區。雖然區表述DOM的一部分，但它也可使用一個以上的「命名空間」。如本領域中公知的那樣，命名空間是名稱的匯集或集合，這些名稱在該命名空間中是唯一。換言之，一個命名空間中不能夠出現兩個相同的名稱。「方面」及其與區的關係「方面」2022是MVC範例的模型(M)部分內的另一組件。它被用來編輯區中的節點。「方面」2022使用不會影響區本身的內容的執行過程來組織對於DOM的訪問。如以下將說明的那樣，這些過程執行與節點相關的有意義且有用的操作。各個節點2021具有相應的2022。通過利用「方面」來執行操作而不是直接對DOM中的節點進行操作，DOM的完整性得以確保。否則，如果直接對節點執行操作，那麼幾個插件可能同時對DOM進行改變，從而造成不一致性。「詞彙」是屬於命名空間的標籤(例如XML標籤)的集合。如上所述，命名空間具有唯一的名稱集(在該特定情況下為標籤集)。詞彙表現為表述XML文檔的DOM樹的子樹。這種子樹包括區。在特定實施例中，標籤集的邊界由區來限定。區209是利用被稱作「區工廠服務」205的服務而創建的。如上所述，區209是對表述文檔的DOM樹的一部分的內部表述。為了提供對該文檔的上述部分的訪問，需要邏輯表述。這種邏輯表述通知計算機關於文檔如何在屏幕上進行邏輯顯示。「畫布」210是一種可操作為提供與區相對應的邏輯布局的服務。另一方面，窗格(例如窗格211)是與由畫布210提供的邏輯布局相對應的物理屏幕布局。實際上，用戶僅能看見以字符和圖片形式呈現在顯示屏上的文檔。因此，文檔必須通過用於在屏幕上描繪字符和圖片的處理來呈現在屏幕上。根據由窗格211提供的物理布局，文檔由畫布210呈現在屏幕上。與區209相對應的畫布210是利用「editlet服務」206來創建的。文檔的DOM是利用editlet服務206和畫布210來編輯的。為了維護原始文檔的完整性，editlet服務206和畫布服務210使用與區209中的一個或多個節點相對應的「方面」。這些服務並不直接操作區和DOM中的節點。「方面」是利用來自MVC範例的(C)組件(即控制器)的命令207來操作的。用戶通常通過例如移動屏幕上的光標和/或鍵入命令而與屏幕進行交互。提供屏幕的邏輯布局的畫布2010接收這些光標操作。然後，畫布2010使得對「方面」採取相應的動作。給定這一關係，光標子系統204即作為用於文檔管理器1081的MVC範例的控制器(C)。畫布2010也具有處理事件的任務。例如，畫布2010處理諸如滑鼠點擊、焦點移動和類似的用戶發起的動作等事件。區、「方面」、畫布和窗格之間的關係概述文檔管理和處理系統內的文檔可從至少四個角度來觀察，即1)用來保持文檔管理系統中的文檔的內容和結構的數據結構；2)不會影響文檔完整性就能編輯文檔內容的方式；3)文檔在屏幕上的邏輯布局；以及4)文檔在屏幕上的物理布局。區、「方面」、畫布和窗格分別表述與上述四個方面相對應的文檔管理系統的組件。撤消系統如上所述，人們希望對文檔的任何改變(例如，編輯)應該是可撤消的。例如，用戶可執行編輯操作，然後決定撤消該改變。參照圖2，撤消子系統212是文檔管理器的可撤消組件。撤消管理器2121保存可能被用戶撤消的、對文檔執行的所有操作。例如，用戶可執行命令來將文檔中的詞彙替換成另一個詞語。之後，該用戶可改變主意並決定保留原來的詞語。撤消子系統212協助上述操作。撤消管理器2121保存上述可撤消編輯2122的操作。光標子系統如上所述，MVC的控制器部分可包括光標子系統204。該光標子系統204從用戶處接收輸入。這些輸入通常具有命令和/或編輯操作的性質。因此，光標子系統204可被視作是與文檔管理器1081相關的MVC範例的控制器(C)部分。視圖如上所述，畫布2010表述要顯現在屏幕上的文檔的邏輯布局。對於XHTML文檔的特定實施例而言，畫布可包括盒樹(boxtree)，該盒樹是文檔在屏幕上如何被查看的邏輯表述。上述盒樹可包含在與文檔管理器1081有關的MVC範例的視圖(V)部分中。詞彙連接文檔處理管理系統的一個重要特徵是，能夠以兩種不同的方式(例如，以兩種標記語言)來表述和顯示文檔，從而使得兩種不同的表述自動保持一致。標記語言文檔(例如XML文檔)基於通過文檔類型定義限定的詞彙創建。詞彙則是一組標籤集，並可以任意定義，這就使得詞彙的數量可能是無限的。但是，為多個可能的詞彙中的每一個都提供專用的單獨處理和管理環境是不切實際的。詞彙連接是解決這種問題的一種方式。例如，文檔可以利用兩種或更多標記語言來表述。這些文檔例如可以是XHTML(可擴展超文本標記語言)、SVG(可縮放矢量圖形)、MathML(數學標記語言)或其他的標記語言。換句話說，標記語言可以視為和XML中的詞彙和標籤集相同。詞彙可以使用詞彙插件來實現。在文檔處理和管理系統中，以插件不可用的詞彙所描述的文檔可以通過將該文檔映射為插件可用的另一詞彙來顯示。因此，以非插件的詞彙描述的文檔仍然是可以正確顯示的。詞彙連接包括獲取定義文件、在定義文件之間進行映射、以及生成定義文件的能力。用某種詞彙描述的文檔能夠映射為另外的詞彙。因此，詞彙連接提供了通過與文檔已被映射成的詞彙相對應的顯示和編輯插件來顯示或編輯文檔的能力。應該認識到，各個文檔在文檔處理和管理系統中被描述為通常具有多個節點的DOM樹。「定義文件」為各個節點描述了該節點與其他節點之間的連接。規定了是否可以對各個節點的元素值和屬性值進行編輯。還描述了使用節點的元素值和屬性值的運算表達式。利用映射特徵，通過參考定義文件創建目的DOM樹。因此，源DOM樹和目的DOM樹之間的關係被建立並維護。詞彙連接監控源DOM樹和目的DOM樹之間的連接。在從用戶接收到編輯指令後，詞彙連接修改源DOM樹中的相關節點。發出表示已經修改了源DOM樹的「變化事件」，並且相應地修改目的DOM樹。通過使用詞彙連接，僅對於少量用戶熟知的相對次要的詞彙可以被轉換為其他主要的詞彙。因此，即便是對於那些僅有少量用戶使用的次要詞彙，也可以準確地顯示文檔，並提供理想的編輯環境。因此，作為文檔管理系統一部分的詞彙連接子系統提供了能夠對文檔進行多種表述的功能。圖3顯示了詞彙連接(VC)子系統300。VC子系統提供了一種維護同一文檔的兩種可替換表述之間的一致性的方式。在圖中具有與上面描述和標識相同的組件，這些組件相互連接從而實現上述目的。例如，兩種表述可以是同一文檔以兩種不同詞彙實現的可替換表述。如上所述，其中一種可以是源DOM樹，而另一種是目DOM樹。詞彙連接子系統利用被稱為「詞彙連接」301的插件在文檔處理和管理系統中實現詞彙連接子系統300的功能。將被表述的文檔的各詞彙305都需要相應的插件。例如，如果文檔的一部分以HTML表述，而其他部分以SVG表述，則需要相應的HTML詞彙插件和SVG詞彙插件。詞彙連接插件301為區209或窗格211創建與適當詞彙305的文檔相對應的適當的詞彙連接畫布310。使用詞彙連接301，利用轉換規則，對源DOM樹的區209的改變被轉換到另一DOM樹306的相應區。轉換規則以詞彙連接描述符(VCD)的形式給出。對於與源和目的DOM之間的這種轉換相對應的各個VCD文件，創建相應的詞彙連接管理器302。連接器連接器304連接源DOM樹中的源節點和目的DOM樹中的目的節點。連接器304可操作以觀察源DOM樹中的源節點，和與該源節點相對應的、對源文檔的修改(變化)。接著，連接器304修改相應的目的DOM樹中的節點。只有連接器304是能夠修改目的DOM樹的對象。例如，如果用戶僅能夠對源文檔和相應的源DOM樹進行修改，則連接器304對目的DOM樹進行相應的修改。連接器304被邏輯地連結在一起以形成樹結構。連接器304形成的樹被稱為「連接器樹」。連接器304通過一種服務而創建，該服務被稱為「連接器工廠」303服務。連接器工廠303從源文檔創建連接器304，並將連接器304以連接器樹的形式連結起來。詞彙連接管理器302維護連接器工廠303。如上所述，詞彙是命名空間中的標籤集。如圖3所示，通過詞彙連接301為文檔創建詞彙305。這通過分析文檔文件以及為源DOM和目的DOM之間的轉換創建適當的詞彙連接管理器302來實現。此外，在創建連接器的連接器工廠303、創建區209的區工廠服務205和創建與區中的節點相對應的畫布的editlet服務206之間建立適當的關聯。當用戶從系統中除去或刪除文檔時，對應的詞彙連接管理器302被刪除。詞彙305接著創建詞彙連接畫布。此外，連接器304和目的DOM樹306被相應地創建。應該理解，源DOM和畫布分別對應於模型(M)和視圖(V)。然而，僅當目標詞彙能夠在屏幕上呈現時，這種呈現才有意義。這種顯示通過詞彙插件來實現。詞彙插件提供用於主要的詞彙，例如XHTML、SVG和MathML。詞彙插件相對於目標詞彙使用。它們提供了一種使用詞彙連接描述符在詞彙之間進行映射的方式。僅在目標詞彙可被映射並具有預定的屏幕呈現方式時，這種映射才有意義。這種呈現方式為工業標準，例如由諸如W3C組織定義的XHTML。在需要詞彙連接時，使用詞彙連接畫布。在這種情況下，由於不能夠為源直接創建視圖，因此，不創建源畫布。在這種情況下，使用連接器樹來創建詞彙連接畫布。這種詞彙連接畫布僅僅處理事件轉換，而並不會有助於將文檔呈現在屏幕上。目的區、窗格以及畫布如上所述，詞彙連接子系統的目的在於創建並同時維護對同一文檔的兩種替換表述。第二替換表述還可以是先前被引入作為目的DOM樹的DOM樹形式。為了瀏覽第二種表述的文檔，需要目的區、畫布和窗格。在創建詞彙連接畫布後，創建相應的目的窗格307。此外，相關的目的畫布308和相應的盒樹309被創建。同樣，詞彙連接畫布還與源文檔的窗格211和區209關聯。目的畫布308提供了文檔的第二種表述方式的邏輯布局。具體地，目的畫布308提供了用戶界面功能，例如光標和選擇(selection)，用於以目的表述的方式呈現文檔。在目的畫布308中發生的事件被提供到連接器。目的畫布308向連接器304通知滑鼠事件、鍵盤事件、拖動和放置事件、以及通知文檔的目的(或第二種)表述的詞彙的特有事件。詞彙連接命令子系統圖3中的詞彙連接子系統300的一部分是詞彙連接命令子系統313。詞彙連接命令子系統313創建詞彙連接命令315，詞彙連接命令315用來執行與詞彙連接子系統300相關的指令。可通過內建的命令模板3131來創建詞彙連接命令，和/或可通過在腳本系統314中使用腳本語言從無到有地創建命令而創建詞彙連接命令。命令模板的例子包括「If」命令模板、「When」命令模板、「Insertfragment」命令模板等。這些模板被用來創建詞彙連接命令。XPath子系統XPath子系統316是文檔處理和管理系統的一個關鍵組件，因為它有助於實現詞彙連接。連接器304通常包括XPath信息。如上所述，詞彙連接的任務是將源DOM樹中的變化反映到目的DOM樹中。XPath信息包括一個或多個用來確定源DOM樹中需要被觀察以確定改變/修改的子集的XPath表達式。源DOM樹、目的DOM樹和連接器樹的概述源DOM樹是對轉換為另一種詞彙之前以一種詞彙表述的文檔進行表述的DOM樹或區。在源DOM樹中的節點被稱為源節點。另一方面，目的DOM樹則表示用於在利用映射進行轉換之後以另一種詞彙表述的同一文檔的DOM樹或區，該映射已在前面結合詞彙連接描述。目的DOM樹中的節點被稱為目的節點。連接器樹是基於連接器的分級表述，用來表述源節點和目的節點之間的連接。連接器觀察源節點和對源文檔進行的修改。連接器隨後修改目的DOM樹。事實上，只有連接器是能夠修改目的DOM樹的對象。文檔處理和管理系統中的事件流為了能夠使用，程序必需對來自用戶的命令進行響應。事件是一種描述和執行用戶對程序實施的動作的方式。許多高級語言例如JAVA依靠描述用戶動作的事件。在現有技術中，程序不得不主動收集用於理解用戶動作和通過自身執行用戶動作的信息。這可能意味著，例如，在對程序初始化後，程序進入重複地查看用戶是否對屏幕、鍵盤和滑鼠等執行了任何動作、並接著採取適當動作的循環。然而，這種處理可能難以操控。此外，這種處理在等候用戶作某些事情時，還需要執行循環的程序，從而消耗了CPU周期。許多語言通過包含不同的範例來解決這些問題，其中的一個範例構成了所有現代的window系統的基礎事件驅動程序。在這種範例中，所有的用戶動作屬於被稱為「事件」的事務的抽象集合。一種事件足夠詳細地描述了特殊的用戶動作。在感興趣的事件發生時，這種系統通知程序，而不是程序主動地收集用戶生成的事件。以這種方式處理用戶交互的程序被稱為「事件驅動」。這通常使用事件類來進行處理，其中事件類捕獲了所有用戶生成事件的基礎特性。文檔處理和管理系統定義和使用其自身的事件以及處理這些事件的方式。幾種類型的事件被使用。例如，滑鼠事件是來自用戶的滑鼠動作的事件。與滑鼠有關的用戶動作由畫布210傳遞到滑鼠事件。因此，畫布可以被認為是用戶與系統交互的最前沿。如果需要，最前沿的畫布將把其與事件有關的內容傳遞到其下級(children)。另一方面，按鍵事件從畫布210產生。按鍵事件具有瞬時的焦點，即，按鍵事件涉及任意瞬時的活動。進入到畫布210的按鍵事件接著被傳遞到其上級(parent)。鍵盤輸入通過能夠處理字符串插入的不同事件而被處理。在使用鍵盤插入字符時，將觸發處理字符串插入的事件。其他的「事件」包括例如拖動事件、放置事件和其他能夠以與滑鼠事件相似的方式處理的事件。在詞彙連接之外處理事件使用事件線程對事件進行傳遞。在接收到事件後，畫布210改變其狀態。如果需要，畫布210將命令1052記入到命令隊列1053。在詞彙連接之內處理事件通過使用詞彙連接插件301，目的畫布1106接收現有的事件，例如滑鼠事件、鍵盤事件、拖動和放置事件、以及詞彙的特有事件。這些事件接著被通知到連接器1104。更具體地說，詞彙連接插件301內的事件流經過源窗格1103、詞彙畫布1104、目的窗格1105、目的畫布1106、目的DOM樹和連接器樹1104，如圖11所示。程序調用器及其與其他組件之間的關係在圖4(a)中更加詳細地顯示了程序調用器103及其與其他組件之間的關係。程序調用器103是在執行環境中被執行以啟動文檔處理和管理系統的基本程序。用戶應用程式106、服務代理1041、命令調用器1051和資源109都被聯接到程序調用器103，如圖1B所示。如前所述，應用程式102是在執行環境中運行的組件。同樣，服務代理1041管理向系統增加各種功能的插件。另一方面，命令調用器1051維護用來執行命令的類和函數，從而執行用戶提供的指令。插件和服務下面將參照圖4(b)詳細描述服務代理1041。如上所述，服務代理1041管理向系統增加各種功能的插件(及相關服務)。服務1042在最底層，在該層中可以將特徵增加到文檔處理和管理系統，或改變該系統中的特徵。「服務」由兩部分構成服務種類401和服務提供器402。如圖4(c)所示，單個的服務種類401可具有多個相關的服務提供器402，這些多個服務提供器402中的每一個都可操作以執行所有或部分的特定服務種類。另一方面，服務種類401則定義了服務的類型。服務可分為三種類型1)向系統提供特定特徵的特徵服務；2)應用程式服務，其是由文檔處理和管理系統運行的應用程式；以及3)提供在整個文檔處理和管理系統中需要的特徵的環境服務。圖4(d)中示出了服務的例子。根據應用程式服務的種類，系統實用程序是相應服務提供器的示例。同樣，editlet206是一個種類，HTMLeditlet和SVGeditlet是相應的服務提供器。區工廠205是服務的另一種，並具有相應的服務提供器(未示出)。之前描述的向文檔處理和管理系統增加功能的插件可以看作是由幾個服務提供器402和與其相關的類構成的單元，如圖4(c)和4(d)所示。各個插件都應該具有在清單文件(manifestfile)中寫入的從屬和服務種類。程序調用器和應用程式之間的關係圖4(e)詳細顯示了程序調用器103和用戶應用程式106之間的關係。所需的文檔、數據等從存儲中載入。所有需要的插件載入到服務代理1041。服務代理1041管理並維護所有的插件。可物理地將插件增加到系統，或者可從存儲中載入其功能。在載入插件的內容後，服務代理1041定義相應的插件。相應的用戶應用程式106被創建，接著被載入到執行環境101並聯接到程序調用器103。應用程式服務和環境之間的關係圖5(a)進一步示出了載入程序調用器103中的應用程式服務的結構。作為命令子系統105組件的命令調用器1051調用或執行程序調用器103內的命令1052。命令1052則是用來在文檔處理和管理系統中處理文檔(例如，XML文檔)和編輯相應的XMLDOM樹的指令。命令調用器1051維護執行命令1052所需的功能和類。服務調用器1041也在程序調用器103中執行。用戶應用程式106連接到用戶界面107和核心組件110。核心組件110提供了一種在所有的窗格中共享文檔的方式。核心組件110還提供字體並作為用於窗格的工具包。圖5(a)和5(b)顯示了框架1071、菜單欄1072和狀態欄1073之間的關係。應用程式核心圖6(a)進一步解釋了應用程式核心110，其保持所有文檔以及作為文檔一部分並屬於文檔的數據。應用程式核心110聯接到管理文檔1082的文檔管理器1081。文檔管理器1081是存儲到與文檔處理和管理系統關聯的存儲器中的所有文檔1082的所有者(proprietor)。為了便於在屏幕上顯示文檔，文檔管理器1081還連接到根窗格1084。剪貼板1086、快照1087、拖拉和放置601，覆蓋602的功能也被聯接到所述應用程式核心。如圖16(a)所示，快照1087用來撤消應用程式狀態。在用戶調用快照功能1087時，應用程式的當前狀態被檢測並存儲。所存儲的狀態的內容在應用程式改變為另一狀態時被保存下來。在圖6(b)中示出了快照。在操作中，當應用程式從一個URL移動到另一個時，快照會記住先前的狀態，從而能夠無縫地執行後退和前進操作。在文檔管理器中組織文檔圖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服務703和IO管理器704)也提供給文檔管理器1081。再參照圖7(a)，DOM服務703基於由文檔管理器1081管理的文檔來創建DOM樹。各個文檔705，不管是根文檔701還是子文檔702都容納在相應的文檔容器203中。圖7(b)顯示了一組文檔A-E是如何以分級結構排列的實施例。文檔A為根文檔。文檔B-D是文檔A的子文檔。文檔E則是文檔D的子文檔。圖7(c)顯示了如何將文檔的同一分級結構顯示在屏幕上的實施例。作為根文檔的文檔A顯示為基礎框架。文檔A的子文檔B-D顯示為在基礎框架A內的子框架。文檔D的子文檔E在屏幕上顯示為子框架D的子框架。再參照圖7(a)，為各個文檔容器203創建撤消管理器706和撤消封裝器(wrapper)707。撤消管理器706和撤消封裝器707用來執行可撤消的命令。使用該特徵，可以撤消使用編輯操作對文檔所作的改變。子文檔中的改變也會涉及到根文檔。撤消操作考慮到了影響分級結構內其他文檔的改變，並確保了在分級結構鏈中的所有文檔之間所維護的一致性，例如，如圖7(c)所示。撤消封裝器707將與容器203中的子文檔相關的撤消對象進行封裝，並將它們和與根文檔相關的撤消對象耦合。撤消封裝器707使得可撤消編輯接收器709能夠收集撤消對象。撤消管理器706和撤消封裝器707連接到可撤消編輯接收器708和可撤消編輯源708。本領域技術人員應該理解，文檔705可以是可撤消編輯源708，並因此可以是可撤消編輯對象。撤消命令和撤消框架圖8(a)和8(b)進一步詳細地顯示了撤消框架和撤消命令。如圖8(a)所示，撤消命令801、重做命令802和可撤消編輯命令803是能夠排列在命令調用器1051中的命令(如圖1(b)所示)並且被相應地執行。可撤消編輯命令803還進一步聯接到可撤消編輯源708和可撤消編輯接收器709。例如，可撤消編輯命令是「foo」編輯命令803和「bar」編輯命令804。可撤消編輯命令的執行圖8(b)顯示了可撤消編輯命令的執行。首先，假設用戶使用編輯命令來編輯文檔705。在第一步驟S1，可撤消編輯接收器709被聯接到可撤消編輯源708，而可撤消編輯源708為文檔705的DOM樹。在第二步驟S2，基於由用戶發出的命令，使用DOMAPI對文檔705進行編輯。在第三步驟S3，向變化事件監聽器通知已經發生了改變。即，在該步驟，監控DOM樹中所有改變的監聽器檢測編輯操作。在第四步驟S4，用撤消管理器706將可撤消的編輯存儲為對象。在第五步驟S5，可撤消編輯接收器709與源708分開，源708可以是文檔705本身。向系統載入文檔時需要的步驟上述幾個子部分描述了系統的各個組件和子組件。下面將描述在使用這些組件時用到的方法。圖9顯示了如何將文檔載入到文檔處理和管理系統中的總體圖。參照圖14-18詳細地描述各個步驟。簡言之，文檔處理和管理系統從由在文檔中包含的數據構成的二進位數據流創建DOM樹。為文檔中的感興趣的並位於「區」中的一部分創建頂節點，接著確定相應的「窗格」。所確定的窗格從頂節點和物理屏幕表面創建「區」和「畫布」。「區」為各個節點創建「方面」，並為它們提供所需信息。畫布創建用於呈現DOM樹的節點的數據結構。具體地，參照圖19(a)，在「步驟0」，表述SHTML和SVG內容的複雜文檔從存儲901載入。接著，為文檔創建DOM樹902。應該注意，DOM樹具有頂節點905(XHTML)，以及隨著DOM樹下降到其他分支，會遇到由雙線表示的邊界，接著是用於不同詞彙SVG的頂節點906。這種複雜文檔的表述有助於理解用來呈現並最終顯示文檔的方式。接下來，創建保持文檔的相應文檔容器903。接著將文檔容器903聯接到文檔管理器904。DOM樹包括根節點，並且可選地包括多個次級節點。典型地，這種文檔包括文本和圖形。因此，DOM樹例如能夠具有XHTML子樹以及SVG子樹。XHTML子樹具有XHTML頂節點905。同樣，SVG子樹具有SVG頂節點906。再次參照圖9(a)，在步驟1，將頂節點聯接到窗格907(窗格907是屏幕的邏輯布局)。在步驟2，窗格907向應用程式核心908請求用於頂節點的區工廠。在步驟3，應用程式核心908返回區工廠以及editlet(其為用於頂節點906的畫布工廠)。在步驟4，窗格907創建區909，區909聯接至窗格。在步驟5，區909為各個節點創建「方面」，並聯接到相應的節點。在步驟6，窗格創建與其聯接的畫布910。在畫布910中包括各種命令。畫布910則構建用於將文檔呈現在屏幕上的數據結構。在XHTML的情況下，這包括盒樹結構。用於區的MVC圖9(b)使用MVC範例顯示了區的結構概要。在這種情況下，模型(M)包括區和「方面」，這是因為它們是與文檔相關的輸入。視圖(V)對應於畫布和數據結構，以便將文檔在屏幕上呈現，這是由於這些是用戶在屏幕上看到的輸出。控制(C)包括畫布中所包含的命令，這是由於這些命令對文檔及其關係執行控制操作。文檔的表述下面將使用圖10來描述複合文檔及其各種表述的實施例。在該實施例中使用的文檔包括文本和圖片。文本使用XHTML表述，而圖片用SVG表述。圖10詳細顯示了用於文檔組件的MVC表述以及相應對象的關係。對於該示例性的表述，文檔1001聯接到保持文檔1001的文檔容器1002。文檔用DOM樹1003表述。DOM樹1003包括頂節點1004和其他子節點，如之前參照圖9(a)所述這些節點具有相應的「方面」。頂節點用陰影圓圈表示。非頂節點用非陰影圓圈表示。用來編輯節點的「方面」用三角形表示，並被聯接到相應的節點。由於文檔具有文本和圖片，所以用於該文檔的DOM樹包括XHTML部分和SVG部分。頂節點1004是XHTML子樹的最頂部的節點。該節點被聯接到XHTML窗格1005，XHTML窗格1005是文檔XHTML部分的物理表述的最頂部窗格。該頂節點1004還聯接到XHTML區1006，其中XHTML區1006是文檔1001的DOM樹的一部分。與節點1004相對應的「方面」1041還聯接到XHTML區1006。XHTML區1006則聯接到XHTML窗格1005。XHTMLeditlet創建XHTML畫布1007，XHTML畫布1007是文檔的邏輯表述。XHTML畫布1007聯接到XHTML窗格1005。XHTML畫布1007為文檔1001的XHTML組件創建盒樹1009。維護和呈現文檔的XHTML部分所需的各種命令1008也被增加到XHTML畫布1005。同樣，該文檔的SVG子樹的頂節點1010被聯接到SVG區1011，SVG區1011是文檔1001的DOM樹的、用於表述文檔的SVG組件的部分。頂節點1010被聯接到SVG窗格1013，SVG窗格1013是文檔的SVG部分的物理表述的最頂部窗格。表述文檔的SVG部分的邏輯表述的SVG畫布1012通過SVGeditlet創建，並被聯接到SVG窗格1013。用於將文檔的SVG部分呈現在屏幕上的數據結構和命令被聯接到所述SVG畫布。例如，這種數據結構可包括圓圈、線、矩形等，如圖所示。下面將使用先前描述的MVC範例，參照圖11(a)和11(b)進一步討論參照圖10描述的、用於對該示例性文檔進行表述的部件。圖11(a)提供了文檔1001的XHTM組件的MV關係的簡化圖。圖中的模型是用於文檔1001的XHTML組件的XHTM區1103。包括在XHTML區樹中的是幾個節點及其相應的「方面」。相應的XHTML區和窗格是MVC範例的模型(M)部分的一部分。MVC範例的視圖(V)部分是用於文檔1001的HTML組件的相應的XHTML畫布1102和盒樹。通過畫布以及其中所包含的命令，文檔的XHTML部分被呈現在屏幕上。例如鍵盤和滑鼠輸入的事件以如圖所示的相反方向進行處理。也就是說，源窗格具有附加功能，以起到DOM保持器的作用。圖11(b)提供了在圖11(a)中示出的用於文檔1001的組件的詞彙連接。作為源DOM保持器的源窗格1103包含了用於文檔的源DOM樹。連接器樹1004通過連接器工廠創建，連接器樹1004又創建作為目的DOM樹保持器的目的窗格1105。目的窗格1105接著以盒樹的形式被布置為XHTML目的畫布1106。插件子系統、詞彙連接和連接器之間的關係圖12(a)-(c)分別顯示了與插件子系統、詞彙連接和連接器相關的附加細節。插件子系統被用來向文檔處理和管理系統增加功能，或與之交換功能。插件子系統包括服務代理1041。如圖12(a)所示，名稱為「MyOwnXMLvocabulary(我的XML詞彙)」VCD文件耦合至包括MyOwnXML連接器工廠樹和詞彙(區工廠構造器)的VC基本插件。聯接到服務代理1041的區工廠服務1201負責創建用於文檔的部分的區。editlet服務1202還被聯接到服務代理。editlet服務1202創建與區中的節點相對應的畫布。區工廠的實施例是分別創建XHTML區和SVG區的XHTML區工廠1211和SVG區工廠1212。如上參照示例性文檔所述，文檔的文本組件可通過創建XHTML區來表述，而圖片則可使用SVG區來表述。editlet服務的示例包括XHTMLeditlet1221和SVGeditlet1222。圖12(b)進一步詳細顯示了詞彙連接，如上所述，詞彙連接是文檔處理和管理系統的重要特徵，其能夠使兩種不同方式的文檔的表述和顯示保持一致。能夠維護連接器工廠303的詞彙連接管理器是詞彙連接子系統的一部分，並耦合到VCD以接收詞彙連接描述符並生成詞彙連接命令301。如圖12(c)所示，連接器工廠303為文檔創建連接器304。如上所述，連接器觀察源DOM中的節點，並修改目的DOM中的節點，以維護兩種表述之間的一致性。模板317表述用於一些節點的轉換規則。事實上，詞彙連接描述符文件是表示一些規則的一系列模板，這些規則用於將滿足某種路徑或規則的元素或元素集合轉換為其他的元素。詞彙模板305和命令模板3131都聯接到詞彙連接管理器302。詞彙連接管理器302是在VCD文件中所有部分的管理器對象。為一個VCD文件創建一個詞彙連接管理器對象。圖12(c)表示了連接器的附加細節。連接器工廠303從源文檔中創建連接器。連接器工廠聯接於詞彙、模板和元素模板，並分別創建詞彙連接器、模板連接器和元素連接器。詞彙連接管理器302維護連接器工廠303。為了創建詞彙，讀取相應的VCD文件。接著創建連接器工廠303。該連接器工廠303與負責創建區的區工廠和負責創建畫布的editlet服務相關聯。接著，用於目標詞彙的editlet服務創建詞彙連接畫布。詞彙連接畫布為目的DOM樹創建節點。詞彙連接畫布為源DOM樹或區中的頂點元素創建連接器。接著，根據需要遞歸地創建子連接器。通過VCD文件中的一組模板創建連接器樹。模板是用於將標記語言的元素轉換為其他元素的規則集合。例如，各個模板與源DOM樹或區相匹配。在正確匹配時，創建頂點連接器。例如，模板「A/*/D」監測所有從節點A開始、在節點D結束的樹分支，而不考慮節點A和節點D之間的節點。同樣，「//B」對應於所有來自根節點的「B」節點。VCD文件相關的連接器樹的示例下面將解釋與特定文檔相關的處理。名為MySampleXML的文檔被載入到文檔處理系統。圖13顯示了使用詞彙連接管理器的VCD腳本和用於文件MySampleXJML的連接器工廠樹的實施例。在圖中顯示了腳本文件內的詞彙部分、模板部分以及它們在詞彙連接管理器中的相應組件。在標籤「vcdvocabulary」下提供了屬性match＝″sampleroot″、label＝″MySampleXML″以及call-template＝″sampleTemplate″。與該實施例相對應，在MySampleXML的詞彙連接管理器中，詞彙包括頂點元素「sampleroot」。相應的UI標註為「MySampleXML」。在模板部分，標籤為vcdtemplate，名稱為「sampletemplate」。如何將文件載入系統的詳細實施例圖14-18顯示了載入文檔MySampleXML的詳細描述。在步驟1，如圖14(a)所示，文檔從存儲1405中載入。DOM服務創建DOM樹和文檔管理器1406以及對應的文檔容器1401。文檔容器聯接到文檔管理器1406。文檔包括用於XHTML和MySampleXML的子樹。XHTML頂節點1403是用於XHTML的最頂部的節點，並具有標籤xhtmlhtml。另一方面，mysample頂節點1404對應於MySampleXML，並具有標籤sampleroot。在步驟2，如圖14(b)所示，根窗格為文檔創建XTML區、「方面」和畫布。創建與頂節點1403對應的窗格1407、XHTML區1408、XHTML畫布1409和盒樹1410。在步驟3，如圖14(c)所示，XHTML區域找到外來的標籤「sampleroot」，並從html畫布上的區域創建子窗格。圖15顯示了步驟4，在步驟4中，子窗格獲取能夠處理「sampleroot」標籤並創建適當的區的相應的區工廠。這種區域工廠將在能夠實現區域工廠的詞彙中。區域工廠包括MySampleXML中的詞彙部分的內容。圖16顯示了步驟5，在步驟5中，與MySampleXML對應的詞彙創建預設的區1061。相應的editlet被創建並被提供給子窗格1501，以創建相應的畫布。editlet創建詞彙連接畫布。接著，editlet調用所述模板部分。所述連接器工廠樹也被包括在內。連接器工廠樹創建所有的連接器，接著將創建的連接器形成連接器樹(連接器樹形成VC畫布的一部分)。根據前面的描述，對於與文檔的XHTML內容相關的頂節點，根窗格和XHTML區的關係以及XHTML畫布和盒樹之間的關係是顯而易見的。圖17(a)基於如上所述的源DOM樹、VC畫布和目的DOM樹之間的對應關係顯示了步驟6。在步驟6中，各個連接器創建目的DOM對象。一些連接器包括XPath信息。XPath信息包括一個或多個XPath表達式，XPath表達式用來確定需要被監測是否發生了改變/修改的源DOM樹的子集。圖17(b)根據源、VC和目的關係顯示了步驟7。在步驟7中，詞彙從源DOM的窗格形成目的DOM樹的目的窗格。這基於源窗格來完成。接著，將目的樹的頂節點聯接到目的窗格以及相應的區。接著為目的窗格設置其自身的editlet，editlet則創建目的畫布，並構建數據結構和命令，從而以目的格式呈現文檔。圖18(a)顯示了發生於某節點的事件流，該節點不具有相應的源節點並僅依賴於目的樹。畫布所獲取的事件(例如滑鼠事件和鍵盤事件)通過目的樹，並被傳輸到元素模板連接器(ElementTemplateConnector)。元素模板連接器不具有相應的源節點，因此被傳送的事件並不是對源節點的編輯操作。如果所傳送的事件與命令模板(CommandTemplate)中描述的命令相匹配，則元素模板連接器執行相應的動作。否則，元素模板連接器忽略所傳送的事件。圖18(b)顯示了發生於某目的樹的節點的事件流，該目的樹的節點通過文本連接器(TextOfConnector)與源節點相關聯。文本連接器從由源DOM樹的XPath規定的節點獲取文本節點，並將該文本節點映射為目的DOM樹的節點。畫布所獲取的事件(例如滑鼠事件和鍵盤事件)通過目的樹，並被傳送到文本連接器。文本連接器將所傳送的事件映射為相應源節點的編輯命令，並將這些命令設置在隊列1053中。編輯命令是通過「方面」執行的、與DOM有關的一組API調用。當執行設置在隊列中的命令時，編輯源節點。在編輯源節點時，發出變化事件，並且將對源節點的修改通知到註冊為監聽器的文本連接器。文本連接器重新建立目的樹，從而在相應的目的節點中反映出對源節點的修改。如果包含文本連接器的模板包括控制聲明，例如「foreach」和「forloop」，則連接器工廠重新評估控制聲明。在重建文本連接器後，重建目的樹。將事件指派給動作的細節根據本發明的一個方面，用戶可以在標記語言環境中將不同的事件指派給特定的動作。例如，用戶可以將按壓「ENTER」的事件指派給特殊的動作。如圖19所示，按壓「ENTER」可以允許輸入圖像文件名的動作。也就是說，在標記語言環境或文檔中，用戶可以在圖像被選中時按壓「ENTER」，然後圖像的文件名便會出現。如果用戶改變該文件名，那麼圖像也會發生改變以反映已改變的文件名。例如，如圖19所示，樣本圖片1900可以由用戶選取。然後，在圖片被選中時按壓「ENTER」鍵，圖片的URL(統一資源定位器)或標題便會出現。用戶然後輸入新圖片的URL或者輸入新的文件名。例如，如圖20所示，圖19中示出的圖片1900已消失，因為在該圖片被選中時用戶按壓了「ENTER」，並且此刻在曾經顯示圖片1900的地方顯示可編輯區域2000。在圖21中，由於用戶輸入新的文件名來代替先前被顯示的圖片，因此被顯示的圖片2100被更新，以反映已改變的文件名。通常與按壓「ENTER」鍵的事件無關的上述動作是有可能存在的，因為根據本發明，可以將這種動作指派給這種事件。此外，在本發明的示例性實施方案中，用戶可以採用用於將事件指派給動作的特殊界面。即，可以採用用戶界面來限定1)用戶「在何處」進行互動而將事件指派給動作；2)根據「什麼用戶動作」來發起命令；以及3)發起「哪個命令」。至於用戶「在何處」進行互動，可以為用戶提供文本域，例如在相應的申請(美國代理人管理號Q81676-用於編輯標記語言文檔的文檔處理和管理方法)中提到的fixerupper文本域，或者可以為用戶提供基於光標的菜單，在該菜單中向用戶顯示與用戶的光標位置對應的XML元素以及該元素的父輩，或者可以為用戶提供三維圖像、輪廓或結構化的tab用戶界面。至於三維圖像，所呈現的頁面可以是利用ARK2向用戶顯示的頁面，並且所呈現的頁面可以包括用於每個元素的多個標籤和多個被呈現的域。因此，人們可以創建具有深度的圖像。通常，文檔是以二維樣式從上部開始顯示的，但是當採用三維樣式等大地查看該文檔時，文檔看上去像是擠在一起的塔群。根元素將作為「基礎」，並且下面的所有孩子元素都將根據孩子元素的深度而成為具有一定高度的塔。輪廓是其中文檔的內容被標籤名稱替換並呈現給用戶的文檔。用戶因而可以選擇希望其與動作關聯的標籤。至於上面提到的結構化的標籤用戶界面，在呈現文檔時，可以將所呈現的屏幕分為兩個屏幕，左邊屏幕顯示代表結構的、具有不同高度的tab，而右邊屏幕顯示文檔的實際繪製的被呈現的圖像。通過在左邊屏幕上選擇tab，可以指明將哪個標籤與元素關聯。根據本發明的示例性實施方案，在與現有技術進行比較時，指明將哪些事件指派給特殊的動作並不困難。在本發明中，可以為命令設定元數據，利用元數據來設定窄(narrow)命令和/或利用(上面提到的)fixerupper操作或增量查詢來支持信息的輸入。例如，與Java腳本相比，本發明允許動作腳本的嵌套，然而在Java腳本中可能已經定義了特殊的命令。例如，如下面所闡述的，根據本發明，可以將多個事件指派給如下面的實施例中所闡述的特殊的命令(例如跳轉到幫助)actionevent＝″/MouseButton+Clicked/l″command＝″jumpToHelp″/.本發明的一個優點在於，可以覆蓋先前已指派給特定事件的動作(甚至系統定義的動作，例如通常與系統定義的按鍵組合「Control+P」對應的PRINTING(列印)動作)。通過將不同的命令綁定到位於不同子樹上的相同事件，可以使同一事件具有不同的效果。例如，考慮日記應用程式。該日記應用程式可以具有以下結構DIAGRAM1diaryday(repeatable)headingdate@weatherphoto(optional，repeatable)content圖22提供了用於該文檔的詞彙連接描述符(VCD)。在圖22所示的「diarysample.vcd」文件的第10行中，在「addEntry」命令內定義了用於增加「day」元素的命令。在第18行中，在「addPhoto」命令內定義了用於增加「photo」元素的命令。大約在第91-102行和第174-176行中，這些命令被映射到「Ctrl+E」按鍵事件。大約在第91-102行中，「Ctrl+E」按鍵事件被映射到「addEntry」命令，並且這些行在整個文檔2300內部定義了該按鍵事件的行為，如圖23所示。如果焦點位於該日記文檔之內，並且「Ctrl+E」被按壓，那麼「day」元素及其子樹將被插入到文檔中。大約在第174-1761行中，同一按鍵事件「Ctrl+E」被映射到「addPhoto」命令，因為該按鍵事件與「content」元素有關。也就是說，如果焦點位於「content」部分2400中，那麼先前用於增加日記日期條目的同一按鍵事件「Ctrl+E」現在用來向日記內容部分2400增加照片2500(如圖24所示)。這種事件的「覆蓋」是可能存在的，因為根據本發明，該動作結構允許將不同的動作「映射」到文檔的不同元素或不同部分。出現在「動作」元素下方的任何子樹都可以將先前使用過的事件映射到與先前不同的命令，並且通過將同一事件、不同的命令指派給不同的子樹，對應於不同子樹的區域將對於給定的事件產生不同的效果。如上所述，「Ctrl+E」的覆蓋效果是能夠實現的，因為「addEntry」命令被映射到「diary」、頂層、根元素(它也對應於XHTML的「本體」)，而「addPhoto」命令被映射到「content」元素/部分。因此，位於與「content」元素對應的區域上方的區域中的任何「Ctrl+E」事件都將具有「addEntry」動作的效果，而位於「content」區域或位於其下方的任何「Ctrl+E」事件都將具有「addPhoto」動作的效果。雖然在上述的實施例中「addPhoto」和「addEntry」動作都被映射到「Ctrl+E」事件，但是也可以增加一些不同的命令。例如，如果VCD的設計者決定改變文本的顏色，那麼將可能出現更多的命令。前述的實施方案和優點僅是示例性的，並且不應當被解釋成是對本發明的限制。本發明的說明書是示意性的，而不是要限制權利要求的範圍。許多替換、修改和變換對於本領域的技術人員來說都將是顯而易見的。權利要求1.一種方法，包括在標記語言環境中，將至少一個事件指派給動作。2.如權利要求1所述的方法，其中所述環境用於編輯標記語言文檔。3.如權利要求1所述的方法，其中所述標記語言為可擴展標記語言(XML)。4.如權利要求2所述的方法，其中所述標記語言為可擴展標記語言(XML)。5.如權利要求1所述的方法，其中所述至少一個事件由用戶執行，並且所述至少一個事件被指派給所述動作。6.如權利要求4所述的方法，其中所述環境為XML呈現環境。7.如權利要求1所述的方法，其中所述至少一個事件可操作為覆蓋先前對應於所述至少一個事件的、系統定義的動作。B.程式設計師界面/觀點8.一種用於創建與可擴展標記語言(XML)相關的環境的方法，其中用戶將至少一個事件指派給動作，並且所述至少一個事件被記為XML中的元素。9.一種用於創建與標記語言相關的環境的方法，其中用戶將至少兩個事件指派給動作，並且所述至少兩個事件通過所述標記語言而嵌套。10.一種電腦程式產品，包括計算機可讀介質，所述計算機可讀介質包括使計算機能夠實現在標記語言環境中將至少一個事件指派給動作的方法的指令。11.如權利要求10所述的電腦程式產品，其中所述環境用於編輯標記語言文檔。12.如權利要求10所述的電腦程式產品，其中所述標記語言為可擴展標記語言(XML)。13.如權利要求11所述的電腦程式產品，其中所述標記語言為可擴展標記語言(XML)。14.如權利要求10所述的電腦程式產品，其中所述至少一個事件由用戶執行，並且所述至少一個事件被指派給所述動作。15.如權利要求12所述的電腦程式產品，其中所述環境是XML呈現環境。16.如權利要求10所述的電腦程式產品，其中所述至少一個事件可操作為覆蓋先前對應於所述至少一個事件的、系統定義的動作。全文摘要一種用於在標記語言環境中將至少一個事件指派給動作的方法。文檔編號G06F3/00GK101052936SQ200580026298公開日2007年10月10日申請日期2005年8月2日優先權日2004年8月2日發明者和家伸明申請人:佳思騰軟體公司