數據處理裝置、文檔處理裝置和文檔處理方法

專利名稱：數據處理裝置、文檔處理裝置和文檔處理方法
技術領域：
本發明涉及數據處理技術，特別涉及處理結構化數據的數據處理裝置。
背景技術：
XML作為適用于通過網絡等與他人共享數據的格式受到人們的關注，且人們正開發用于編寫、顯示和編輯XML文檔的應用軟件(例如，請參考專利文獻1)。XML文檔由根據文檔類型定義等所定義的詞匯(標簽集)編寫。
專利文獻1特開2001-290804號公報發明內容解決問題的方案本發明的實施方式涉及數據處理裝置。該數據處理裝置的特征在于包括數據獲取裝置；定義文件獲取裝置，獲取描述所述數據的處理方法的定義文件；和移交裝置，對于所述定義文件中未描述其處理方法的數據，將所述數據的處理移交給其他處理系統。
本發明的另一實施方式也涉及數據處理裝置。該數據處理裝置的特征在于包括數據獲取裝置；定義文件獲取裝置，獲取描述所述數據的處理方法的定義文件；以及合并裝置，獲取能夠對所述定義文件中未描述處理方法的數據進行處理的其他定義文件，編入所述定義文件中。
本發明的另一實施方式是文檔處理裝置，其特征在于包括源文件獲取單元，獲取源文件，所述源文件為由標簽確定元素數據的結構化文檔文件、并混合有多種標簽集；定義文件保存單元，保存定義文件，所述定義文件描述了由屬于預定標簽集的標簽所確定的元素數據的數據變換規則，和用于將由不屬于所述預定標簽集的標簽所確定的元素數據的數據處理移交給其他處理系統的移交命令；標簽選擇單元，從源文件中依次選擇應作為數據變換處理對象的標簽；和數據變換單元，對由所選擇的標簽確定的元素數據，通過采用定義文件中的數據變換規則來執行源文件中所包含的各元素數據的數據變換，其中，在作為數據變換處理對象被選擇的標簽不屬于預定的標簽集時，所述數據變換單元根據移交命令將由該標簽確定的元素數據移交給能夠進行數據處理的其他處理系統。
例如，假定有將用戶定義的標簽集和以XHTML之類的表示方法確定的既定的標簽集混合的源文件。此時，在定義文件中可將數據變換規則記載為模板規則，以對由用戶定義標簽所確定的內容(content)或元素(element)名等的元素數據進行數據變換。另外，對于該用戶定義標簽集以外的標簽的情況，可記載向其他處理系統移交數據處理的命令。在本例中，當XHTML標簽為處理對象時，數據變換單元可以將相應部分的處理移交給作為插件等軟件模塊來提供的XHTML專用處理系統。此外，數據變換單元也可以參考記載了相對于XHTML標簽的數據變換規則的其他定義文件，對由XHTML確定的元素數據進行數據變換。
本發明的另一實施方式也是文檔處理裝置，其特征在于包括源文件獲取單元，獲取形成為結構化文檔文件的源文件，所述結構化文檔文件混合有由第一標簽集確定的元素數據和由第二標簽集確定的元素數據；定義文件保存單元，保存確定與第一標簽集對應的數據變換規則的第一定義文件、和確定與第二標簽集對應的數據變換規則的第二定義文件，以作為與標簽對應并確定元素數據變換規則的定義文件；定義文件合并單元，通過結合第一定義文件和第二定義文件來生成合并定義文件，以作為確定與第一標簽集和第二標簽集對應的數據變換規則的定義文件；標簽選擇單元，從源文件依次選擇應作為數據變換處理對象的標簽；和數據變換單元，對由選擇的標簽確定的元素數據使用合并定義文件的數據變換規則，從而對源文件中所包含的各元素數據進行數據變換。
本發明的另一實施方式是文檔處理方法。該方法包括以下步驟源文件獲取步驟，所述源文件為由標簽確定的元素數據的結構化文檔文件，并混合有多種標簽集；標簽選擇步驟，從源文件依次選擇應作為變換處理對象的標簽；定義文件載入步驟，從記錄媒體載入定義文件，所述定義文件描述了由屬于預定標簽集的標簽所確定的元素數據的數據變換規則，和用于將由不屬于所述預定標簽集的標簽所確定的元素數據的數據處理移交給其他處理系統的移交命令；數據變換步驟，對于由選擇的標簽確定的元素數據使用定義文件的數據變換規則，執行源文件中所包含的各元素數據的數據變換；和移交步驟，在作為數據變換處理對象被選擇的標簽不屬于預定的標簽集時，根據移交命令將由該標簽確定的元素數據移交給能夠進行數據處理的其他處理系統。
本發明的另一實施方式也是文檔處理方法。該方法包括以下步驟源文件獲取步驟，獲取形成為結構化文檔文件的源文件，所述結構化文檔文件混合有由第一標簽集確定的元素數據和由第二標簽集確定的元素數據；定義文件載入步驟，從記錄媒體載入確定與第一標簽集對應的數據變換規則的第一定義文件、和確定與第二標簽集對應的數據變換規則的第二定義文件，以作為與標簽對應并確定元素數據變換規則的定義文件；合并定義文件創建步驟，通過結合第一定義文件和第二定義文件來生成合并定義文件，以作為確定與第一標簽集和第二標簽集對應的數據變換規則的定義文件；標簽選擇步驟，從源文件依次選擇應作為數據變換處理對象的標簽；和數據變換步驟，通過對由選擇的標簽確定的元素數據采用合并定義文件的數據變換規則，對源文件中所包含的各元素數據進行數據變換。
但是，以上的構成元素的任意組合，對本發明的表現在方法、裝置、系統等之間的變換也屬于本發明的有效實施方式。
發明的效果根據本發明，在處理標記語言結構化的數據時，能夠提高用戶的便利性。


圖1是與前提技術相關的文檔處理裝置的構成示意圖；圖2示出了作為處理對象的XML文檔的例子；
圖3示出了將圖2所示的XML文檔映射為HTML描述的表的例子；圖4(a)示出了用于將圖2所示的XML文檔映射為圖3所示的表的定義文件的例子；圖4(b)示出了用于將圖2所示的XML文檔映射為圖3所示的表的定義文件的例子；圖5示出了當利用圖3所示的對應關系將圖2所示的用成績管理詞匯描述的XML文檔映射為HTML時顯示屏幕的例子；圖6示出的是為了用戶創建定義文件而由定義文件生成單元向用戶提示的圖形用戶界面的例子；圖7示出了利用定義文件生成單元生成的屏幕布局(layout)的另一實施例；圖8示出了文檔處理裝置提供的XML文檔的編輯屏幕的例子；圖9示出了利用文檔處理裝置編輯的XML文檔的另一例子；圖10示出了顯示圖9所示文檔的屏幕顯示的例子；圖11(a)示出了文檔處理系統的基本構成；圖11(b)是文檔處理系統的總體方框圖；圖11(c)是文檔處理系統的總體方框圖；圖12示出了文檔管理器的細節；圖13示出了詞匯連接子系統的細節；圖14示出了程序調用器與其它組成的關系的細節；圖15示出了利用程序調用器載入的應用程序服務的構造的細節；圖16示出了核心組件的細節；圖17示出了文檔管理器的細節；圖18示出了提供了撤消框架和撤消命令的細節；圖19示出了文檔處理系統中的文檔載入的情況；圖20示出了文檔及其表現的例子；圖21示出了模型與控制器關系的圖；圖22示出了分別涉及插件子系統、詞匯連接與連接器的細節；圖23示出了VCD文件的例子；圖24示出了文檔處理系統中載入復合文檔的順序的圖；
圖25示出了文檔處理系統中載入復合文檔的順序的圖；圖26示出了文檔處理系統中載入復合文檔的順序的圖；圖27示出了文檔處理系統中載入復合文檔的順序的圖；圖28示出了文檔處理系統中載入復合文檔的順序的圖；圖29示出了命令流；圖30是用于說明文檔處理裝置處理復合文檔文件的示意圖；圖31是用于說明文檔處理裝置處理復合文檔文件的示意圖；圖32是表示圖31所示的處理所用的定義文件的例子；圖33是用于說明文檔處理裝置處理復合文檔文件的示意圖；圖34是表示圖33所示的處理所用的定義文件的例子；圖35是用于說明文檔處理裝置處理復合文檔文件的示意圖；圖36是表示圖35所示的處理所用的定義文件的例子；圖37是用于說明實施方式的第一實施方式的結構的圖；圖38是表示圖37所示的處理所用的第一定義文件的例子；圖39是表示圖37所示的處理所用的第二定義文件的例子；圖40是用于說明實施方式的第一實施方式的結構的圖；圖41是表示圖40所示的處理所用的第一定義文件的例子；圖42是表示圖40所示的處理所用的第二定義文件的例子。
符號說明20文檔處理裝置22主控單元 24編輯單元30DOM單元 32DOM提供單元 34DOM生成單元36輸出單元40CSS單元 42CSS分析單元44CSS提供單元 46呈現單元 50HTML單元52，62控制單元54，64編輯單元 56，66顯示單元60SVG單元 80VC單元 82映射單元84定義文件獲取單元 86定義文件生成單元具體實施方式
(前提技術)
圖1示出了與前提技術相關的文檔處理裝置20的結構。文檔處理裝置20對結構化的文檔進行處理，該文檔中的數據被分為具有分級結構的多個組件。在本前提技術中以對作為結構化文檔一例的XML文檔進行處理為例來說明。文檔處理裝置20包括主控單元22、編輯單元24、DOM(文檔對象模塊)單元30、CSS(層疊樣式表)單元40、HTML(超文本標記語言)單元50、SVG(可縮放矢量圖形)單元60以及用作轉換單元一個示例的VC(詞匯連接)單元80。在硬件組件方面，這些單元結構可由任意計算機的CPU、存儲器、載入存儲器中的程序等來實現。這里，描述了由它們的協作而實現的功能模塊。因此，本領域技術人員能夠理解，這些功能模塊可僅通過硬件的方式、僅通過軟件的方式或通過二者相結合的方式以多種形式來實現。
主控單元22提供插件的載入或提供執行命令的框架。編輯單元24提供了用于編輯XML文檔的框架。文檔處理裝置20中的文檔的顯示和編輯功能是通過插件來實現的，而必要的插件是根據所處理的文檔類型、通過主控單元22或編輯單元24來載入的。主控單元22或編輯單元24通過參考作為處理對象的XML文檔的命名空間來確定哪個或哪些詞匯描述了待處理的XML文檔的內容，并且對應于所確定的詞匯而載入用于顯示和編輯的插件，從而執行顯示和編輯。例如，利用對HTML文檔進行顯示和編輯的HTML單元50，以及對SVG文檔進行顯示和編輯的SVG單元60等在文檔處理裝置20中被實現為處理單元。也就是說，對于各個詞匯(標簽集)，將顯示系統和編輯系統實現為插件，以使得在對HTML文檔和SVG文檔進行編輯時，分別將HTML單元50和SVG單元60與其各自的控制單元進行協同載入。如以下將描述的那樣，在要對既包括HTML又包括SVG組件的復合文檔進行處理時，既載入HTML單元50又載入SVG單元60。
通過實現以上結構，用戶能夠僅選擇必要的功能以安裝該功能，如果需要，也能夠在稍后階段增加或刪除一個和多個功能。因此，能夠有效利用記錄媒介的存儲區域(例如硬盤)，并能夠避免在執行程序的時候存儲器使用的浪費。此外，由于這一結構有利于性能擴展，因此開發者自己能夠以插件的形式處理新的詞匯，因而能夠促進開發過程。因此，用戶也能夠通過增加插件而以較低成本輕易地增加功能。
編輯單元24通過用戶接口從用戶處接收編輯指令的事件，將事件通知適當的插件并控制處理，所述處理可包括重新執行事件的重做(redo)處理以及取消事件的撤消(undo)處理。
DOM單元30包括DOM提供單元32、DOM生成單元34以及輸出部36。DOM單元30實現了與文檔對象模型(DOM)相符的功能，在XML文檔作為數據被處理時，所述文檔對象模型被定義以提供訪問方法。DOM提供單元32是滿足由編輯單元24定義的接口的DOM的實現。DOM生成單元34從XML文檔生成DOM樹。如以下將描述的那樣，當通過VC單元80將待處理的XML文檔映射為其它詞匯時，生成與映射源中的XML文檔相對應的源樹以及與映射目的中的XML文檔相對應的目的樹。在編輯的末尾，例如輸出部36輸出作為XML文檔的DOM樹。
CSS單元40提供與CSS相符的顯示功能，并包括CSS分析單元42、CSS提供單元44以及呈現單元46。CSS分析單元42具有用于分析CSS語法的分析功能。CSS提供單元44是CSS對象的實現，并執行對DOM樹的CSS層疊處理。呈現單元46是CSS的呈現引擎，并用來顯示以諸如HTML的詞匯描述的、利用CSS設置的文檔。
HTML單元50對以HTML描述的文檔進行顯示或編輯。SVG單元60對以SVG描述的文檔進行顯示或編輯。這些顯示/編輯系統以插件的形式實現，各個系統包括對文檔進行顯示的顯示單元“畫布(Canvas)”56、66、發送和接收包括編輯命令的事件的控制單元“Editlet”52、62以及在接收到編輯命令時對DOM進行編輯的編輯單元“區(zone)”54、64。在控制單元52或62從外部源接收到用于DOM樹的編輯命令時，編輯單元54或64修改DOM樹，而顯示單元56或66更新顯示。這些單元具有與被稱作MVC(Model-View-Controllers，模型-視圖一控制器)的框架相類似的結構，通常，顯示單元56及66對應于“視圖(View)”，控制單元52及62對應于“控制器(Controller)”，而編輯單元54及64和DOM實體對應于“模型(Model)”。在本前提技術的文檔處理裝置20中，不僅能夠以樹型視圖顯示格式來編輯XML文檔，而且能夠根據相應的詞匯來完成編輯。例如，HTML單元50提供了用戶界面，通過該用戶界面能夠以一種類似于Word處理器的方法對HTML文檔進行編輯，而SVG單元60提供了一種用戶界面，通過該用戶界面能夠以一種類似于圖像繪制工具的方法對SVG文檔進行編輯。
VC單元80包括映射單元82、定義文件獲取單元84以及定義文件生成單元86。通過將以某個詞匯描述的文檔映射為另一詞匯，VC單元80提供了一種框架，以通過與被映射的詞匯相對應的顯示和編輯插件來顯示或編輯文檔。在本前提技術中，該功能被稱為詞匯連接(VocabularyConnectionVC)。在VC單元80中，定義文件獲取單元84獲取描述了映射定義的腳本文件。該定義文件逐個節點地描述了節點間的對應(連接)。此時，可規定各節點的元素值或屬性值是否可以編輯。也可描述使用了節點的元素值或屬性值的運算表達式。這些功能將在稍后進行描述。映射單元82使得DOM生成單元34通過參考VC定義文件獲取單元84已經獲取的腳本文件來生成目的樹，以管理源樹與目的樹之間的對應關系。定義文件生成單元86為用戶提供圖形用戶界面，以生成定義文件。
VC單元80對源樹與目的樹之間的連接進行監控。當VC單元80通過由負責顯示的插件提供的用戶接口從用戶處接收編輯指令時，它首先修改源樹的相關節點。因此，DOM單元30將發出指示源樹已經被修改的變化事件。然后，VC單元80接收該變化事件，并對應于被修改的節點而修改目的樹的節點，以使得目的樹與源樹的修改同步。當為顯示/編輯目的樹提供必要的處理的插件(例如HTML單元50)接收了指示目的樹已經被修改的變化事件時，該插件通過參考被修改的目的樹而對顯示進行更新。通過執行將詞匯轉換為另一主要詞匯的上述結構，即使是以少數用戶使用的局部詞匯來描述文檔，也能夠顯示文檔，并提供編輯環境。
文檔處理裝置20顯示和/或編輯文檔的操作將在下文中描述。當文檔處理裝置20載入待處理的文檔時，DOM生成單元34從XML文檔生成DOM樹。主控單元22或編輯單元24通過參考待處理的XML文檔的命名空間來確定哪個詞匯描述XML文檔。如果與詞匯相對應的插件安裝在文檔處理裝置20中，則該插件被載入以顯示/編輯文檔。另一方面，如果插件并未安裝其中，則進行檢查以查看是否存在定義文件。如果存在定義文件，則定義文件獲取單元84獲取該定義文件，并根據定義生成目的樹，以使得能夠通過與被映射成的詞匯相對應的插件來顯示/編輯文檔。如果該文檔是包含多個詞匯的復合文檔，則通過與各詞匯相對應的插件來顯示/編輯該文檔的相關部分，以下將詳細描述。如果不存在定義文件，則顯示文檔的源或樹型結構，并在顯示屏中進行編輯。
圖2示出了待處理的XML文檔的例子。根據該示例性表示，XML文檔用于管理與學生已獲得的評分或分數(成績)相關的數據。作為XML文檔的上部節點的組件“成績”包括在“成績”下方為各個學生設置的多個元素“生徒”。元素“生徒”具有屬性“名前”，并包括作為子元素的學科“國語”(日語)、“數學”、“理科”以及“社會”(社會科學)。屬性“名前”存儲學生的姓名。組件“國語”、“數學”、“理科”和“社會”存儲分別為日語、數學、自然科學和社會科學的學科的測試成績。例如，姓名為“A”的學生的成績是日語為“90”、數學為“50”、自然科學為“75”以及社會科學為“60”。下文中，該文檔中使用的詞匯(標簽集)被稱作“成績管理詞匯”。
由于根據本前提技術的文檔處理裝置20不具有與成績管理詞匯的顯示和/或編輯相符或能夠處理成績管理詞匯的顯示和/或編輯的插件，因此，將使用以上描述的VC單元80，以不使用源顯示和樹顯示的其它顯示方法來顯示該文檔。也就是說，通過準備定義文件，使得成績管理詞匯可映射為已具有插件的另一詞匯，例如HTML或SVG。下面將要進行的說明是在假設已經具備了定義文件的情況下進行的，不過對于用戶本身用以創建定義文件所必需的用戶界面將在后面描述。
圖3示出了圖2中所示的XML文檔映射為以HTML描述的表的例子。在圖3所示的例子中，使以成績管理詞匯描述的“生徒”節點與以HTML描述的表(“TABLE”節點)的行(“TR”節點)相對應。各行的第一列與屬性值“名前”相對應，第二列與“國語”節點的元素值相對應，第三列與“數學”節點的元素值相對應，第四列與“理科”節點的元素值相對應，而第五列與“社會”節點的元素值相對應。因此，圖2所示的XML文檔能以HTML的列表格式來顯示。此外，這些屬性值和元素值被指定為能夠編輯，以使得用戶能夠使用HTML單元50的編輯功能在顯示屏上對這些值進行編輯。在第六列中，指定了用來計算日語、數學、自然科學以及社會科學的分數的加權平均的運算表達式，并顯示每個學生的分數的平均值。以這種方式，通過在定義文件中指定運算表達式來完成更靈活的顯示，從而提高用戶在進行編輯時的便利性。另外，將對第六列的編輯指定為不允許，以使得不能單獨對平均值本身進行編輯。因此，在映射定義中，能夠指定可編輯或不能編輯，以避免用戶可能的錯誤操作。
圖4(a)和4(b)表示定義文件的例子，以將圖2所示的XML文檔映射為圖3所示的表。該定義文件通過被定義用于和定義文件一起使用的腳本語言來描述。在圖4(a)和4(b)所示的例子中，“生徒の追加”和“生徒の削除”被定義為命令，并分別涉及將節點“生徒”插入源樹中的操作以及將節點“生徒”從源樹中刪除的操作。模板描述了諸如“名前”和“國語”的標題顯示于表的第一行中，而節點“生徒”的內容顯示于第二行及其隨后的行中。在顯示節點“生徒”內容的模板中，包含“text-of”的項表示允許進行編輯，而包含“value-of”的項表示不允許進行編輯。在這些顯示了節點“生徒”內容的行中，在第六列中描述了運算表達式“(src國語+src數學+src理科+src社會)div 4”。這意味著顯示學生成績的平均值。
圖5示出了將圖2所示的由成績管理詞匯描述的XML文檔利用圖3所示的對應關系映射為HTML以使其顯示在顯示屏上時，顯示屏的一個例子。在表90各行中從左至右顯示的是各學生的姓名，以及日語成績、數學成績、自然科學成績、社會科學成績及其平均值。用戶能夠在該屏幕上對XML文檔進行編輯。例如，當第二行第三列中的值變為“70”時，源樹中與該節點相對應的元素值(亦即學生“B”的數學成績)變為“70”。此時，為了使目的樹與源樹一致，目的樹的相應部分因此而改變，從而使得HTML單元50能夠根據改變的目的樹來對顯示進行更新。因此，學生“B”的數學成績變為“70”，而平均值相應地變為“55”。
在圖5所示的屏幕上，例如“生徒の追加”和“生徒の削除”的命令被顯示為菜單，如圖4(a)、(b)所示的定義文件中所定義的那樣。當用戶從這些命令中選擇一個命令時，節點“生徒”增加至源樹中或從源樹中刪除。以這種方式，利用根據本前提技術的文檔處理裝置20，不僅能夠對分級結構下端中的組件的元素值進行編輯，而且能夠對該分級結構進行編輯。具有上述樹型結構的編輯功能能夠以命令的形式顯現給用戶。此外，增加或刪除表中的行的命令可例如與增加或刪除節點“生徒”的操作相關。嵌入其它詞匯中的命令可顯現給用戶。該表可用作輸入模板，以使得對于新學生的成績數據能夠以填空的方式來增加。如上所述，在使用HTML單元50的顯示/編輯功能的同時，以成績管理詞匯描述的文檔可通過VC功能來編輯。
圖6示出了由定義文件生成單元86顯現給用戶的圖形用戶界面的例子，以使用戶能夠生成定義文件。待映射的XML文檔在屏幕的左側區域91顯示為樹。被映射成的XML文檔的屏幕布局顯示在屏幕的右側區域92中。該屏幕布局可通過HTML單元50來編輯，用戶在屏幕的右側區域92中確定并創建用于對文檔進行顯示的屏幕布局。例如，使用諸如鼠標等的指示設備將屏幕的左側區域91中顯示的XML文檔的待映射的節點拖動并放置到屏幕的左側區域91中的HTML屏幕布局中，以指定映射源處的節點與映射目的處的節點之間的連接。例如，當作為元素“生徒”的子元素的“數學”被放置到HTML屏幕上的表90中第一行與第三列的交叉處時，第三列中的“數學”節點與“TD”節點之間建立連接。各節點均被如此被指定為可編輯或者不可編輯。此外，可在顯示屏中嵌入運算表達式。當完成屏幕編輯時，定義文件生成單元86生成定義文件，其描述屏幕布局與節點之間的連接。
已經開發出了能夠處理主要詞匯(例如XHTML(可擴展超文本標記語言)、MathML(數學標記語言)以及SVG(可縮放矢量圖形))的瀏覽器或編輯器。但是，不可能開發出適于以自創詞匯描述的所有文檔(例如圖2中所示的文檔)的瀏覽器或編輯器。然而，如果如上所述創建了用于映射為其它詞匯的定義文件，那么以自創詞匯描述的文檔就能夠使用VC功能來顯示和/或編輯，而不需不斷開發新的瀏覽器或編輯器。
圖7示出了由定義文件生成單元86生成的屏幕布局的另一例子。在圖7所示的例子中，在屏幕上產生表90和圓形圖92用于顯示以成績管理詞匯描述的XML文檔。圓形圖93以SVG描述。如以下將討論的那樣，根據本前提技術的文檔處理裝置20能夠對在單個XML文檔內以多個詞匯描述的復合文檔進行處理。這就是為什么以HTML描述的表90以及以SVG描述的圓形圖93能夠顯示在同一屏幕上的原因。
圖8示出了用于由文檔處理裝置20處理的XML文檔的編輯屏幕的一例。在圖8所示的例子中，單個屏幕被分割為多個區域，而待處理的XML文檔在各個區域以多種不同顯示格式顯示。該文檔的源在區域94中顯示，該文檔的樹結構在區域95中顯示，而圖5所示的、以HTML描述的表在區域96中顯示。該文檔在這些區域中的任意區域均可被編輯，當用戶對這些區域中的任意區域的內容進行編輯時，源樹將被相應修改，從而負責各屏幕顯示的插件更新應反映源樹變更的屏幕。具體而言，負責顯示對應編輯屏幕的插件的顯示單元被預先注冊為變化事件的監聽器，所述變化事件提供源樹中發生了改變的通知。當源樹被任意插件或VC單元80修改時，顯示編輯屏幕的所有顯示單元接收發出的一個或多個變化事件，并從而更新屏幕。此時，如果插件正在通過VC功能進行顯示，則VC單元80根據對源樹的修改來修改目的樹。之后，插件的顯示單元通過參考上述經過修改的目的樹而對屏幕進行更新。
例如，當通過專用插件來實現源顯示和樹型視圖顯示時，源顯示插件和樹顯示插件通過直接參考源樹而不是利用目的樹來實現它們的顯示。在這種情況下，當在屏幕的任何區域中完成編輯時，源顯示插件和樹顯示插件通過參考修改后的源樹來更新屏幕。同樣，負責顯示區域96的HTML單元50通過參考目的樹來更新屏幕，該目的樹已根據對源樹的修改而做了修改。
源顯示和樹型視圖顯示也可通過使用VC功能而實現。也就是說，例如，如果HTML被用于源和樹型結構的布局，則XML文檔可映射為HTML以通過HTML單元50來顯示。在這種情況下，將生成具有源格式、樹格式、表格式的三個目的樹。如果在屏幕上的三個區域的任意一個中進行編輯，則VC單元80對源樹進行修改，并在之后分別對具有源格式、樹格式、表格式的三個目的樹進行修改。然后，HTML單元50通過參考三個目的樹來更新三個屏幕顯示。
以這種方式，在單個屏幕上以多種顯示格式顯示文檔，從而提高了用戶的便利性。例如，用戶能夠利用表90或類似物來以視覺上易于理解的格式顯示和編輯文檔，同時通過源顯示或樹顯示來理解文檔的分級結構。在上述實施例中，單個屏幕被劃分為多個顯示格式，它們被同時顯示。但是，也可在單個屏幕上顯示單個顯示格式，從而可通過用戶指令來切換顯示格式。在這種情況下，主控單元22從用戶處接收用于切換顯示格式的請求，并隨后命令對應的插件進行顯示切換。
圖9示出了由文檔處理裝置20編輯的XML文檔的另一例。在圖9所示的XML文檔中，XHTML文檔被嵌入SVG文檔的“foreignObject”標簽中，而該XHTML文檔包含以MathML描述的公式。在這種情況下，編輯單元24通過參考命名空間而將描繪任務分配或指派給適當的顯示系統。在圖9所示的實施例中，編輯單元24首先使SVG單元60描繪矩形，然后使HTML單元50描繪XHTML文檔。此外，編輯單元24使MathML單元(未示出)描繪公式。以這種方式，包含多個詞匯的復合文檔被適當地顯示。圖10示出了顯示結果。
在對文檔進行編輯期間，可向用戶顯示編輯菜單。該菜單可對應于復合文檔的待編輯部分。因此，當用戶在顯示媒介上移動光標(キヤリツジ)時，待顯示的菜單可根據光標的位置被切換。也就是說，當光標位于顯示SVG文檔的區域中時，顯現給用戶的菜單響應于SVG單元60或響應于由用于映射SVG文檔的定義文件所定義的命令。當光標位于顯示XHTML文檔的區域中時，顯現給用戶的菜單響應于HTML單元50或響應于由用于映射XHTML文檔的定義文件所定義的命令。因此，可根據編輯位置提供適當的用戶界面。
如果在復合文檔中不存在與詞匯相符的適當插件或映射定義，則以該詞匯描述的部分可以源或樹格式顯示。在傳統實踐中，當要打開在某個文檔中嵌有其它文檔的復合文檔時，如果沒有安裝能夠顯示該嵌入文檔的應用程序，則它們的內容不能顯示。但是，根據本前提技術，由文本數據組成的XML文檔可顯示為源或樹格式，從而能夠確定其內容。這是基于文本的XML文檔或類似文檔的一個特征。
以基于文本的語言來描述的數據的另一個有益方面例如在于，在同一文檔中以其它詞匯描述的部分的數據可被該復合文檔中以某個詞匯描述的另一文檔所參考。此外，當在該文檔中進行搜索時，嵌入圖片(例如SVG)中的字符串也可作為被搜索的對象。
在以某個詞匯描述的文檔中，可使用屬于其它詞匯的標簽。雖然該XML文檔通常并不有效，但只要它結構良好(well-formed)，就可作為有效的XML文檔而被處理。在這種情況下，被插入的屬于其它詞匯的標簽可使用定義文件來進行映射。例如，在XML文檔中，可使用諸如“重要”和“最重要”的標簽以通過強調的方式來顯示這些標簽周圍的部分，或者可將這些標簽按重要性的順序來排序以進行相應顯示。
當用戶在圖10所示的編輯屏幕上對文檔進行編輯時，負責對被編輯的部分進行處理的插件或VC單元80對源樹進行修改。能夠為源樹中的各個節點注冊對于變化事件的監聽器。通常，與屬于各個節點的詞匯相符的插件的顯示單元或VC單元80被注冊為監聽器。當源樹被修改時，DOM提供單元32從被修改的節點向較高層次探索。如果存在注冊的監聽器，則DOM提供單元32向該監聽器發出變化事件。例如，參考如圖9中所示的文檔，如果位于<html>節點下方的節點被修改，那么該變化事件被通報給被注冊為<html>節點的監聽器的HTML單元50。在同一時刻，該變化事件被通報給被注冊為位于<html>節點上方的<svg>節點中的監聽器的SVG單元60。此時，HTML單元50通過參考被修改的源樹而更新顯示。由于屬于SVG單元60本身的詞匯的節點并未被修改，因此SVG單元60可忽視該變化事件。
根據編輯的內容，由HTML單元50對顯示進行的修改可改變總體布局。在這種情況下，對于各插件的各個顯示區域的布局將由管理屏幕布局的組件(例如，負責顯示最高節點的插件)來更新。例如，當由HTML單元50顯示的區域較之以前變大時，HTML單元50首先描繪HTML單元50本身所負責的區域，然后確定顯示區域的大小。然后，顯示區域的大小被通報給管理屏幕布局的組件，以請求對布局進行更新。負責屏幕布局的組件一收到該通知便為各個插件重新布置顯示區域。因此，被編輯的部分的顯示被適當更新，且總體屏幕布局被更新。
用以實現具有該先決條件技術的文檔處理裝置20的功能結構將在下面詳細描述。以下的說明中，在描述類名等的情況下，使用原來的英文字母。
A.概述互聯網的出現導致由用戶處理和管理的文檔的數目近乎成指數函數地增長。形成互聯網核心的萬維網聯合會(World Wide Web)包括由這些文檔數據構成的大規模數據中心庫。除了文檔，Web還提供用于這些文檔的信息檢索系統。這些文檔通常用標記語言描述，一種簡單且常用的標記語言是HTML(HypeText Markup Language超文本標記語言)。這種文檔還包括指向可能位于該Web其它部分中的其它文檔的鏈接。XML(eXtensible Markup Language可擴展標記語言)是另一種更高級、更常用的標記語言。用于訪問和查看該Web文檔的簡單瀏覽器使用面向對象的編程語言(例如Java(注冊商標))來開發。
以標記語言描述的文檔通常在瀏覽器和其它應用程序中表述為樹型數據結構的格式。這種結構與文檔的語法分析樹相對應。DOM(DocumentObject Model文檔對象模型)是一種眾所周知的用于表述和操作文檔的基于樹的數據結構模型。文檔對象模型提供了用于表述文檔的標準對象集合，包括HTML和XML文檔等。DOM包括兩個基本組件，即，如何將表述文檔中組件的對象進行組合的標準模型，以及用于訪問和操作這些對象的標準接口。
應用程序開發者能夠支持DOM作為其自身的特定數據結構的API(Application Program Interface接口和應用程序接口)。另一方面，創建文檔的應用程序開發者可使用標準DOM接口而不是使用其自身API的特定接口。因此，由于這種能夠提供標準的能力，DOM能有效地增加各種環境中、尤其是Web上的文檔的相互利用。已經定義了DOM的幾種變化，由不同的編程環境和應用程序來使用。
DOM樹是基于相應的DOM的內容對文檔的分級表述。DOM樹包括“根”以及從根產生的一個或多個“節點”。在某些情況下，根表述整個文檔。中間節點可表述元素，諸如表及表中的行和列。DOM樹的“葉子”通常表述數據，例如不可進一步分解的文本項目或圖像。DOM樹中的各個節點可與屬性相關聯，屬性描述了由節點表述的元素的參數，例如字體、大小、顏色、縮進等。
雖然HTML是一種創建文檔的常用語言，但它是格式和版式語言。HTML不是一種數據描述語言。表述HTML文檔的DOM樹的節點包括與HTML格式標簽相對應的預先定義的元素。由于HTML通常不提供任何數據描述，也不提供任何對數據的標簽/標注，因此，常常難以對HTML文檔中的數據進行查詢。
網絡設計者的目標是使得Web文檔能夠被軟件應用程序查詢或處理。獨立顯示的分級組織的語言能夠通過這種方式查詢和處理。諸如XML(可擴展標記語言)的標記語言能夠提供這些特征。
與HTML相反，眾所周知，XML的優點是使得文檔設計者能夠使用可自由定義的“標簽”來對數據元素進行標注。上述數據元素可進行分級組織。另外，XML文檔可包含文檔類型定義(DTD)，它是對文檔中所使用的“語法”(標簽及其相互關系)的描述。使用CSS(Cascading Style Sheet層疊樣式表)或XSL(XML Style LanguageXML樣式語言)，以定義結構化的XML文檔的顯示方法。與DOM、HTML、XML、CSS、XSL有關的其它信息以及相關語言特征也可從Web獲取(例如，http://www.w3.org/TR/)。
Xpath提供了用于對XML文檔的部分進行尋址的公共的語法和語義。Xpath的功能的一個示例是對與XML文檔相對應的DOM樹進行遍歷。它提供了用于操作與XML文檔的各種表述相關聯的字符串、數字和布爾字符的基本工具。Xpath對XML文檔的摘要、邏輯結構(例如，DOM樹)、而不是其表面語法(例如，描述哪個行或哪個字符位于序列中的語法)進行操作。使用Xpath，能夠在分級結構中(例如，在XML文檔的DOM樹中)進行定位。除了用于尋址的用途之外，Xpath還被設計用來測試DOM樹中的節點是否與某個模式相匹配。其它涉及Xpath的細節可在http://www.w3.org/TR/中找到。
利用XML公知的有益效果和特征，需要一種有效的文檔處理系統，其能夠對標記語言(例如，XML)描述的文檔進行處理，并能夠提供一種用于創建和修改這些文檔的友好的用戶界面。
此處說明的系統構成中的一些將使用MVC(Model-View-Controllers，模型-視圖-控制器)來說明，MVC是一種眾所周知的圖形用戶界面(GUI)范例。MVC范例提供了一種將應用程序(或甚至是一個應用程序的接口)分解為三部分(即，模型、視圖和控制器)的方法。最初開發MVC是為了將傳統的輸入、處理和輸出任務映射到GUI環境中。
輸入→處理→輸出控制器→模型→視圖根據所述MVC范例，用戶輸入、外界建模、以及對用戶的視覺反饋利用模型(M)、視窗(V)以及控制器(C)對象被分離和處理。控制器可操作以解釋輸入(例如用戶的鼠標和鍵盤輸入)，并將這些用戶動作映射為發送至模型和/或視窗的命令，以實現適當的改變。模型可操作以管理一個或多個數據元素、響應對其狀態的詢問、并響應改變狀態的指令。視窗可操作以管理顯示的矩形區域，并負責通過圖形和文本的組合將數據顯現給用戶。
B.文檔處理系統的總體構成文檔處理系統的一個實施例將在本文中參照圖11-29進行討論。
圖11(a)示出了能夠作為具有本文隨后描述的類型的文檔處理系統的基礎的要素的傳統裝置的例子。裝置10包括具有CPU形式或微處理器11等形式的處理器，處理器11通過通信路徑13耦合至存儲器12。存儲器12可為任何當前或將來能獲得的ROM和/或RAM存儲形式。通信路徑13通常實現為總線。用戶輸入裝置14(例如鼠標、鍵盤、語音識別系統或類似設備)的I/O接口16以及顯示設備15(或其它用戶接口)也耦合至總線用于與處理器11和存儲器12通信。如本領域所公知的那樣，諸如打印機、通信調制解調器等的其它設備可耦合至該裝置。該裝置可為獨立設備或者具有將多個終端以及一個或多個服務器耦合在一起的聯網形式，或者以本領域公知的多種設置方式的其中之一。本發明并不受這些組件的結構、它們的集中式或分布式體系結構或者多種組件的通信方式的限制。
另外，應該注意到，本系統和此處討論的實施例包括幾種具有多種功能的組件和子組件。應該注意到，這些組件和子組件可僅使用硬件、僅使用軟件以及使用硬件和軟件的組合來實現，以提供上述的多種功能。另外，硬件、軟件及其組合可使用通用計算裝置或使用專用硬件或使用通用計算裝置和專用硬件的組合來實現。因此，組件或子組件的結構包括運行特定軟件的通用/專用計算裝置，以提供該組件或子組件的功能。
圖11(b)示出了一種示例性文檔處理系統的總體方框圖。文檔在上述文檔處理系統中被創建和編輯。這些文檔能夠以具有標記語言的特征的任何語言來表述(例如XML)。同樣，為方便起見，已經創建了用于特定組件和子組件的術語和名稱。但是，這些不應被視作對本文公開的一般教導范圍造成了限制。
所述文檔處理系統可被視為具有兩個基本組件。第一個組件是“執行環境”101，它是文檔處理系統運行的環境。例如，執行環境提供了協助系統以及用戶對文檔進行處理和管理的基本效用和功能。第二個組件是“應用程序”102，它由在執行環境中運行的應用程序構成。這些應用程序包括文檔本身及其各種表述。
1.執行環境執行環境101的關鍵組件是程序調用器(ProgramInvoker程序啟動單元)103。程序調用器103是被訪問以啟動文檔處理系統的基本程序。例如，當用戶登錄并啟動文檔處理系統時，程序調用器103被執行。能夠例如讀取并處理作為插件增加至文檔處理系統的功能、啟動并運行應用程序、以及讀取與文檔相關的屬性。程序調用器103的功能并不限于此。當用戶希望發起計劃在執行環境中運行的應用程序時，程序調用器103找到、發起然后執行該應用程序。
程序調用器103聯接至幾個組件，例如插件子系統104、命令子系統105以及資源(Resource)模塊109。隨后將對這些組件進行更詳細描述。
a)插件子系統插件子系統104是向文檔處理系統增加功能的一種高度靈活和有效的設備。插件子系統104也能夠被用來修改和去除文檔處理系統中存在的功能。此外，可使用插件子系統增加或修改多種功能。例如，如之前所提以及隨后將詳細描述的那樣，插件子系統可用于增加功能“Editlet”，其可操作以有助于在屏幕上呈現文檔。插件Editlet也有助于對增加至系統的詞匯進行編輯。
插件子系統104包括服務代理(ServiceBroker服務中介單元)1041。服務代理1041管理增加至文檔處理系統的插件，從而代理已增加至文檔處理系統的服務。
代表期望功能的單個功能以“服務(Service)”1042的形式被增加至系統。服務1042的可用類型包括但不限于應用程序(Application)服務、區工廠(ZoneFactory區生成單元)服務、編輯器(Editlet編輯單元)服務、命令工廠(CommandFactory命令生成單元)服務、連接Xpath(ConnectionXPathXpath管理單元)服務、CSS計算(CSSComputationCSS計算單元)服務等。這些服務及其與系統其余部分的關系將隨后詳細描述，以更好地理解文檔處理系統。
插件和服務之間的關系是，插件是可包括一個或多個服務提供單元(ServiceProvider服務提供單元)的單元，各個服務提供單元具有與之相關的一個或多個類別的服務。例如，使用具有適當軟件應用程序的單個插件，能將一個或多個服務增加至系統，從而向系統增加相應的功能。
b)命令子系統命令子系統105被用來執行與文檔的處理相關的命令形式的指令。用戶可通過執行一系列指令而執行對文檔的操作。例如，通過發出命令形式的指令，用戶在文檔處理系統中處理XML文檔，并編輯與該XML文檔相對應的XML DOM樹。這些命令可利用鍵盤敲打、鼠標點擊或其它有效的用戶接口動作而輸入。有時，能夠通過命令來執行一個以上的指令。在這種情況下，這些指令被封裝成單個命令并連續執行。例如，用戶可能希望將錯誤詞語替換為正確詞語。在這種情況下，第一指令可用以在文檔中找尋錯誤詞語。第二指令可用以刪除該錯誤詞語。第三指令可用以輸入正確詞語。這三個指令可被封裝成單個命令。
命令可具有相關功能，例如具有下面將要詳細討論的“撤消”功能。這些功能可隨后分配給用來創建對象的基類。
命令子系統105的一個組件是命令調用器(CommandInvoker命令啟動單元)1051，命令調用器1051可操作為選擇性地提供并執行命令。雖然圖11(b)中僅示出了一個命令調用器，但也可使用一個以上的命令調用器并同時執行一個以上的命令。命令調用器1051維護執行命令所需的功能和類。在操作中，要執行的命令(Command)1052被置于隊列(Queue)1053中。命令調用器創建連續執行的命令線程。如果在命令調用器中沒有正在執行的命令，則由命令調用器1051執行待執行的命令1052。如果命令調用器正在執行命令，則新的命令被置于命令隊列1053的末尾。不過，對于各命令調用器1051而言，一次僅執行一個命令。如果指定的命令執行失敗，則命令調用器1051執行例外處理。
可由命令調用器1051執行的命令的類型包括但不限于可撤消命令(UndoableCommand)1054、異步命令(AsynchronousCommand)1055以及詞匯連接命令(VCCommand)1056。可撤消命令1054是那些如果用戶希望就能夠回退其效果的命令。可撤消命令的示例為剪切、復制、插入文本等。在操作中，當用戶突出文檔的一部分并向該部分應用剪切命令時，如果需要，通過使用可撤消命令，可使得被剪切的部分“恢復原樣(uncut)”。
詞匯連接命令1056被載入詞匯連接描述符(Vocabulary ConnectionDescriptorVCD)腳本文件中。詞匯連接命令1056是能夠由程序員定義的用戶指定命令。這些命令可以是更抽象命令的組合，例如，用于增加XML片段、刪除XML片段、設置屬性等。這些命令特別集中于對文檔進行編輯。
異步命令(AsynchronousCommand)1055是用于載入或保存由系統執行的文檔的命令，異步命令1055與可撤消命令(UndoableCommand)或VC命令(VCCommand)異步地執行。與可撤消命令不同，異步命令不能取消。
c)資源資源(Resource)109是向不同的類提供某些功能的對象。例如，串資源、圖標和設定鍵綁定是系統中使用的資源。
2.應用程序組件應用程序組件102，即文檔處理系統的第二個主要特征，在執行環境101中運行。概括而言，應用程序組件102包括實際文檔，實際文檔包括其在系統內的多個邏輯和物理表述。應用程序組件102還包括用來管理文檔系統組件。應用程序組件102進一步包括用戶應用程序(UserApplication)106、應用程序核心108、用戶界面107以及核心組件(CoreComponent)110。
a)用戶應用程序用戶應用程序106連同程序調用器103一起被載入到系統中。用戶應用程序106是將文檔、文檔的多種表述以及與文檔進行交互所需的用戶界面特征結合在一起的粘合劑(glue)。例如，用戶可能希望創建作為工程(project)一部分的一套文檔。載入這些文檔，創建用于文檔的適當表述，增加作為用戶應用程序106一部分的用戶界面功能。換言之，用戶應用程序106將文檔及其表述的各個方面結合在一起使得用戶能夠與形成工程一部分的文檔進行交互。一旦創建了用戶應用程序106，每當用戶希望與形成工程一部分的文檔進行交互時，用戶就能夠簡單地將用戶應用程序106載入到執行環境中。
b)核心組件核心組件(CoreComponent)110提供了在多個窗格(Pane)之間共享文檔的一種方法。如將在隨后詳細討論的那樣，窗格表述DOM樹，并處理屏幕的物理布局。例如，物理屏幕包括在屏幕內的多個窗格用于描述各條信息。實際上，由用戶在屏幕上查看的文檔可在一個或多個窗格中顯示。此外，兩個不同的文檔可以出現在屏幕上的兩個不同窗格中。
屏幕的物理布局還可以具有樹型形式，如圖11(c)所示。因此，如果組件1083要作為窗格顯示在屏幕上，則該窗格可被實現為根窗格(RootPane)1084。作為一種選擇，它也可以是子窗格(Subpane)1085。根窗格1084是窗格樹根部的窗格，而子窗格1085是除了根窗格1084之外的任何窗格。
核心組件110也提供字體，并充當用于文檔的多個功能性操作的源，例如，工具包(toolkit)。由核心組件110執行的任務的一個示例是在多個窗格之間移動鼠標光標。被執行的任務的另一個示例是標記一個窗格中的文檔的一部分，并將其復制到包含不同文檔的另一窗格上。
c)應用程序核心如上所述，應用程序組件102由被系統處理和管理的文檔組成。應用程序組件102包括對于系統內的文檔的多種邏輯和物理表述。應用程序核心108是應用程序組件102的組件。其功能是保持實際文檔及其內的所有數據。應用程序核心108包括文檔管理器(DocumentManager；文檔管理單元)1081和文檔1082本身。
文檔管理器1081的多個方面將在隨后更詳細描述。文檔管理器1081管理文檔1082。文檔管理器1081也連接至根窗格(RootPane)1084、子窗格(SubPane)1085、剪貼板(ClipBoard)實用程序1087以及快照(SnapShot)實用程序1088。剪貼板實用程序1087提供了保持用戶決定增加至剪貼板的部分文檔的一種方法。例如，用戶可能希望剪切文檔的一部分，并將其保存到新的文檔上，用于稍后查看。在這種情況下，剪切的部分被增加至剪貼板。
快照實用程序1088也將在稍后描述，從而當應用程序從一個狀態變為另一狀態時，能夠記住應用程序的當前狀態。
d)用戶界面應用程序102的另一組件是用戶界面107，其為用戶提供一種與系統進行物理交互的方式。例如，以物理接口1070來實現用戶界面時，用戶使用用戶界面上載、刪除、編輯和管理文檔。用戶界面107包括框架(Frame)1071、菜單欄(MenuBar)1072、狀態欄(StatusBar)1073以及URL(URLBar)欄1074。
如通常公知的那樣，框架1071可被視為顯示(例如物理屏幕)的活動區域。菜單欄1072是包括為用戶提供選項的菜單的屏幕區域。狀態欄1073是顯示應用程序的執行狀態的屏幕區域。URL欄1074提供了輸入用于在互聯網上定位的URL地址的區域。
C.文檔管理器和相關的數據結構圖12示出了文檔管理器1081的進一步細節。圖12包括被用來在文檔處理系統內表述文檔的數據結構和組件。為了更好的理解，在這部分描述的組件通過利用模型-視圖-控制器(MVC)表述范例來進行描述。
文檔管理器1081包括文檔容器(DocumentContainter)203，文檔容器203保持并容納文檔處理系統中的所有文檔。聯接至文檔管理器1081的工具包201為文檔管理器1081的使用提供了各種工具。例如，“DOM服務(DomService)”是由工具包201提供的能夠提供創建、維護和管理與文檔相對應的DOM所需的所有功能的工具。作為工具包201提供的另一工具的“IO管理器(IOManager)”分別管理向系統的輸入和來自系統的輸出。同樣地，“流處理器(StreamHandler)”是一種以比特流方式來處理文檔上載的工具。這些工具形成了工具包201的組件，不過并未在圖中明確示出或指定附圖標記。
根據MVC范例表述，模型(M)包括文檔的DOM樹模型202。如上所述，所有文檔均在文檔處理系統中被表述為DOM樹。文檔也形成文檔容器203的一部分。
1.DOM模型和區表述文檔的DOM樹是具有節點(Node)2021的樹。作為DOM樹的子集的區(Zone)209包括該DOM樹內部的一個或多個節點所關聯的區。例如，僅文檔的一部分可在屏幕上顯現。文檔可見的這一部分可使用“區”209來表述。利用被稱作“區工廠(ZoneFactory區生成單元)”205的插件來創建、操作和處理區。雖然區表述DOM的一部分，但它也可使用一個以上的“命名空間”。如本領域中公知的那樣，命名空間是名稱的匯集或集合，這些名稱在該命名空間中是唯一的。換言之，一個命名空間中不能夠出現兩個相同的名稱。
2.“方面”(Facet)及其與區的關系“方面”2022是MVC范例的模型(M)部分內的另一組件。它被用來編輯區中的節點。“方面”2022使用不會影響區本身的內容的執行過程來組織對于DOM的訪問。如以下將說明的那樣，這些過程執行與節點相關的有意義且有用的操作。
各個節點具有相應的“方面”。通過利用“方面”來執行操作而不是直接對DOM中的節點進行操作，DOM的完整性得以確保。否則，如果直接對節點執行操作，那么幾個插件可能同時對DOM進行改變，從而造成不一致性。
由W3C構建的DOM標準定義了用于對節點進行操作的標準接口。實際上，對每個詞匯或每個節點提供了特定操作，并且這些操作優選地提供為API。文檔處理系統提供了這種作為“方面”的節點特定API，并將“方面”聯接至各個節點。這符合DOM標準，同時增加了有用的API。通過在已應用的標準DOM之上增加特定的API而不是為每個詞匯實現特定的DOM，可集中處理多種詞匯，并正確地處理其中具有多個詞匯任意組合的混合的文檔。
“詞匯”是屬于命名空間的標簽(例如XML標簽)的集合。如上所述，命名空間具有唯一的名稱集(在該特定情況下為標簽集)。詞匯表現為表述XML文檔的DOM樹的子樹。這種子樹包括區。在特定實施例中，標簽集的邊界由區來限定。區209是利用被稱作“區工廠服務”205的服務而創建的。如上所述，區209是對表述文檔的DOM樹的僅僅一部分的內部表述。為了提供對該文檔的上述部分的訪問，需要邏輯表述。這種邏輯表述通知計算機關于文檔如何在屏幕上進行邏輯顯示。如上所述，“畫布(Canvas)”(例如畫布210)是一種可操作為提供與區相對應的邏輯布局的服務。
另一方面，窗格(例如窗格211)是與由畫布210提供的邏輯布局相對應的物理屏幕布局。實際上，用戶僅能看見以字符和圖片形式呈現在顯示屏上的文檔。因此，文檔必須通過用于在屏幕上描繪字符和圖片的處理來呈現在屏幕上。根據由窗格211提供的物理布局，文檔由畫布210呈現在屏幕上。
與區209相對應的畫布210是利用“Editlet服務”206來創建的。文檔的DOM是利用Editlet服務206和畫布210來編輯的。為了維護原始文檔的完整性，Editlet服務206和畫布服務210使用與區209中的一個或多個節點相對應的“方面”2022。這些服務并不直接操作區和DOM中的節點。“方面”是利用命令207來操作的。
用戶通常通過例如移動屏幕上的光標和/或鍵入命令而與屏幕進行交互。提供屏幕的邏輯布局的畫布2010接收這些光標操作。然后，畫布2010使得對“方面”采取相應的動作。給定這一關系，光標子系統204即作為用于文檔管理器1081的MVC范例的控制器(C)。畫布2010也具有處理事件的任務。例如，畫布2010處理諸如鼠標點擊、焦點移動和類似的用戶發起的動作等事件。
3.區、“方面”、畫布和窗格之間的關系概述文檔管理和處理系統內的文檔可從至少四個角度來觀察，即1)用來保持文檔管理系統中的文檔的內容和結構的數據結構；2)不會影響文檔完整性就能編輯文檔內容的手段；3)文檔在屏幕上的邏輯布局；以及4)文檔在屏幕上的物理布局。區、“方面”、畫布和窗格分別表述與上述四個方面相對應的文檔處理系統的組件。
4.撤消子系統如上所述，人們希望對文檔的任何改變(例如，編輯)應該是可撤消的。例如，用戶可執行編輯操作，然后決定撤消該改變。參照圖12，撤消子系統212是文檔管理器的可撤消組件。撤消管理器(UndoManager)2121保存可能被用戶撤消的、對文檔執行的所有操作。
例如，用戶可執行命令來將文檔中的詞語替換成另一個詞語。之后，該用戶可改變主意并決定保留原來的詞語。撤消子系統212利用可撤消編輯(UndoableEdit)2122來支持上述操作。撤消管理器2121保存上述可撤消編輯2122的操作。
5.光標子系統如上所述，MVC的控制器部分可包括光標子系統204。該光標子系統204接收用戶輸入。這些輸入通常具有命令和/或編輯操作的性質。因此，光標子系統204可被視作是與文檔管理器1081相關的MVC范例的控制器(C)部分。
6.視圖如上所述，畫布210表述要顯現在屏幕上的文檔的邏輯布局。對于XHTML文檔的特定實施例而言，畫布210可包括盒樹(box tree)208，盒樹208是文檔在屏幕上如何被查看的邏輯表述。上述盒樹208可包含在與文檔管理器1081有關的MVC范例的視圖(V)部分中。
D.詞匯連接文檔處理系統的一個重要特征是，提供這樣一種環境，能夠將XML文檔映射成另外的表述，并且在對映射后的表述進行編輯時，保持其與映射前XML文檔的一致性。
標記語言文檔(例如XML文檔)基于通過文檔類型定義限定的詞匯創建。詞匯則是一組標簽集，并可以任意定義，這就使得詞匯的數量可能是無限的。但是，為多個可能的詞匯中的每一個都提供專用的單獨處理和管理環境是不切實際的。詞匯連接是解決這種問題的一種方法。
例如，文檔可以利用兩種或更多標記語言來表述。這些文檔例如可以是XHTML(可擴展超文本標記語言)、SVG(可縮放矢量圖形)、MathML(數學標記語言)或其他的標記語言。換句話說，標記語言可以視為和XML中的詞匯和標簽集相同。
詞匯可以使用詞匯插件來處理。在文檔處理系統中，以插件不可用的詞匯所描述的文檔可以通過將該文檔映射為插件可用的另一詞匯來顯示。因此，以未準備有插件的詞匯描述的文檔仍然是可以正確顯示的。
詞匯連接包括獲取定義文件、在(所得到的定義文件的基礎上在兩個不同的詞匯之間進行映射的能力。用某種詞匯描述的文檔能夠映射為另外的詞匯。因此，詞匯連接能夠通過與文檔已被映射成的詞匯相對應的顯示和編輯插件來顯示或編輯文檔。
應該認識到，各個文檔在文檔處理系統中被描述為通常具有多個節點的DOM樹。“定義文件”為各個節點描述了該節點與其他節點之間的連接。規定了是否可以對各個節點的元素值和屬性值進行編輯。還描述了使用節點的元素值和屬性值的運算表達式。
利用映射特征，通過參考定義文件創建目的DOM樹。因此，源DOM樹和目的DOM樹之間的關系被建立并維護。詞匯連接監控源DOM樹和目的DOM樹之間的對應。在從用戶接收到編輯指令后，詞匯連接修改源DOM樹中的相關節點。如上所述，發出表示已經修改了源DOM樹的“變化事件”，并且相應地修改目的DOM樹。
通過使用詞匯連接，僅對于少量用戶所知的相對次要的詞匯可以被轉換為其他主要的詞匯。因此，即便是對于那些僅有少量用戶使用的次要詞匯，也可以準確地顯示文檔，并提供理想的編輯環境。
因此，作為文檔管理系統一部分的詞匯連接子系統提供了能夠對文檔進行多種表述的功能。
圖13顯示了詞匯連接(VCVocabulary Connection)子系統300。VC子系統300提供了一種維護同一文檔的兩種可替換表述之間的一致性的方法。例如，兩種表述可以是同一文檔以兩種不同詞匯實現的可替換表述。如上所述，其中一種可以是源DOM樹，而另一種是目的DOM樹。
1.詞匯連接子系統利用被稱為“詞匯連接(VocabularyConnection)”301的插件在文檔處理系統中實現詞匯連接子系統300的功能。將被表述的文檔的各詞匯305都需要相應的插件。例如，如果文檔的一部分以HTML表述，而其他部分以SVG表述，則需要相應的HTML詞匯插件和SVG詞匯插件。
詞匯連接插件301為區209或窗格211創建與適當詞匯305的文檔相對應的適當的詞匯連接畫布310。使用詞匯連接301，利用轉換規則，對源DOM樹的區209的改變被轉換到另一DOM樹306的相應區。轉換規則以詞匯連接描述符(Vocabulary Connection DescriptorVCD)的形式給出。對于與源和目的DOM之間的這種轉換相對應的各個VCD文件，創建相應的詞匯連接管理器(VocabularyConnectionManager)302。
2.連接器連接器(Connector)304連接源DOM樹中的源節點和目的DOM樹中的目的節點。連接器304可操作以觀察源DOM樹中的源節點，和與該源節點相對應的、對源文檔的修改(變化)。接著，連接器304修改相應的目的DOM樹中的節點。只有連接器304是能夠修改目的DOM樹的對象。例如，如果用戶僅能夠對源文檔和相應的源DOM樹進行修改，則連接器304對目的DOM樹進行相應的修改。
連接器304被邏輯地鏈接在一起以形成樹結構。連接器304形成的樹被稱為“連接器樹(ConnectorTree)”。連接器304通過一種服務而創建，該服務被稱為“連接器工廠(ConnectorFactory連接器生成單元)”303服務。連接器工廠303從源文檔創建連接器304，并將連接器304以連接器樹的形式鏈接起來。詞匯連接管理器302維護連接器工廠303。
如上所述，詞匯是命名空間中的標簽集。如圖所示，通過詞匯連接301為文檔創建詞匯305。這通過分析文檔文件以及為源DOM和目的DOM之間的轉換創建適當的詞匯連接管理器302來實現。此外，在創建連接器的連接器工廠303、創建區209的區工廠(ZoneFactory)205和創建與區中的節點相對應的畫布的Editlet服務206之間建立適當的關聯。當用戶從系統中除去或刪除文檔時，對應的詞匯連接管理器302被刪除。
詞匯305接著創建詞匯連接畫布310。此外，連接器304和目的DOM樹306被相應地創建。
應該理解，源DOM和畫布分別對應于模型(M)和視圖(V)。然而，僅當目標詞匯能夠在屏幕上呈現時，這種呈現才有意義。這種顯示通過詞匯插件來實現。詞匯插件提供用于主要的詞匯，例如XHTML、SVG和MathML。詞匯插件與目標詞匯關聯地使用。它們提供了一種使用詞匯連接描述符在詞匯之間進行映射的方式。
僅在目標詞匯可被映射并具有預定的屏幕呈現方式時，這種映射才有意義。這種呈現方法為例如XHTML等之類的由W3C組織定義的標準規格。
在需要詞匯連接時，使用詞匯連接畫布。在這種情況下，由于不能夠為源直接創建視圖，因此，不創建源畫布。在這種情況下，使用連接器樹來創建詞匯連接畫布。這種詞匯連接畫布僅僅處理事件轉換，而并不會有助于將文檔呈現在屏幕上。
3.目的區、窗格以及畫布如上所述，詞匯連接子系統的目的在于創建并同時維護對同一文檔的兩種表述。第二表述還可以是先前被引入作為目的DOM樹的DOM樹形式。為了瀏覽第二種表述的文檔，需要目的區(DestinationZone)、畫布和窗格。
在創建詞匯連接畫布后，創建相應的目的窗格(DestinationPane)307，如圖13所示。此外，相關的目的畫布(DestinationCanvas)308和相應的盒樹309被創建。同樣，詞匯連接畫布310還與源文檔的窗格211和區209關聯。
目的畫布308提供了文檔的第二種表述方式的邏輯布局。具體地，目的畫布308提供了用戶界面功能，例如光標和選擇，用于以目的表述的方式呈現文檔。在目的畫布308中發生的事件被提供到連接器。目的畫布308向連接器304通知鼠標事件、鍵盤事件、拖動和放置事件、以及通知文檔的目的(或第二種)表述的詞匯的特有事件。
4.詞匯連接命令子系統詞匯連接(VC)子系統300的一部分是詞匯連接(VC)命令子系統313。詞匯連接命令子系統313創建詞匯連接命令315，詞匯連接命令315用來執行與詞匯連接子系統300相關的指令。可通過內建的命令模板(CommandTemplate)318來創建詞匯連接命令，和/或可通過在腳本系統314中使用腳本語言從無到有地創建命令而創建詞匯連接命令。
命令模板的例子包括“If”命令模板、“When”命令模板、“插入(Insert)”命令模板等。這些模板被用來創建詞匯連接命令。
5.Xpath子系統Xpath子系統316是文檔處理系統的一個重要組件，因為它能夠有助于實現詞匯連接。連接器304通常包括xpath信息。如上所述，詞匯連接的任務是將源DOM樹中的變化反映到目的DOM樹中。xpath信息包括一個或多個用來確定源DOM樹中需要被觀察以確定改變/修改的子集的xpath表達式。
6.源DOM樹、目的DOM樹和連接器樹的概述源DOM樹是對轉換為另一種詞匯之前以一種詞匯表述的文檔進行表述的DOM樹或區。在源DOM樹中的節點被稱為源節點。
另一方面，目的DOM樹則表示用于在利用映射進行轉換之后以另一種詞匯表述的同一文檔的DOM樹或區，該映射已在前面結合詞匯連接描述。目的DOM樹中的節點被稱為目的節點。
連接器樹(ConnectorTree)是基于連接器的分級表述，用來表述源節點和目的節點之間的對應關系。連接器觀察源節點和對源文檔進行的修改。連接器隨后修改目的DOM樹。事實上，只有連接器是被允許修改目的DOM樹的唯一對象。
E.文檔處理系統中的事件流為了能夠使用，程序必須對來自用戶的命令進行響應。事件是一種描述和執行用戶對程序實施的動作的方法。許多高級語言例如JAVA(注冊商標)依靠描述用戶動作的事件。在現有技術中，程序不得不主動收集用于理解用戶動作和通過自身執行用戶動作的信息。這可能意味著，例如，在對程序初始化后，程序進入重復地查看用戶是否對屏幕、鍵盤和鼠標等執行了任何動作、并接著采取適當動作的循環。然而，這種處理可能難以操控。此外，這種處理在等候用戶做某些事情時，還需要執行循環的程序，從而消耗了CPU周期。
許多語言通過包含不同的范例來解決這些問題，其中的一個范例構成了所有現代的視窗系統的基礎事件驅動程序。在這種范例中，所有的用戶動作屬于被稱為“事件”的事務的抽象集合。事件足夠詳細地描述了特殊的用戶動作。在感興趣的事件發生時，這種系統通知程序，而不是程序主動地收集用戶生成的事件。以這種方式處理用戶交互的程序被稱為“事件驅動”。
這通常使用事件(Event)類來進行處理，其中事件類捕獲了所有用戶生成事件的基礎特性。
文檔處理系統定義和使用其自身的事件以及處理這些事件的方式。幾種類型的事件被使用。例如，鼠標事件是來自用戶的鼠標動作的事件。與鼠標有關的用戶動作由畫布210傳遞到鼠標事件。因此，畫布可以被認為是用戶與系統交互的最前沿。如果需要，最前沿的畫布將把其與事件有關的內容傳遞到其下級。
另一方面，按鍵事件從畫布210產生。按鍵事件具有瞬時的焦點，即，按鍵事件涉及任意瞬時的活動。進入到畫布210的按鍵事件接著被傳遞到其上級。鍵盤輸入通過能夠處理字符串插入的不同事件而被處理。在使用鍵盤插入字符時，將觸發處理字符串插入的事件。其他的“事件”包括例如拖動事件、放置事件和其他能夠以與鼠標事件相似的方式處理的事件。
1.在詞匯連接之外處理事件使用事件線程對事件進行傳遞。在接收到事件后，畫布210改變其狀態。如果需要，畫布210將命令1052記入到命令隊列(CommandQueue)1053。
2.在詞匯連接之內處理事件通過使用詞匯連接插件301，作為目的畫布(DestinationCanvas)一例的XHTMLCanvas 1106接收現有的事件，例如鼠標事件、鍵盤事件、拖動和放置事件、以及詞匯的特有事件。這些事件接著被通知到連接器304。更具體地說，詞匯連接插件301內的事件流經過源窗格1103、詞匯連接畫布VCCanvas1104、目的窗格(DestinationPane)1105、作為目的畫布一例的DestinationCanvas 1106、目的DOM樹和連接器樹，如圖21(b)所示。
F.程序調用器(ProgramInvoker)及其與其他組件之間的關系。
在圖14(a)中更加詳細地顯示了程序調用器103及其與其他組件之間的關系。程序調用器103是在執行環境中被執行以啟動文檔處理系統的基本程序。用戶應用程序(UserApplication)106、服務代理(ServiceBroker)1041、命令調用器(CommandInvoker)1051和資源(Resource)109都被聯接到程序調用器103，如圖11(b)所示。如前所述，應用程序102是在執行環境中運行的組件。同樣，服務代理1041管理向系統增加各種功能的插件。另一方面，命令調用器1051維護用來執行命令的類和函數，從而執行用戶提供的指令。
1.插件和服務下面將參照圖14(b)詳細描述服務代理1041。如上所述，服務代理1041管理向系統增加各種功能的插件(及相關服務)。服務(Service)1042在最底層，在該層中可以將特征增加到文檔處理系統，或改變該系統中的特征。“服務”由兩部分構成服務種類401和服務提供單元402(ServiceProvider)。如圖14(c)所示，單個的服務種類(ServiceCategory)401可具有多個相關的服務提供單元402，這些多個服務提供單元402中的每一個都可操作以執行所有或部分的特定服務種類。另一方面，服務種類401則定義了服務的類型。
服務可分為三種類型1)向系統提供特定特征的特征服務；2)應用程序服務，其是由文檔處理系統運行的應用程序；以及3)提供在整個文檔處理系統中需要的特征的環境服務。
圖14(d)中示出了服務的例子。根據應用程序服務的種類，系統實用程序是相應服務提供單元的示例。同樣，Editlet 206是一個種類，HTMLEditlet和SVGEditlet是相應的服務提供單元。區工廠205是服務的另一種，并具有相應的服務提供單元(未示出)。
之前描述的向文檔處理系統增加功能的插件可以看作是由幾個服務提供單元402和與其相關的類構成的單元，如圖14(c)和14(d)所示。各個插件都應該具有在聲明文件中寫入的從屬性和服務種類401。
2.程序調用器和應用程序之間的關系圖14(e)詳細顯示了程序調用器103和用戶應用程序106之間的關系。所需的文檔、數據等從存儲器中載入。所有需要的插件載入到服務代理1041。服務代理1041管理并維護所有的插件。可物理地將插件增加到系統，或者可從存儲器中載入其功能。在載入插件的內容后，服務代理1041定義相應的插件。相應的用戶應用程序106被創建，接著被載入到執行環境101并聯接到程序調用器103。
G.應用程序服務和環境之間的關系圖15(a)進一步示出了載入程序調用器103中的應用程序服務的結構。作為命令子系統105組件的命令調用器1051調用或執行程序調用器103內的命令1052。命令1052則是用來在文檔處理系統中處理文檔(例如，XML文檔)和編輯相應的XMLDOM樹的指令。命令調用器1051維護執行命令1052所需的功能和類。
服務調用器1041也在程序調用器103中執行。用戶應用程序106連接到用戶界面107和核心組件(CoreComponent)110。核心組件110提供了一種在所有的窗格之間共享文檔的方式。核心組件110還提供字體并作為用于窗格的工具包。
圖15(b)顯示了框架(Frame)1071、菜單欄(MenuBar)1072和狀態欄(StatusBar)1073之間的關系。
H.應用程序核心圖16(a)進一步解釋了應用程序核心110，其保持所有文檔以及作為文檔一部分并屬于文檔的數據。核心組件(CoreComponent)110聯接到管理文檔1082的文檔管理器(DocumentManager)1081。文檔管理器1081是存儲到與文檔處理系統關聯的存儲器中的所有文檔1082的所有者。
為了便于在屏幕上容易地顯示文檔，文檔管理器1081還連接到根窗格1084。剪貼板(ClipBoard)1087、快照(SnapShot)1088、拖放工具(Drag & Drop)601，以及覆蓋(Overlay)602的功能也被聯接到核心組件110。
快照1088用來將應用程序狀態復原。在用戶調用快照功能1088時，應用程序的當前狀態被檢測并存儲。其后，在應用程序改變為另一狀態時，所存儲的狀態的內容被保存下來。在圖16(b)中示出了快照1088。在操作中，當應用程序從一個URL移動到另一個時，快照1088會記住先前的狀態，從而能夠無縫地執行回退和前進操作。
I.在文檔管理器中文檔的構成圖17(a)更加詳細地描述了文檔管理器1081以及如何在文檔管理器中構成并保存文檔。如圖11(b)所示，文檔管理器1081管理文檔1082。在圖17(a)顯示的實施例中，多個文檔中的一個為根文檔(RootDocument)701，其他的文檔為子文檔(SubDocument)702。文檔管理器1081連接到根文檔701，根文檔701則連接到所有的子文檔702。
如圖12和17(a)所示，文檔管理器1081耦合到文檔容器(DocumentContainer)203，文檔容器203是管理所有文檔1082的對象。形成工具包(例如，XML工具包)201的一部分的工具(包括DOM服務703和IO管理器(IOManager)704)也提供給文檔管理器1081。再參照圖17(a)，DOM服務703基于由文檔管理器1081管理的文檔來創建DOM樹。各個文檔705，不管是根文檔701還是子文檔702都容納在相應的文檔容器203中。
圖17(b)顯示了一組文檔A-E是如何以分級結構排列的實施例。文檔A為根文檔。文檔B-D是文檔A的子文檔。文檔E則是文檔D的子文檔。圖17(b)的左側還顯示了如何將文檔的同一分級結構顯示在屏幕上的實施例。作為根文檔的文檔A顯示為基礎框架。文檔A的子文檔B-D顯示為在基礎框架A內的子框架。文檔D的子文檔E在屏幕上顯示為子框架D的子框架。
再參照圖17(a)，為各個文檔容器203創建撤消管理器(UndoManager)706和撤消封裝器(UndoWrapper)707。撤消管理器706和撤消封裝器707用來執行可撤消的命令。使用該特征，可以撤消使用編輯操作對文檔所作的改變。子文檔中的改變也會涉及到根文檔。撤消操作考慮到了影響分級結構內其他文檔的改變，并確保了在分級結構鏈中的所有文檔之間所維護的一致性，例如，如圖17(b)所示。
撤消封裝器707將與容器203中的子文檔相關的撤消對象進行封裝，并將它們和與根文檔相關的撤消對象耦合。撤消封裝器707使得可撤消編輯接收器(UndoableEditAcceptor可撤消編輯接受單元)709能夠收集撤消對象。
撤消管理器706和撤消封裝器707連接到可撤消編輯接收器709和可撤消編輯源(UndoableEditSource)708。本領域技術人員應該理解，文檔705可以是可撤消編輯源708，并因此可以是可撤消編輯對象的源。
J.撤消命令和撤消框架圖18(a)和(b)進一步詳細地顯示了撤消框架和撤消命令。如圖18(a)所示，撤消命令(UndoCommand)801、重做命令(RedoCommand)802和可撤消編輯命令(UndoableEditCommand)803是能夠排列在命令調用器1051中的命令(如圖11(b)所示)并且被相應地執行。可撤消編輯命令803還進一步聯接到可撤消編輯源708和可撤消編輯接收器709。例如，可撤消編輯命令是“foo”編輯命令804和“bar”編輯命令805。
1.可撤消編輯命令的執行圖18(b)顯示了可撤消編輯命令的執行。首先，假設用戶使用編輯命令來編輯文檔705。在第一步驟S1，可撤消編輯接收器709被聯接到可撤消編輯源708，可撤消編輯源708為文檔705的DOM樹。在第二步驟S2，基于由用戶發出的命令，使用DOM的API對文檔705進行編輯。在第三步驟S3，向變化事件監聽器通知已經發生了改變。即，在該步驟，監控DOM樹中所有改變的監聽器檢測編輯操作。在第四步驟S4，將可撤消的編輯存儲為撤消管理器706的對象。在第五步驟S5，可撤消編輯接收器709與可撤消編輯源708分開，可撤消編輯源708可以是文檔705本身。
K.向系統載入文檔時需要的步驟上述幾個子部分描述了系統的各個組件和子組件。下面將描述在使用這些組件時用到的方法。圖19(a)顯示了如何將文檔載入到文檔處理系統中的總體圖。參照圖24-28詳細地描述各個步驟的特定的例子。
簡言之，文檔處理系統從由在文檔中包含的數據構成的二進制數據流創建DOM樹。為文檔中的感興趣的并位于“區”中的一部分創建頂節點(ApexNode)，接著確定相應的“窗格”。所確定的窗格從頂節點和物理屏幕表面創建“區”和“畫布”。“區”接著為各個節點創建“方面”，并為它們提供所需信息。畫布創建用于呈現DOM樹的節點的數據結構。
具體地，文檔從存儲器901載入。接著，創建文檔的DOM樹902。創建保持文檔的相應文檔容器903。接著將文檔容器903聯接到文檔管理器904。DOM樹包括根節點，并且可選地包括多個次級節點。
典型地，這種文檔包括文本和圖形。因此，DOM樹例如能夠具有XHTML子樹以及SVG子樹。XHTML子樹具有XHTML頂節點905。同樣，SVG子樹具有SVG頂節點906。
在步驟1，將頂節點906聯接到窗格907(窗格907是屏幕的邏輯布局)。在步驟2，窗格907向應用程序核心(即窗格所有者(PaneOwner)908)請求用于頂節點906的區工廠。在步驟3，窗格所有者908返回區工廠以及作為用于頂節點906的畫布工廠的Editlet。
在步驟4，窗格907創建區909，區909聯接至窗格。在步驟5，區909為各個節點創建“方面”，并聯接到相應的節點。在步驟6，窗格907創建畫布910。畫布910與窗格907聯接。在畫布910中包括各種命令。在步驟7中，畫布910則構建用于將文檔呈現在屏幕上的數據結構。在XHTML的情況下，這包括盒樹結構。
1.區的MVC圖19(b)使用MVC范例顯示了區的結構概要。在這種情況下，模型(M)包括區工廠創建的區和“方面”，這是因為它們是與文檔相關的輸入。用于將文檔呈現在屏幕上的畫布和數據結構是為用戶顯示在屏幕上的輸出，因此，視圖(V)對應于畫布和數據結構。控制(C)包括畫布中所包含的命令，這是由于這些命令對文檔及其關系執行控制操作。
L.文檔的表述下面將使用圖20來描述復合文檔及其各種表述的實施例。在該實施例中使用的文檔包括文本和圖片。文本使用XHTML表述，而圖片用SVG表述。圖20詳細顯示了用于文檔組件的MVC表述以及相應對象的關系。對于該示例性的表述，文檔1001聯接到保持文檔1001的文檔容器1002。文檔用DOM樹1003表述。DOM樹1003包括頂節點1004。
頂節點用陰影圓圈表示。非頂節點用非陰影圓圈表示。用來編輯節點的“方面”用三角形表示，并被聯接到相應的節點。由于文檔具有文本和圖片，所以用于該文檔的DOM樹包括XHTML部分和SVG部分。頂節點1004是XHTML子樹的最頂部的節點。該頂節點被聯接到XHTML窗格1005，XHTML窗格1005是文檔XHTML部分的物理表述的最頂部窗格。該頂節點1004還聯接到XHTML區1006，其中XHTML區1006是文檔DOM樹的一部分。
與節點1004相對應的“方面”1041還聯接到XHTML區1006。XHTML區1006則聯接到XHTML窗格1005。XHTML的Editlet創建XHTML畫布1007，XHTML畫布1007是文檔的邏輯表述。XHTML畫布1007聯接到XHTML窗格1005。XHTML畫布1007為文檔1001的XHTML組件創建盒樹1009。維護和呈現文檔的XHTML部分所需的各種命令1008也被增加到XHTML畫布1007。
同樣，該文檔的SVG子樹的頂節點1010被聯接到SVG區1011，SVG區1011是文檔1001的DOM樹的、用于表述文檔的SVG組件的部分。頂節點1010被聯接到SVG窗格1013，SVG窗格1013是文檔的SVG部分的物理表述的最頂部窗格。表述文檔的SVG部分的邏輯表述的SVG畫布1012通過SVGEditlet創建，并被聯接到SVG窗格(SVGPane)1013。用于將文檔的SVG部分呈現在屏幕上的數據結構和命令1014被聯接到SVG畫布(SVGCanvas)1012。例如，這種數據結構可包括圓圈、線、矩形等，如圖所示。
下面將使用先前描述的MVC范例，參照圖21(a)進一步討論參照圖20描述的、用于對該示例性文檔進行表述的部件。圖21(a)提供了文檔1001的XHTM組件的MV關系的簡化圖。圖中的模型是用于文檔1001的XHTML組件的XHTML(XHTMLZone)區1101。包括在XHTML區樹中的是幾個節點及其相應的“方面”。相應的XHTML區和窗格是MVC范例的模型(M)部分的一部分。MVC范例的視圖(V)部分是用于文檔1001的HTML組件的相應的XHTML畫布1102和盒樹。通過畫布以及其中所包含的命令，文檔的XHTML部分被呈現在屏幕上。例如鍵盤和鼠標輸入的事件以如圖所示的相反方向進行處理。
也就是說，源窗格(SourcePane)具有附加功能，以起到DOM保持器的作用。圖21(b)提供了在圖21(a)中示出的用于文檔1001的組件的詞匯連接。作為源DOM保持器的源窗格1103包含了用于文檔的源DOM樹。連接器樹(ConnectorTree)1004通過連接器工廠(ConnectorFactory)創建，連接器樹1004又創建作為目的DOM樹保持器的目的窗格(DestinationPane)1105。目的窗格1105接著以盒樹的形式被布置為XHTML目的畫布(XHTMLDestinationCanvas)1106。
M.插件子系統、詞匯連接和連接器之間的關系圖22(a)-(c)分別顯示了與插件子系統、詞匯連接和連接器相關的附加細節。插件子系統被用來向文檔處理系統增加功能，或與之交換功能。插件子系統包括服務代理(ServiceBroker)1041。聯接到服務代理1041的區工廠服務(ZoneFactoryService)1201負責創建用于文檔的部分的區。Editlet服務(EditletService)1202還被聯接到服務代理1041。Editlet服務(EditletService)1202創建與區中的節點相對應的畫布。
區工廠的例子是分別創建XHTML區和SVG區的XHTML區工廠1211和SVG區工廠(SVGZoneFactory)1212。如上參照示例性文檔所述，文檔的文本組件可通過創建XHTML區來表述，而圖片則可使用SVG區來表述。Editlet服務(EditletService)的示例包括XHTMLEditlet 1221和SVGEditlet 1222。
圖22(b)進一步詳細顯示了詞匯連接，如上所述，詞匯連接是文檔處理系統的重要特征，其能夠使兩種不同方式的文檔的表述和顯示保持一致。能夠維護連接器工廠303的詞匯連接管理器(VCManager)302是詞匯連接子系統的一部分。連接器工廠303為文檔創建連接器304。如上所述，連接器觀察源DOM中的節點，并修改目的DOM中的節點，以維護兩種表述之間的一致性。
模板(Template)317表述用于一些節點的轉換規則。事實上，詞匯連接描述符(VCD)文件是表示一些規則的一系列模板，這些規則用于將滿足某種路徑或規則的元素或元素集合轉換為其他的元素。模板317和命令模板(CommandTemplate)318都聯接到詞匯連接管理器302。詞匯連接管理器302是管理VCD文件中的所有部分的對象。為一個VCD文件創建一個詞匯連接管理器對象。
圖22(c)表示了連接器的附加細節。連接器工廠303從源文檔中創建連接器。連接器工廠303聯接于詞匯、模板和元素模板，并分別創建詞匯連接器(VocabularyConnector)、模板連接器(TemplateConnector)和元素連接器(ElementConnector)。
詞匯連接管理器302維護連接器工廠303。為了創建詞匯，讀取相應的VCD文件。接著創建連接器工廠303。該連接器工廠303與負責創建區的區工廠205和負責創建畫布的Editlet服務206相關聯。
接著，用于目標詞匯的Editlet服務創建詞匯連接畫布。詞匯連接畫布為源DOM樹或區中的頂節點創建連接器。接著，根據需要遞歸地創建子連接器。通過VCD文件中的一組模板創建連接器樹。
模板是用于將標記語言的元素轉換為其他元素的規則集合。例如，各個模板與源DOM樹或區相匹配。在正確匹配時，創建頂點連接器。例如，模板“A/*/D”監測所有從節點A開始、在節點D結束的樹分支，而不考慮節點A和節點D之間的節點。同樣，“//B”對應于所有來自根節點的“B”節點。
N.與連接器樹相關的VCD文件的示例下面將解釋與特定文檔相關的處理。名為MySampleXML的文檔被載入文檔處理系統。圖23顯示了使用詞匯連接管理器的VCD腳本和用于MySampleXML的連接器工廠樹的實施例。在圖中顯示了腳本文件內的詞匯部分、模板部分以及它們在詞匯連接管理器中的相應組件。在標簽“vcdvocabulary”下提供了屬性match＝″sampleroot″、label＝″MySampleXML″以及call-template＝″sample template″。
與該實施例相對應，在MySampleXML的詞匯連接管理器中，詞匯包括頂點元素“sampleroot”。相應的UI標簽為“MySampleXML”。在模板部分，標簽為vcdtemplate，名稱為“sample template”。
O.將文件載入系統的詳細例子圖24-28顯示了載入文檔MySampleXML的詳細描述。在步驟1，如圖24(a)所示，文檔從存儲器1405中載入。DOM服務創建DOM樹和文檔管理器1406以及對應的文檔容器1401。文檔容器1401聯接到文檔管理器1406。文檔包括用于XHTML和MySampleXML的子樹。XHTML頂節點1403是用于XHTML的最頂部的節點，并具有標簽xhtmlhtml。另一方面，頂節點1404對應于MySampleXML的最頂部的節點，并具有標簽sampleroot。
在步驟2，如圖24(b)所示，根窗格(RootPane)為文檔創建XTML區、“方面”和畫布。創建與頂節點1403相應的窗格(Pane)1407、XHTML區(XHTMLZone)1408、XHTML畫布(XHTMLCanvas)1409和盒樹(BoxTree)1410。
在步驟3，如圖24(c)所示，XHTML區找到外來的標簽“sampleroot”，并從XHTML畫布的區創建子窗格。
圖25顯示了步驟4，在步驟4中，子窗格1501獲取能夠處理“sampleroot”標簽并創建適當的區的相應的區工廠。這種區工廠將在能夠實現區工廠的詞匯中。區工廠包括MySampleXML中的詞匯部分(VocabularySection)的內容。
圖26顯示了步驟5，在步驟5中，與MySampleXML對應的詞匯創建缺省的區(DefaultZone)1601。相應的Editlet被創建并被提供給子窗格1501，以創建相應的畫布。Editlet創建詞匯連接畫布，稱為模板部分(TemplateSection)還包括連接器工廠樹(ConnectorFactoryTree)。連接器工廠樹創建所有的連接器，創建的連接器形成連接器樹。
圖27顯示了步驟6，各個連接器創建目的DOM對象。一些連接器包括xpath信息。xpath信息包括一個或多個xpath表達式，xpath表達式用來確定需要被監測是否發生了改變/修改的源DOM樹的子集。
在圖28所示步驟7中，詞匯從源DOM的窗格形成目的DOM樹的目的窗格(DestinationPane)。這基于源窗格(SourcePane)來完成。接著，將目的樹的頂節點(ApexNode)聯接到目的窗格以及相應的區。接著為目的窗格設置其自身的Editlet，Editlet則創建目的畫布(DestinationCanvas)，并構建數據結構和命令，從而以目的格式呈現文檔。
圖29(a)顯示了發生于某節點的事件流，該節點不具有相應的源節點并僅依賴于目的樹。在第一步驟，畫布所獲取的事件(例如鼠標事件和鍵盤事件)通過目的樹，并被傳輸到元素模板連接器(ElementTemplateConnector)。元素模板連接器不具有相應的源節點，因此被傳送的事件并不是對源節點的編輯操作。如果所傳送的事件與命令模板(CommandTemplate)中描述的命令相匹配，則執行相應的動作。否則，元素模板連接器忽略所傳送的事件。
圖29(b)顯示了發生于某目的樹的節點的事件流，該目的樹的節點通過文本連接器(TextOfConnector)與源節點相關聯。文本連接器從由源DOM樹的XPath規定的節點獲取文本節點，并將該文本節點映射為目的DOM樹的節點。畫布所獲取的事件(例如鼠標事件和鍵盤事件)通過目的樹，并被傳送到文本連接器。文本連接器將所傳送的事件映射為相應源節點的編輯命令，并將這些命令設置在隊列(Queue)1053中。編輯命令是通過“方面”執行的DOM的一組API調用。當執行設置在隊列中的命令時，編輯源節點。在編輯源節點時，發出變化事件，并且將對源節點的修改通知到注冊為監聽器的文本連接器。文本連接器重新建立目的樹，從而在相應的目的節點中反映出對源節點的修改。如果包含文本連接器的模板包括控制聲明，例如“for each”和“for loop”，則連接器工廠重新評估控制聲明。在重建文本連接器后，重建目的樹。
(實施方式)在實施方式中，提出了在利用VC功能處理文檔時，即使定義文件中未描述的元素存在于文檔中，也能夠適當處理該元素的技術。
根據本實施方式的文檔處理裝置20能夠如前提技術所說明的那樣，適當處理包含多個詞匯的復合文檔文件。本申請人認為，復合文檔文件中的詞匯的關系有以下種類，其中，將對屬于情況(2)和(3)的復合文檔文件進行適當處理的方法論作為課題。
(1)在第一詞匯的元素的下級存在第二詞匯的元素。
(2)在第一詞匯的元素的下級存在第二詞匯的元素，而且，在第二詞匯的元素的下級又存在第一詞匯的元素。
(3)在第一詞匯的元素中，指定第二詞匯的屬性作為全局屬性。
在本實施方式中，特別提出了處理情況(2)中的復合文檔文件的技術。
圖30是用于說明文檔處理裝置20處理復合文檔文件的示意圖。文檔處理裝置20在讀入文檔文件生成源樹時，首先，由主控單元22根據根元素的命名空間或元素名，選擇能夠處理該元素所屬的詞匯或是標簽集的處理系統。處理系統可以是作為特定詞匯的處理系統而準備的插件，也可以是與使用定義文件的VC功能相應的處理系統。當選擇的處理系統是HTML單元50等插件時，插件進行以下處理，即，從根節點依次朝向下位的節點，對各節點增加與元素匹配而準備的擴展接口等。插件自身不對應，即，沒有準備擴展接口，當碰到不能處理的節點時，依靠主控單元22，插件把比該節點更下位的節點的處理移交給其他的處理系統。主控單元22選擇能夠處理那個節點的元素的處理系統，將比該節點更下位的節點的處理移交給該處理系統。這樣，能夠適當處理情況(1)的復合文檔文件。在找不到能夠處理的插件等的情況下，進行圖標顯示或源(source)顯示等通用的處理系統能夠進行處理。
圖31是用于說明文檔處理裝置20處理復合文檔文件的示意圖。圖32示出了圖31所示的處理所用的定義文件的例子。在由主控單元22所選擇的處理系統是VC單元80的情況下，VC單元80參考定義文件，從根元素開始順序進行與元素名匹配的模板中所描述的處理。模板未準備、或者模板中未描述的元素被忽略。在圖31和圖32的例子中，屬于由命名空間前綴“p2”規定的命名空間的元素由于在定義文件中沒有描述，所以被忽略，不能創建目的樹。因此，雖然在文檔文件中存在，但是不能顯示在屏幕上，更不能編輯。
圖33是用于說明文檔處理裝置20處理復合文檔文件的示意圖。圖34示出了圖33所示的處理所用的定義文件的例子。在圖33和圖34所示的例子中，作為用于對圖31和圖32所示的例子中被忽略且未被處理的元素進行適當處理的技術的例子，準備了能夠對復合文檔文件所用的全部元素進行處理的定義文件。也就是說，除了由命名空間前綴“p1”所規定的屬于命名空間的元素的模板之外，在定義文件中準備有“p2”的元素的模板。據此，復合文檔文件中存在的所有元素都與目的樹相對應，能夠適當地處理。
圖35是用于說明文檔處理裝置20處理復合文檔文件的示意圖。圖36示出了圖35所示的處理所用的定義文件的例子。在該例子中，將某文檔文件的源樹映射到包含多個詞匯的復合文檔的目的樹。因此，目的樹由負責各詞匯的處理系統進行顯示。
如圖31和圖32所說明的那樣，在定義文件的模板中描述文檔文件中包含的元素的處理方法，當通過VC功能處理文檔時，模板中未描述的元素被忽略，不作為處理的對象。為了解決這一問題，在本實施方式的第一例中，提出了將雖然在文檔中存在但是與定義文件中所描述模板的任一模板不匹配的元素移交給其他處理系統的方法。
圖37是用于說明第一例的結構的圖。圖38和圖39分別示出了圖37所示的處理所用的第一定義文件的例子和第二定義文件的例子。在與文檔對應的第一定義文件的模板的最后描述了與其他模板不匹配的所有元素所匹配的模板，即，“*”被指定為屬性“match”的模板，其中，描述了表示將該元素的處理移交給其他的處理系統的命令，即，<vcdapply-vocabularies select＝”.”/>。VC單元80在使用第一定義文件進行文檔文件的處理時，在與該模板匹配的元素存在的情況下，將移交該元素的處理的法則通知給主控單元22。主控單元22選擇能夠處理該元素的處理系統，并將處理移交給該處理系統。
在圖37的情況下，如果文檔中存在屬于命名空間“p2”的元素，則讀入與該詞匯對應的第二定義文件，將處理移交給VC單元80。VC單元80使用第二定義文件的模板，將文檔文件中包含的屬于命名空間“p2”的元素對應到目的樹進行處理。當能夠處理命名空間“p2”的插件存在時，也可以將處理移交給該插件。根據該技術，在通過VC功能處理包含多個標簽集元素的復合文檔文件時，即使存在第一定義文件不能處理的元素，也能適當分配給其他處理系統進行處理。
圖40是用于說明第二實施例的結構的圖。圖41和圖42分別示出了圖40所示的處理所用的第一定義文件的例子和第二定義文件的例子。與文檔對應的第一定義文件的開頭描述了并入其他定義文件的命令，即，<vcdimport href＝”private2.Vcd”/>。VC單元80讀入第一定義文件，如果檢測出該命令，則讀入由屬性“href”指定的定義文件，合并到第一定義文件。據此，生成了能夠同時處理第一定義文件支持的元素和第二定義文件支持的元素的一個虛擬定義文件。
在該例子中，由于生成了虛擬的一個詞匯，文檔整體由虛擬的一個處理系統進行處理，因此如情況(2)那樣，即使是詞匯為嵌套型的復合文檔，也能適當進行處理。被合并的定義文件例如可以是支持較小(minor)的標簽集的定義文件，也可以假定預先并入其他定義文件中，描述命令或模板。此時，優選地，例如，能夠考慮被采用的模板的優先順序、或命令的優先順序等來創建定義文件。另外，優選地，第一定義文件和并入其中的其他定義文件按照創建相同詞匯的目的樹的方式描述。
作為多個定義文件被合并的結果，存在命令名重復的可能性。在這種情況下，VC單元80可將重復的命令名變換成其他的名稱再進行合并。此外，在用同樣的命令名進行合并的情況下，當發送該命令時，可根據光標的位置判斷執行哪個命令。也就是說，可以執行在負責光標位置元素的定義文件中所描述的命令。
在上述說明中，盡管關于指定預先合并的定義文件的例子進行了說明，但是，VC單元80可以在檢測到第一定義文件不能處理的元素存在于文檔中時，檢索支持該元素的其他定義文件，將定義文件進行動態合并。此外，也可以在第一定義文件中描述合并所有的定義文件的命令，預先合并文檔處理裝置20能獲取的所有的定義文件。
當描述了全局屬性在目的樹中具有的任何區域的模板時，情況(3)的復合文檔文件也能通過第二例進行適當處理。
以上根據實施方式對本發明進行了說明。本領域技術人員可以理解，這些實施方式只是示例，這些構成要素、各個處理過程的組合可以形成各種各樣的變化例子，這些變化的例子也屬于本發明的范圍內。
另外，權利要求書中記載的源文件獲取單元的功能在本實施方式中由主控單元22實現。權利要求書中記載的定義文件保存單元的功能在本實施方式中主要由定義文件獲取單元84或定義文件生成單元86實現。權利要求書中記載的標簽選擇單元的功能在本實施方式中主要由主控單元22實現。權利要求書中記載的數據變換單元的功能在本實施方式中由主控單元22和HTML單元50或SVG單元60等的聯系來實現。權利要求書中記載的定義文件合成單元的功能在本實施方式中主要由定義文件生成單元86實現。
本領域技術人員應當理解，這些權利要求中記載的各構成部分實現的功能可以由本實施方式中所示的各功能塊的單個個體或這些個體的聯系來實現。
雖然在實施方式中對處理XML文檔的例子進行了說明，本實施方式的文檔處理裝置20對以其他的標記語言(例如，SGML、HTML等)描述的文檔也可以進行同樣的處理。
產業上利用的可能性利用本發明對以標記語言描述的結構化數據進行處理，可以提高用戶的便利性。
權利要求
1.數據處理裝置，其特征在于，包括數據獲取裝置；定義文件獲取裝置，獲取描述所述數據的處理方法的定義文件；和移交裝置，對于所述定義文件中未描述其處理方法的數據，將所述數據的處理移交給其他處理系統。
2.數據處理裝置，其特征在于，包括數據獲取裝置；定義文件獲取裝置，獲取描述所述數據的處理方法的定義文件；和合并裝置，獲取能夠對所述定義文件中未描述處理方法的數據進行處理的其他定義文件，編入所述定義文件中。
3.文檔處理裝置，其特征在于，包括源文件獲取單元，獲取源文件，所述源文件為由標簽確定元素數據的結構化文檔文件、并混合有多種標簽集；定義文件保存單元，保存定義文件，所述定義文件描述了由屬于預定標簽集的標簽所確定的元素數據的數據變換規則，和用于將由不屬于所述預定標簽集的標簽所確定的元素數據的數據處理移交給其他處理系統的移交命令；標簽選擇單元，從源文件中依次選擇應作為數據變換處理對象的標簽；和數據變換單元，對由所選擇的標簽確定的元素數據，通過采用定義文件中的數據變換規則來執行源文件中所包含的各元素數據的數據變換，其中，在作為數據變換處理對象被選擇的標簽不屬于預定的標簽集時，所述數據變換單元根據移交命令將由該標簽確定的元素數據移交給能夠進行數據處理的其他處理系統。
4.文檔處理裝置，其特征在于，包括源文件獲取單元，獲取形成為結構化文檔文件的源文件，所述結構化文檔文件混合有由第一標簽集確定的元素數據和由第二標簽集確定的元素數據；定義文件保存單元，保存確定與第一標簽集對應的數據變換規則的第一定義文件、和確定與第二標簽集對應的數據變換規則的第二定義文件，以作為與標簽對應并確定元素數據變換規則的定義文件；定義文件合并單元，通過結合第一定義文件和第二定義文件來生成合并定義文件，以作為確定與第一標簽集和第二標簽集對應的數據變換規則的定義文件；標簽選擇單元，從源文件依次選擇應作為數據變換處理對象的標簽；和數據變換單元，對由選擇的標簽確定的元素數據使用合并定義文件的數據變換規則，從而對源文件中所包含的各元素數據進行數據變換。
5.如權利要求4所述的文檔處理裝置，其特征在于，在第一定義文件中描述了用于編入其他定義文件的編入命令，所述定義文件合并單元在第一定義文件中描述了將第二定義文件作為編入對象的編入命令時，通過使第二定義文件與第一定義文件結合來生成合并定義文件。
6.文檔處理方法，其特征在于，包括源文件獲取步驟，所述源文件為由標簽確定的元素數據的結構化文檔文件，并混合有多種標簽集；標簽選擇步驟，從源文件依次選擇應作為變換處理對象的標簽；定義文件載入步驟，從記錄媒體載入定義文件，所述定義文件描述了由屬于預定標簽集的標簽所確定的元素數據的數據變換規則，和用于將由不屬于所述預定標簽集的標簽所確定的元素數據的數據處理移交給其他處理系統的移交命令；數據變換步驟，對于由選擇的標簽確定的元素數據使用定義文件的數據變換規則，執行源文件中所包含的各元素數據的數據變換；和移交步驟，在作為數據變換處理對象被選擇的標簽不屬于預定的標簽集時，根據移交命令將由該標簽確定的元素數據移交給能夠進行數據處理的其他處理系統。
7.文檔處理方法，其特征在于，包括源文件獲取步驟，獲取形成為結構化文檔文件的源文件，所述結構化文檔文件混合有由第一標簽集確定的元素數據和由第二標簽集確定的元素數據；定義文件載入步驟，從記錄媒體載入確定與第一標簽集對應的數據變換規則的第一定義文件、和確定與第二標簽集對應的數據變換規則的第二定義文件，以作為與標簽對應并確定元素數據變換規則的定義文件；合并定義文件創建步驟，通過結合第一定義文件和第二定義文件來生成合并定義文件，以作為確定與第一標簽集和第二標簽集對應的數據變換規則的定義文件；標簽選擇步驟，從源文件依次選擇應作為數據變換處理對象的標簽；和數據變換步驟，通過對由選擇的標簽確定的元素數據采用合并定義文件的數據變換規則，對源文件中所包含的各元素數據進行數據變換。
8.文檔處理程序，其特征在于，能使計算機實現如下功能源文件獲取功能，所述源文件為由標簽確定元素數據的結構化文檔文件，并混合有多種標簽集；定義文件保持功能，所述定義文件描述了由屬于預定標簽集的標簽所確定的元素數據的數據變換規則，和用于將由不屬于所述預定標簽集的標簽所確定的元素數據的數據處理移交給其他處理系統的移交命令；標簽選擇功能，從源文件依次選擇應作為變換處理對象的標簽；數據變換功能，對由選擇的標簽確定的元素數據，通過采用定義文件的數據變換規則，執行源文件中所包含的各元素數據的數據變換；和移交功能，在作為數據變換處理對象所選擇的標簽不屬于預定的標簽集時，根據移交命令將由該標簽特定的元素數據移交給能夠進行數據處理的其他處理系統。
9.文檔處理程序，其特征在于能使計算機實現如下功能源文件獲取功能，獲取形成為結構化文檔文件的源文件，所述結構化文檔文件混合有由第一標簽集確定的元素數據和由第二標簽集確定的元素數據；定義文件保持步驟，保持確定與第一標簽集對應的數據變換規則的第一定義文件、和確定與第二標簽集對應的數據變換規則的第二定義文件，以作為與標簽對應并確定元素數據變換規則的定義文件；合并定義文件創建功能，通過結合第一定義文件和第二定義文件來生成合并定義文件，以作為確定與第一標簽集和第二標簽集對應的數據變換規則的定義文件；標簽選擇功能，從源文件依次選擇應作為數據變換處理對象的標簽；和數據變換功能，通過對由選擇的標簽確定的元素數據采用合并定義文件的數據變換規則，對源文件中所包含的各元素數據進行數據變換。
全文摘要
提供了適當處理結構化數據的技術。VC單元通過定義文件所描述的模板使文檔中所包含的元素與目的樹對應，進行處理。文檔中有定義文件的模板中未描述的元素時，VC單元要求主控單元將該元素的處理移交給其它處理系統。主控單元選擇能處理該元素的處理系統并移交處理。另外，當文檔中有定義文件的模板中未描述的元素時，VC單元讀入能夠處理該元素的其他定義文件，合并到定義文件中。
文檔編號G06F17/21GK101057230SQ200580038659
公開日2007年10月17日 申請日期2005年11月14日 優先權日2004年11月12日
發明者葉俊信 申請人:佳思騰軟件公司