专利名称：将文档的一种表述的改变反映到另一种表述的文档处理和管理方法
技术领域：
本文教导了涉及自动将信息的一种类型的表述的改变传播到用于相同信息的另一种类型的表述的技术。具体地说，所述技术涉及对由源DOM树表述的文档的改变，所述改变自动传播到以可选的表述呈现的目的DOM树。
背景技术：
互联网的出现导致由用户处理和管理的文档的数目近乎指数增长。形成互联网核心的万维网联合会(亦即通常所说的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文档处理系统的屏幕设计必须预先进行硬编码(hard code)。
由于这一局限性，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)对象来处理。控制器可操作以解释输入(例如用户的鼠标和键盘输入)，并将这些用户动作映射为发送至模型和/或视窗的命令，以实现适当的改变。模型可操作以管理一个或多个数据元素、响应对其状态的询问、并响应指令以改变状态。视窗可操作以管理显示的矩形区域，并负责通过图形和文本的组合将数据显现给用户。
有时采用两种不同的形式同时表述相同的信息。在这种情况下，希望第一表述的信息的改变自动传播到第二表述。
发明内容
为了实现上述的期望的特征，提供了一种从DOM树传播改变的方法。该方法包括监测所述DOM树的子集，所述子集与模板匹配；改变所述DOM树的被监测的子集；以及自动更新所述DOM树的表述，以反映所述被监测的子集的改变。
所公开的教导的另一方面在于一种用于传播改变的系统。该系统包括第一DOM树；映射到所述第一DOM树的表述。对所述第一DOM树的改变被自动传播到所述表述。
所公开的教导的再一方面在于一种文档管理系统，包括文档的源表述；和文档的目的表述。所述文档的源表述的改变被自动传播到所述文档的目的表述。
所公开的教导的又一方面在于一种计算机可读介质，其包括使计算机能够执行根据所公开的教导的技术的指令。
下面参照附图来详细描述本发明的实施方案，在附图中，相同的参考标记指代相同的元件，其中参照图1-18描述文档处理和管理系统的示例性实现，下面对附图简要描述图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)示出了涉及快照(snap shot)的示例性实现的进一步细节；图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示出了将示例文档MySampleXML载入图1(b)的示例性文档处理和管理系统中的步骤6；图18示出了将示例文档MySampleXML载入图1(b)的示例性文档处理和管理系统中的步骤7；图19(a)示出了在不具有相应的源节点而仅依赖于目的树的节点上发生的事件流；图19(b)示出了在通过TextOfConnector与源节点相关的目的树的节点上发生的事件流；图20示出了词汇连接的示例性实现的图；以及图21是示出被传播的变化的实施例的图。
具体实施例方式
下面参照附图详细描述本文公开的教导的示例性实施方案。
权利要求仅表示本发明的边界和界限。所讨论的实现、实施方案和优点仅是示例性的，因而不应当被解释成是对本发明的限制。本文公开的教导的说明书是示意性的，而不是要限制权利要求的范围。对本领域的技术人员来说，许多替换、修改和改变都将是显而易见的。
A.文档处理和管理系统的总体结构图1(a)图解说明了能够作为在本文中随后详细描述类型的文档处理和管理系统的基础的组件的传统结构。装置10包括具有CPU形式或微处理器形式的处理器11，处理器11通过通信路径13(通常实现为总线)耦合至可为任何当前或将来能获得的ROM和/或RAM存储形式的存储器12。用户输入14(例如鼠标、键盘、语音识别系统或类似设备)的I/O接口16以及显示设备15(或其它用户接口)也耦合至总线用于与处理器11和存储器12通信。如本领域所公知的那样，诸如打印机、通信调制解调器等的其它设备可耦合至该装置。该装置可为独立设备或者具有将多个终端以及一个或多个服务器耦合在一起的联网形式，或者以本领域公知的多种设置方式的其中之一。本发明并不受这些组件的结构、它们的集中式或分布式体系结构或者多种组件的通信方式的限制。
另外，应该注意到，本文所讨论的系统和示例性实现包括几种具有多种功能的组件和子组件。应该注意到，这些组件和子组件可仅使用硬件、仅使用软件以及使用硬件和软件的组合来实现，以提供上述的多种功能。另外，硬件、软件及其组合可使用通用计算装置或使用专用硬件或使用通用计算装置和专用硬件的组合来实现。因此，组件或子组件的结构包括运行特定软件的通用/专用计算装置，以提供该组件或子组件的功能。
图1(b)示出了一种示例性文档处理和管理系统的总体方框图。文档在上述文档处理和管理系统中被创建和编辑。这些文档能够以具有标记语言的特征的任何语言来表述(例如XML)。同样，为方便起见，已经创建了用于特定组件和子组件的术语和名称。但是，这些不应被视作对本文公开的一般教导范围造成了限制。
所述文档处理和管理系统可被视为具有两个基本组件。一个组件是“执行环境”101，它是处理和管理系统运行的环境。例如，执行环境提供了协助系统以及用户对文档进行处理和管理的基本效用和功能。另一组件是“应用程序组件”102，它由在执行环境中运行的应用程序构成。这些应用程序包括文档本身及其各种表述。
1.执行环境执行环境101的关键组件是程序调用器103。程序调用器103是被访问以启动文档处理和管理系统的基本程序。例如，当用户登录并启动文档处理和管理系统时，程序调用器103被执行。程序调用器103能够(例如但并非限制)读取并处理作为插件增加至文档处理和管理系统的功能、启动并运行应用程序、以及读取与文档相关的性质。当用户希望发起计划在执行环境中运行的应用程序时，程序调用器103找到、发起然后执行该应用程序。例如，当用户希望对已经载入到系统中的文档进行编辑(它是执行环境中的一种应用程序)时，程序调用器103首先找到该文档，然后执行用于载入和编辑该文档所必需的功能。
程序调用器103联接至几个组件，例如插件子系统104、命令子系统105以及资源模块109。这些组件将随后进行更详细描述。
a)插件子系统插件子系统104是向文档处理和管理系统增加功能的一种高度灵活和有效的设备。插件子系统104也能够被用来修改和去除文档处理和管理系统中存在的功能。此外，可使用插件子系统增加或修改多种功能。例如，如随后将详细描述的那样，插件子系统可用于增加功能“editlet”，其可操作以有助于在屏幕上呈现文档。插件editlet也有助于对增加至系统的词汇进行编辑。
插件子系统104包括服务代理1041。服务代理1041管理增加至文档处理和管理系统的插件，从而代理已增加至文档处理和管理系统的服务。
代表期望功能的单个功能以“服务”1042的形式被增加至系统。服务1042的可用类型包括但不限于应用程序服务、区工厂服务、editlet服务、命令工厂服务、连接xpath服务、CSS计算服务等。这些服务及其与系统其余部分的关系将随后详细描述，以更好地理解文档处理和管理系统。
插件和服务之间的关系是，插件是可包括一个或多个服务提供器的单元，各个服务提供器具有与之相关的一个或多个类别的服务。例如，使用具有适当软件应用程序的单个插件，能将多个服务中的一个服务增加至系统，从而向系统增加相应的功能。
b)命令子系统命令子系统105被用来执行与文档的处理相关的命令形式的指令。用户可通过执行一系列指令而执行对文档的操作。例如，通过发出命令形式的指令，用户在文档管理系统中处理XML文档，并编辑与该XML文档相对应的XML DOM树。这些命令可利用键盘敲打、鼠标点击或其它有效的用户接口动作而输入。有时，能够通过命令来执行一个以上的指令。在这种情况下，这些指令被封装成单个命令并连续执行。例如，用户可能希望将错误词语替换为正确词语。在这种情况下，第一指令可用以在文档中找寻错误词语。第二指令可用以删除该错误词语。第三指令可用以输入正确词语。这三个指令可被封装成单个命令。
在某些示例中，命令可具有相关功能，例如，下面将要详细讨论的“撤消”功能。这些功能可随后分配给用来创建对象的基类。
命令子系统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。
c)资源资源109是向不同的类提供某些功能的对象。例如，串资源、图标和设定键绑定是系统中使用的资源。
2.应用程序组件应用程序组件102，即文档处理系统的第二个主要特征，在执行环境101中运行。概括而言，应用程序组件102包括实际文档，实际文档包括其在系统内的多个逻辑和物理表述。应用程序组件102还包括系统的、用来管理文档的组件。应用程序组件102进一步包括用户应用程序106、应用程序核心108、用户界面107以及核心组件110。
a)用户应用程序用户应用程序106连同程序调用器103一起被载入到系统中。用户应用程序106是将文档、文档的多种表述以及与文档进行交互所需的用户界面特征结合在一起的粘合剂(glue)。例如，用户可能希望创建作为工程(project)一部分的一套文档。载入这些文档，创建用于文档的适当表述，增加作为用户应用程序106一部分的用户界面功能。换言之，用户应用程序106将文档及其表述的各个方面结合在一起使得用户能够与形成工程一部分的文档进行交互。一旦创建了用户应用程序106，每当用户希望与形成工程一部分的文档进行交互时，用户就能够简单地将用户应用程序106载入到执行环境中。
b)核心组件核心组件110提供了在多个窗格之间共享文档的一种方法。如将在随后详细讨论的那样，窗格表述DOM树，并处理屏幕的物理布局。例如，物理屏幕包括在屏幕内的多个窗格用于描述各条信息。实际上，由用户在屏幕上查看的文档可在一个或多个窗格中显示。此外，两个不同的文档可以出现在屏幕上的两个不同窗格中。
屏幕的物理布局还可以具有树型形式，如图1(c)所示。因此，如果组件1083要作为窗格显示在屏幕上，则该窗格可被实现为根窗格1084。作为一种选择，它也可以是子窗格1085。根窗格1084是窗格树根部的窗格，而子窗格1085是除了根窗格1084之外的任何窗格。
核心组件110也提供字体，并充当用于文档的多个功能性操作的源，例如，工具包(toolkit)。由核心组件110执行的任务的一个示例是在多个窗格之间移动鼠标光标。被执行的任务的另一个示例是标记一个窗格中的文档的一部分，并将其复制到包含不同文档的另一窗格上。
c)应用程序核心如上所述，应用程序组件102由被系统处理和管理的文档组成。应用程序组件102包括对于系统内的文档的多种逻辑和物理表述。应用程序核心108是应用程序组件102的组件。其功能是保持实际文档及其内的所有数据。应用程序核心108包括文档管理器1081和文档1082本身。
文档管理器1081的多个方面将在随后进行更详细的描述。所述文档管理器管理文档1082。所述文档管理器也连接至根窗格1084、子窗格1085、剪贴板实用程序1086以及快照实用程序1087。剪贴板实用程序1086提供了保持用户决定增加至剪贴板的部分文档的一种方法。例如，用户可能希望剪切文档的一部分，并将其保存到新的文档上，用于稍后查看。在这种情况下，剪切的部分被增加至剪贴板。
快照实用程序1087也将在稍后描述，从而当应用程序从一个状态变为另一状态时，能够记住应用程序的当前状态。
d)用户界面应用程序102的另一组件是用户界面107，其为用户提供一种与系统进行物理交互的方式。例如，以物理接口1070来实现用户界面时，用户使用用户界面上载、删除、编辑和管理文档。用户界面包括框架1071、菜单栏1072、状态栏1073以及URL栏1074。
如通常公知的那样，框架可被视为物理屏幕的活动区域。菜单栏1072是屏幕的、包括为用户提供选项的菜单的区域。状态栏1073是屏幕的、显示应用程序的执行状态的区域。URL栏1074提供了输入用于在互联网上定位的URL地址的区域。
B.文档管理器和相关的数据结构图2示出了文档管理器1081的进一步细节。图2包括被用来在文档处理和管理系统内表述文档的数据结构和组件。为了更好的理解，在这部分描述的组件通过利用模型-视图-控制器(MVC)表述范例来进行描述。
文档管理器1081包括文档容器(containter)203，文档容器203保持并容纳文档处理和管理系统中的所有文档。联接至文档管理器1081的工具包201为文档管理器1081的使用提供了各种工具。例如，“DOM服务”是由工具包201提供的能够提供创建、维护和管理与文档相对应的DOM所需的所有功能的工具。作为工具包201提供的另一工具的“IO管理器”分别管理向系统的输入和来自系统的输出。同样地，“流处理器”是一种以比特流方式来处理文档上载的工具。这些工具形成了工具包201的组件，不过并未在图中明确示出或指定附图标记。
根据MVC范例表述，模型(M)包括文档的DOM树模型202。如上所述，所有文档均在文档处理和管理系统中被表述为DOM树。文档也形成文档容器203的一部分。
1.DOM模型和区DOM是由W3C构建的标准。DOM标准定义了用于对节点进行操作的标准接口。在每个词汇或每个节点的基础上，在所述标准内提供了特定的操作。这些操作优选地被提供为API。文档处理/管理系统提供了这种作为“方面(facet)”的节点特定API。每个“方面”都联接到节点。通过将这种“方面”连接到节点，提供了符合DOM标准的有用的API。通过在已应用的标准DOM之上增加特定的API而不是为每个词汇实现特定的DOM，可集中处理多种词汇，并且可以正确地处理其中采用词汇的任意组合的文档。通常，DOM可以被示意性地表述为DOM树。
表述文档的DOM树是具有节点2021的树。作为DOM树的子集的区209包括该DOM树内部的一个或多个所关注的节点。例如，仅文档的一部分可在屏幕上显现。文档可见的这一部分可使用“区”209来表述。利用被称作“区工厂”205的插件来创建、操作和处理区。虽然区表述DOM的一部分，但它也可使用一个以上的“命名空间”。如本领域中公知的那样，命名空间是名称的汇集或集合，这些名称在该命名空间中是唯一。换言之，一个命名空间中不能够出现两个相同的名称。
2.“方面”及其与区的关系“方面”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处理诸如鼠标点击、焦点移动和类似的用户发起的动作等事件。
3.区、“方面”、画布和窗格之间的关系概述文档管理和处理系统内的文档可从至少四个角度来观察，即1)用来保持文档管理系统中的文档的内容和结构的数据结构；2)不会影响文档完整性就能编辑文档内容的方式；3)文档在屏幕上的逻辑布局；以及4)文档在屏幕上的物理布局。区、“方面”、画布和窗格分别表述与上述四个方面相对应的文档管理系统的组件。
4.撤消系统如上所述，人们希望对文档的任何改变(例如，编辑)应该是可撤消的。例如，用户可执行编辑操作，然后决定撤消该改变。参照图2，撤消子系统212是文档管理器的可撤消组件。撤消管理器2121保存可能被用户撤消的、对文档执行的所有操作。例如，用户可执行命令来将文档中的词汇替换成另一个词语。之后，该用户可改变主意并决定保留原来的词语。撤消子系统212协助上述操作。撤消管理器2121保存上述可撤消编辑2122的操作。
5.光标子系统如上所述，MVC的控制器部分可包括光标子系统204。该光标子系统204从用户处接收输入。这些输入通常具有命令和/或编辑操作的性质。因此，光标子系统204可被视作是与文档管理器1081相关的MVC范例的控制器(C)部分。
6.视图如上所述，画布2010表述要显现在屏幕上的文档的逻辑布局。对于XHTML文档的特定实施例而言，画布可包括盒树(box tree)，该盒树是文档在屏幕上如何被查看的逻辑表述。上述盒树可包含在与文档管理器1081有关的MVC范例的视图(V)部分中。
C.词汇连接文档处理管理系统的一个重要特征是，能够以两种不同的方式(例如，以两种标记语言)来表述和显示文档，从而使得两种不同的表述自动保持一致。
标记语言文档(例如XML文档)基于通过文档类型定义限定的词汇创建。词汇则是一组标签集，并可以任意定义，这就使得词汇的数量可能是无限的。但是，为多个可能的词汇中的每一个都提供专用的单独处理和管理环境是不切实际的。词汇连接是解决这种问题的一种方式。
例如，文档可以利用两种或更多标记语言来表述。这些文档例如可以是XHTML(可扩展超文本标记语言)、SVG(可缩放矢量图形)、MathML(数学标记语言)或其他的标记语言。换句话说，标记语言可以视为和XML中的词汇和标签集相同。
词汇可以使用词汇插件来实现。在文档处理和管理系统中，以插件不可用的词汇所描述的文档可以通过将该文档映射为插件可用的另一词汇来显示。因此，以非插件的词汇描述的文档仍然是可以正确显示的。
词汇连接包括获取定义文件、在定义文件之间进行映射、以及生成定义文件的能力。用某种词汇描述的文档能够映射为另外的词汇。因此，词汇连接提供了通过与文档已被映射成的词汇相对应的显示和编辑插件来显示或编辑文档的能力。
应该认识到，各个文档在文档处理和管理系统中被描述为通常具有多个节点的DOM树。“定义文件”为各个节点描述了该节点与其他节点之间的连接。规定了是否可以对各个节点的元素值和属性值进行编辑。还描述了使用节点的元素值和属性值的运算表达式。
利用映射特征，通过参考定义文件创建目的DOM树。因此，源DOM树和目的DOM树之间的关系被建立并维护。词汇连接监控源DOM树和目的DOM树之间的连接。在从用户接收到编辑指令后，词汇连接修改源DOM树中的相关节点。发出表示已经修改了源DOM树的“变化事件”，并且相应地修改目的DOM树。
通过使用词汇连接，仅对于少量用户熟知的相对次要的词汇可以被转换为其他主要的词汇。因此，即便是对于那些仅有少量用户使用的次要词汇，也可以准确地显示文档，并提供理想的编辑环境。
因此，作为文档管理系统一部分的词汇连接子系统提供了能够对文档进行多种表述的功能。
图3显示了词汇连接(VC)子系统300。VC子系统提供了一种维护同一文档的两种可替换表述之间的一致性的方式。在图中具有与上面描述和标识相同的组件，这些组件相互连接从而实现上述目的。例如，两种表述可以是同一文档以两种不同词汇实现的可替换表述。如上所述，其中一种可以是源DOM树，而另一种是目DOM树。
1.词汇连接子系统利用被称为“词汇连接”301的插件在文档处理和管理系统中实现词汇连接子系统300的功能。将被表述的文档的各词汇305都需要相应的插件。例如，如果文档的一部分以HTML表述，而其他部分以SVG表述，则需要相应的HTML词汇插件和SVG词汇插件。
词汇连接插件301为区209或窗格211创建与适当词汇305的文档相对应的适当的词汇连接画布310。使用词汇连接301，利用转换规则，对源DOM树的区209的改变被转换到另一DOM树306的相应区。转换规则以词汇连接描述符(VCD)的形式给出。对于与源和目的DOM之间的这种转换相对应的各个VCD文件，创建相应的词汇连接管理器302。
2.连接器连接器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。
在需要词汇连接时，使用词汇连接画布。在这种情况下，由于不能够为源直接创建视图，因此，不创建源画布。在这种情况下，使用连接器树来创建词汇连接画布。这种词汇连接画布仅仅处理事件转换，而并不会有助于将文档呈现在屏幕上。
3.目的区、窗格以及画布如上所述，词汇连接子系统的目的在于创建并同时维护对同一文档的两种替换表述。第二替换表述还可以是先前被引入作为目的DOM树的DOM树形式。为了浏览第二种表述的文档，需要目的区、画布和窗格。
在创建词汇连接画布后，创建相应的目的窗格307。此外，相关的目的画布308和相应的盒树309被创建。同样，词汇连接画布还与源文档的窗格211和区209关联。
目的画布308提供了文档的第二种表述方式的逻辑布局。具体地，目的画布308提供了用户界面功能，例如光标和选择(selection)，用于以目的表述的方式呈现文档。在目的画布308中发生的事件被提供到连接器。目的画布308向连接器304通知鼠标事件、键盘事件、拖动和放置事件、以及通知文档的目的(或第二种)表述的词汇的特有事件。
4.词汇连接命令子系统图3中的词汇连接子系统300的一部分是词汇连接命令子系统313。词汇连接命令子系统313创建词汇连接命令315，词汇连接命令315用来执行与词汇连接子系统300相关的指令。可通过内建的命令模板3131来创建词汇连接命令，和/或可通过在脚本系统314中使用脚本语言从无到有地创建命令而创建词汇连接命令。
命令模板的例子包括“If”命令模板、“When”命令模板、“Insertfragment”命令模板等。这些模板被用来创建词汇连接命令。
5.XPath子系统XPath子系统316是文档处理和管理系统的一个关键组件，因为它有助于实现词汇连接。连接器304通常包括XPath信息。如上所述，词汇连接的任务是将源DOM树中的变化反映到目的DOM树中。XPath信息包括一个或多个用来确定源DOM树中需要被观察以确定改变/修改的子集的XPath表达式。
6.源DOM树、目的DOM树和连接器树的概述源DOM树是对转换为另一种词汇之前以一种词汇表述的文档进行表述的DOM树或区。在源DOM树中的节点被称为源节点。
另一方面，目的DOM树则表示用于在利用映射进行转换之后以另一种词汇表述的同一文档的DOM树或区，该映射已在前面结合词汇连接描述。目的DOM树中的节点被称为目的节点。
连接器树是基于连接器的分级表述，用来表述源节点和目的节点之间的连接。连接器观察源节点和对源文档进行的修改。连接器随后修改目的DOM树。事实上，只有连接器是能够修改目的DOM树的对象。
D.文档处理和管理系统中的事件流为了能够使用，程序必需对来自用户的命令进行响应。事件是一种描述和执行用户对程序实施的动作的方式。许多高级语言例如JAVA依靠描述用户动作的事件。在现有技术中，程序不得不主动收集用于理解用户动作和通过自身执行用户动作的信息。这可能意味着，例如，在对程序初始化后，程序进入重复地查看用户是否对屏幕、键盘和鼠标等执行了任何动作、并接着采取适当动作的循环。然而，这种处理可能难以操控。此外，这种处理在等候用户作某些事情时，还需要执行循环的程序，从而消耗了CPU周期。
许多语言通过包含不同的范例来解决这些问题，其中的一个范例构成了所有现代的window系统的基础事件驱动程序。在这种范例中，所有的用户动作属于被称为“事件”的事务的抽象集合。一种事件足够详细地描述了特殊的用户动作。在感兴趣的事件发生时，这种系统通知程序，而不是程序主动地收集用户生成的事件。以这种方式处理用户交互的程序被称为“事件驱动”。
这通常使用事件类来进行处理，其中事件类捕获了所有用户生成事件的基础特性。
文档处理和管理系统定义和使用其自身的事件以及处理这些事件的方式。几种类型的事件被使用。例如，鼠标事件是来自用户的鼠标动作的事件。与鼠标有关的用户动作由画布210传递到鼠标事件。因此，画布可以被认为是用户与系统交互的最前沿。如果需要，最前沿的画布将把其与事件有关的内容传递到其下级(children)。
另一方面，按键事件从画布210产生。按键事件具有瞬时的焦点，即，按键事件涉及任意瞬时的活动。进入到画布210的按键事件接着被传递到其上级(parent)。键盘输入通过能够处理字符串插入的不同事件而被处理。在使用键盘插入字符时，将触发处理字符串插入的事件。其他的“事件”包括例如拖动事件、放置事件和其他能够以与鼠标事件相似的方式处理的事件。
1.在词汇连接之外处理事件使用事件线程对事件进行传递。在接收到事件后，画布210改变其状态。如果需要，画布210将命令1052记入到命令队列1053。
2.在词汇连接之内处理事件通过使用词汇连接插件301，目的画布1106接收现有的事件，例如鼠标事件、键盘事件、拖动和放置事件、以及词汇的特有事件。这些事件接着被通知到连接器1104。更具体地说，词汇连接插件301内的事件流经过源窗格1103、词汇画布1104、目的窗格1105、目的画布1106、目的DOM树和连接器树1104，如图11所示。
E.程序调用器及其与其他组件之间的关系在图4(a)中更加详细地显示了程序调用器103及其与其他组件之间的关系。程序调用器103是在执行环境中被执行以启动文档处理和管理系统的基本程序。用户应用程序106、服务代理1041、命令调用器1051和资源109都被联接到程序调用器103，如图1B所示。如前所述，应用程序102是在执行环境中运行的组件。同样，服务代理1041管理向系统增加各种功能的插件。另一方面，命令调用器1051维护用来执行命令的类和函数，从而执行用户提供的指令。
1.插件和服务下面将参照图4(b)详细描述服务代理1041。如上所述，服务代理1041管理向系统增加各种功能的插件(及相关服务)。服务1042在最底层，在该层中可以将特征增加到文档处理和管理系统，或改变该系统中的特征。“服务”由两部分构成服务种类401和服务提供器402。如图4(c)所示，单个的服务种类401可具有多个相关的服务提供器402，这些多个服务提供器402中的每一个都可操作以执行所有或部分的特定服务种类。另一方面，服务种类401则定义了服务的类型。
服务可分为三种类型1)向系统提供特定特征的特征服务；2)应用程序服务，其是由文档处理和管理系统运行的应用程序；以及3)提供在整个文档处理和管理系统中需要的特征的环境服务。
图4(d)中示出了服务的例子。根据应用程序服务的种类，系统实用程序是相应服务提供器的示例。同样，editlet 206是一个种类，HTML editlet和SVG editlet是相应的服务提供器。区工厂205是服务的另一种，并具有相应的服务提供器(未示出)。
之前描述的向文档处理和管理系统增加功能的插件可以看作是由几个服务提供器402和与其相关的类构成的单元，如图4(c)和4(d)所示。各个插件都应该具有在清单文件(manifest file)中写入的从属和服务种类。
2.程序调用器和应用程序之间的关系图4(e)详细显示了程序调用器103和用户应用程序106之间的关系。所需的文档、数据等从存储中载入。所有需要的插件载入到服务代理1041。服务代理1041管理并维护所有的插件。可物理地将插件增加到系统，或者可从存储中载入其功能。在载入插件的内容后，服务代理1041定义相应的插件。相应的用户应用程序106被创建，接着被载入到执行环境101并联接到程序调用器103。
F.应用程序服务和环境之间的关系图5(a)进一步示出了载入程序调用器103中的应用程序服务的结构。作为命令子系统105组件的命令调用器1051调用或执行程序调用器103内的命令1052。命令1052则是用来在文档处理和管理系统中处理文档(例如，XML文档)和编辑相应的XML DOM树的指令。命令调用器1051维护执行命令1052所需的功能和类。
服务调用器1041也在程序调用器103中执行。用户应用程序106连接到用户界面107和核心组件110。核心组件110提供了一种在所有的窗格中共享文档的方式。核心组件110还提供字体并作为用于窗格的工具包。
图5(a)和5(b)显示了框架1071、菜单栏1072和状态栏1073之间的关系。
G.应用程序核心图6(a)进一步解释了应用程序核心110，其保持所有文档以及作为文档一部分并属于文档的数据。应用程序核心110联接到管理文档1082的文档管理器1081。文档管理器1081是存储到与文档处理和管理系统关联的存储器中的所有文档1082的所有者(proprietor)。
为了便于在屏幕上显示文档，文档管理器1081还连接到根窗格1084。剪贴板1086、快照1087、拖拉和放置601，覆盖602的功能也被联接到所述应用程序核心。
如图16(a)所示，快照1087用来撤消应用程序状态。在用户调用快照功能1087时，应用程序的当前状态被检测并存储。所存储的状态的内容在应用程序改变为另一状态时被保存下来。在图6(b)中示出了快照。在操作中，当应用程序从一个URL移动到另一个时，快照会记住先前的状态，从而能够无缝地执行后退和前进操作。
H.在文档管理器中组织文档图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，并因此可以是可撤消编辑对象。
I.撤消命令和撤消框架图8(a)和8(b)进一步详细地显示了撤消框架和撤消命令。如图8(a)所示，撤消命令801、重做命令802和可撤消编辑命令803是能够排列在命令调用器1051中的命令(如图1(b)所示)并且被相应地执行。可撤消编辑命令803还进一步联接到可撤消编辑源708和可撤消编辑接收器709。例如，可撤消编辑命令是“foo”编辑命令803和“bar”编辑命令804。
1.可撤消编辑命令的执行图8(b)显示了可撤消编辑命令的执行。首先，假设用户使用编辑命令来编辑文档705。在第一步骤S1，可撤消编辑接收器709被联接到可撤消编辑源708，而可撤消编辑源708为文档705的DOM树。在第二步骤S2，基于由用户发出的命令，使用DOM API对文档705进行编辑。在第三步骤S3，向变化事件监听器通知已经发生了改变。即，在该步骤，监控DOM树中所有改变的监听器检测编辑操作。在第四步骤S4，用撤消管理器706将可撤消的编辑存储为对象。在第五步骤S5，可撤消编辑接收器709与源708分开，源708可以是文档705本身。
J.向系统载入文档时需要的步骤上述几个子部分描述了系统的各个组件和子组件。下面将描述在使用这些组件时用到的方法。图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的情况下，这包括盒树结构。
1.用于区的MVC图9(b)使用MVC范例显示了区的结构概要。在这种情况下，模型(M)包括区和“方面”，这是因为它们是与文档相关的输入。视图(V)对应于画布和数据结构，以便将文档在屏幕上呈现，这是由于这些是用户在屏幕上看到的输出。控制(C)包括画布中所包含的命令，这是由于这些命令对文档及其关系执行控制操作。
K.文档的表述下面将使用图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。XHTML editlet创建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通过SVG editlet创建，并被联接到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。
L.插件子系统、词汇连接和连接器之间的关系图12(a)-(c)分别显示了与插件子系统、词汇连接和连接器相关的附加细节。插件子系统被用来向文档处理和管理系统增加功能，或与之交换功能。插件子系统包括服务代理1041。如图12(a)所示，名称为“My Own XML vocabulary(我的XML词汇)”VCD文件耦合至包括MyOwnXML连接器工厂树和词汇(区工厂构造器)的VC基本插件。联接到服务代理1041的区工厂服务1201负责创建用于文档的部分的区。editlet服务1202还被联接到服务代理。editlet服务1202创建与区中的节点相对应的画布。
区工厂的实施例是分别创建XHTML区和SVG区的XHTML区工厂1211和SVG区工厂1212。如上参照示例性文档所述，文档的文本组件可通过创建XHTML区来表述，而图片则可使用SVG区来表述。editlet服务的示例包括XHTML editlet 1221和SVG editlet 1222。
图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”节点。
M.VCD文件相关的连接器树的示例下面将解释与特定文档相关的处理。名为MySampleXML的文档被载入到文档处理系统。图13显示了使用词汇连接管理器的VCD脚本和用于文件MySampleXJML的连接器工厂树的实施例。在图中显示了脚本文件内的词汇部分、模板部分以及它们在词汇连接管理器中的相应组件。在标签“vcd:vocabulary”下提供了属性match＝″sample:root″、label＝″MySampleXML″以及call-template＝″sampleTemplate″。
与该实施例相对应，在MySampleXML的词汇连接管理器中，词汇包括顶点元素“sample:root”。相应的UI标注为“MySampleXML”。在模板部分，标签为vcd:template，名称为“sample template”。
N.如何将文件载入系统的详细实施例图14-18显示了载入文档MySampleXML的详细描述。在步骤1，如图14(a)所示，文档从存储1405中载入。DOM服务创建DOM树和文档管理器1406以及对应的文档容器1401。文档容器联接到文档管理器1406。文档包括用于XHTML和MySampleXML的子树。XHTML顶节点1403是用于XHTML的最顶部的节点，并具有标签xhtml:html。另一方面，mysample顶节点1404对应于MySampleXML，并具有标签sample:root。
在步骤2，如图14(b)所示，根窗格为文档创建XTML区、“方面”和画布。创建与顶节点1403对应的窗格1407、XHTML区1408、XHTML画布1409和盒树1410。
在步骤3，如图14(c)所示，XHTML区域找到外来的标签“sample:root”，并从html画布上的区域创建子窗格。
图15显示了步骤4，在步骤4中，子窗格获取能够处理“sample:root”标签并创建适当的区的相应的区工厂。这种区域工厂将在能够实现区域工厂的词汇中。区域工厂包括MySampleXML中的词汇部分的内容。
图16显示了步骤5，在步骤5中，与MySampleXML对应的词汇创建缺省的区1061。相应的editlet被创建并被提供给子窗格1501，以创建相应的画布。editlet创建词汇连接画布。接着，editlet调用所述模板部分。所述连接器工厂树也被包括在内。连接器工厂树创建所有的连接器，接着将创建的连接器形成连接器树(连接器树形成VC画布的一部分)。根据前面的描述，对于与文档的XHTML内容相关的顶节点，根窗格和XHTML区的关系以及XHTML画布和盒树之间的关系是显而易见的。
图17基于如上所述的源DOM树、VC画布和目的DOM树之间的对应关系显示了步骤6。在步骤6中，各个连接器创建目的DOM对象。一些连接器包括XPath信息。XPath信息包括一个或多个XPath表达式，XPath表达式用来确定需要被监测是否发生了改变/修改的源DOM树的子集。
图18根据源、VC和目的关系显示了步骤7。在步骤7中，词汇从源DOM的窗格形成目的DOM树的目的窗格。这基于源窗格来完成。接着，将目的树的顶节点联接到目的窗格以及相应的区。接着为目的窗格设置其自身的editlet，editlet则创建目的画布，并构建数据结构和命令，从而以目的格式呈现文档。
图19(a)显示了发生于某节点的事件流，该节点不具有相应的源节点并仅依赖于目的树。画布所获取的事件(例如鼠标事件和键盘事件)通过目的树，并被传输到元素模板连接器(ElementTemplateConnector)。元素模板连接器不具有相应的源节点，因此被传送的事件并不是对源节点的编辑操作。如果所传送的事件与命令模板(CommandTemplate)中描述的命令相匹配，则元素模板连接器执行相应的动作。否则，元素模板连接器忽略所传送的事件。
图19(b)显示了发生于某目的树的节点的事件流，该目的树的节点通过文本连接器(TextOfConnector)与源节点相关联。文本连接器从由源DOM树的XPath规定的节点获取文本节点，并将该文本节点映射为目的DOM树的节点。画布所获取的事件(例如鼠标事件和键盘事件)通过目的树，并被传送到文本连接器。文本连接器将所传送的事件映射为相应源节点的编辑命令，并将这些命令设置在队列1053中。编辑命令是通过“方面”执行的、与DOM有关的一组API调用。当执行设置在队列中的命令时，编辑源节点。在编辑源节点时，发出变化事件，并且将对源节点的修改通知到注册为监听器的文本连接器。文本连接器重新建立目的树，从而在相应的目的节点中反映出对源节点的修改。如果包含文本连接器的模板包括控制声明，例如“foreach”和“for loop”，则连接器工厂重新评估控制声明。在重建文本连接器后，重建目的树。
O.用于传播改变的方法的细节在计算机应用程序中，通常将文档(例如XML文档)作为DOM树来存储。图10包括表述XML文档的一部分的DOM树1003。应当注意，虽然采用DOM树作为实施例来解释已公开的教导，但是本文所公开的技术也可以应用于可被表述为树或图的任何信息。
图20示出了词汇连接，而词汇连接是用于实现本文所公开的技术的一种示例性方式。文档的一部分被表述为源DOM树。源DOM树2001是在其转换到可选的表述之前的DOM树。源DOM树20011-2001n中的节点为源节点，源DOM树中的元素为源元素。
区是可由插件处理的DOM树的一部分。对于特定的区，创建目的DOM树2003。目的树的节点和元素被称作目的节点和目的元素。
源节点和目的节点通过连接器相连。连接器树2002是用于连接的树。连接器树可以利用连接器工厂来创建。连接器利用连接Xpath中的函数xpath来查看源节点。Xpath利用模板来监测源节点。
例如，模板“A/*/D”监测所有从节点A开始、在节点D结束的树分支，而不考虑节点A和节点D之间的节点。同样，“//B”对应于所有来自根节点的“B”节点。
可选的表述可以是目的DOM树。
利用模板来监测DOM树的子集。在DOM树的被监测的子集中进行改变。DOM树的表述被自动更新为反映被监测的子集的改变。
当连接Xpath所监测的节点集之中的节点发生改变时，DOM结构中的变化事件监听器监听这一变化。变化事件监听器发送变化事件。连接Xpath捕获该变化事件。连接Xpath对该变化事件进行评估。如果用于监听值改变的被监测节点函数发生变化，那么则通知例如值改变监听器(ValueChangeListeners)。如果存在可能会影响被监测节点的其他节点，那么便将这些节点呈现给监听器。值改变监听器是用于监听对被监测节点作出的修改、并相应地作出动作的监听器。
图21示出了其中连接Xpath与VC一起使用的示例性的实现。书写VCD以便为每个来自根节点的“B”节点创建DIV部分。在这种情况下，连接Xpath监测所有满足模板“//B”路径的节点。可以看出，在实际的DOM中存在两个“B”节点2101、2102。被映射的DOM树将由屏幕上所显示的两个DIV部分组成。另一个“B”节点2103被增加至被编辑的DOM。连接Xpath拾取DOM的这一变化，并将另一个DIV部分映射到新创建的“B”节点。
在可选的实现中，连接Xpath与菜单一起使用。可以使菜单中未使用的项变为灰色。本文所公开的连接Xpath特征和技术可以实现这一特征。利用Xpath和模板来监测的节点将是插入记号(caret)的位置。光标的移动被监控。当光标移动到新位置时，只有当光标位于被映射到可执行命令的位置时才会进行评估。
通常监控并过滤出文档的特定部分，以便仅执行适当的变化事件。
另一种示例性的实现采用CSS选择器(用于CSS的W3C定义)。当CSS被改变时，其呈现会受到CSS改变的影响的文档部分也被改变，从而使所有其他部分保持原样。
另一种实现涉及在关系数据库的上下文中使用的树形结构。树被用来表述人们的关系、用于论文的相关文档以及所属结构树之间的关系。如果树的结构发生改变，那么该改变可被路由到其内容发生改变的所有文档。例如，然后可以将文档发送到需要其同意才可进行改变的人员。
在web的上下文中，可以监控页面及其链接的移动。
在另一种可选的实现中，可以监控疾病的副作用和疾病的治愈。
在又一种实现中，采用树的形式来表述用于电子设备的蓝图的关系。监控对树中的节点的改变，并将所述改变传播到使用所述电子设备的所有产品。
对于本领域的技术人员来说，根据前面公开的内容和教导进行其他的修改和变化将是显而易见的。因此，虽然本文仅具体描述了本发明的某些实施方案，但是在不背离本发明的精神和范围的情况下，可以对上述实施方案进行多种修改将是显而易见的。
权利要求
1.一种从DOM树传播改变的方法，所述方法包括监测所述DOM树的子集，所述子集与模板匹配；改变所述DOM树的被监测的子集；以及自动更新所述DOM树的表述，以反映所述被监测的子集的改变。
2.如权利要求1所述的方法，其中所述表述为第二DOM树。
3.如权利要求1所述的方法，其中通过连接机制来实现监测。
4.如权利要求1所述的方法，其中变化事件监听器监听所述DOM树。
5.如权利要求4所述的方法，其中，当所述DOM树中发生修改时，所述变化事件监听变化事件。
6.如权利要求3所述的方法，其中所述连接机制包括用于监测所述DOM树中的节点的函数。
7.如权利要求5所述的方法，其中所述变化事件将更新发送到需要被更新的所述表述中的节点。
8.如权利要求1所述的方法，其中待监测的所述DOM树的每个子集都在所述连接机制中具有相应的模板。
9.一种用于传播改变的系统，包括第一DOM树；映射到所述第一DOM树的表述；其中，对所述第一DOM树的改变被自动传播到所述表述。
10.如权利要求9所述的系统，其中所述表述为第二DOM树。
11.如权利要求9所述的系统，进一步包括操作以监测所述第一DOM树中的节点的连接机制。
12.如权利要求11所述的系统，其中所述第一DOM树包括变化事件监听器。
13.如权利要求12所述的系统，其中，当所述第一DOM树中发生修改时，所述变化事件操作以监听变化事件。
14.如权利要求11所述的系统，其中所述连接机制包括用于监测所述第一DOM树中的节点的函数。
15.如权利要求12所述的系统，其中所述事件将更新发送到需要被更新的所述表述中的树结构。
16.如权利要求11所述的系统，其中所述连接机制包括至少一个模板。
17.如权利要求16所述的系统，其中所述模板能够与所述第一DOM树的子集匹配。
18.如权利要求16所述的系统，其中待监测的所述第一DOM树的每个子集都在所述连接机制中具有相应的模板。
19.如权利要求9所述的系统，其中所述第一DOM树表述XML文档的至少一部分。
20.一种文档管理系统，包括文档的源表述；文档的目的表述；其中所述文档的源表述的改变被自动传播到所述文档的目的表述。
21.如权利要求20所述的系统，其中所述源表述为第一DOM树。
22.如权利要求20所述的系统，其中所述文档的所述目的表述为第二DOM树。
23.如权利要求21所述的系统，进一步包括监测所述第一DOM树中的节点的连接机制。
24.如权利要求22所述的系统，其中所述第一DOM树包括变化事件监听器。
25.如权利要求24所述的系统，其中当所述第一DOM树中发生修改时，所述变化事件监听器监听变化事件。
26.如权利要求22所述的系统，其中所述连接机制包括用于监测所述第一DOM树中的节点的函数。
27.如权利要求24所述的系统，其中所述变化事件将更新发送到需要被更新的所述表述的第二中的节点。
28.如权利要求22所述的系统，其中所述连接机制包括至少一个模板。
29.如权利要求28所述的系统，其中所述模板能够与所述第一DOM树的子集匹配。
30.如权利要求20所述的系统，其中待监测的所述第一节点的每个子集都在所述连接机制中具有相应的模板。
31.如权利要求20所述的系统，其中所述第一DOM树表述XML文档的至少一部分。
31.一种包含计算机可读介质的计算机程序产品，所述介质包括使计算机能够实现传播文档中的改变的方法的指令，所述指令包括生成所述文档的至少一部分的源表述；生成与所述源表述对应的目的表述；监测所述文档的源表述的改变；改变所述文档的源表述；以及自动将所述改变传播到所述文档的目的表述。
32.如权利要求31所述的计算机程序产品，其中所述源表述为第一DOM树。
33.如权利要求31所述的计算机程序产品，其中所述目的表述为第二DOM树。
34.如权利要求31所述的计算机程序产品，其中通过连接机制来实现监测。
35.如权利要求31所述的计算机程序产品，其中变化事件监听器监听所述第一DOM树。
36.如权利要求35所述的计算机程序产品，其中当所述第一DOM树中发生修改时，所述变化事件监听器监听变化事件。
37.如权利要求34所述的计算机程序产品，其中所述连接机制包括用于监测所述第一DOM树中的节点的函数。
38.如权利要求36所述的计算机程序产品，其中所述变化事件将更新发送到需要被更新的所述表述的第二中的节点。
39.如权利要求31所述的计算机程序产品，其中待监测的所述第一节点的每个子集都在所述连接机制中具有相应的模板。
全文摘要
一种从DOM树传播改变的方法。该方法包括监测所述DOM树的子集，所述子集与模板匹配。改变所述DOM树的被监测的子集。自动更新所述DOM树的表述，以反映所述被监测的子集的改变。
文档编号G06Q99/00GK101052986SQ200580026209
公开日2007年10月10日 申请日期2005年8月2日 优先权日2004年8月2日
发明者和家伸明 申请人:佳思腾软件公司