概要
互联网的出现导致由用户处理和管理的文档的数目近乎指数增 长。形成互联网核心的万维网联合会(亦即通常所说的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)对象来 处理。控制器可操作以解释输入(例如用户的鼠标和键盘输入)，并将 这些用户动作映射为发送至模型和/或视窗的命令，以实现适当的改 变。模型可操作以管理一个或多个数据元素、响应对其状态的询问、 并响应指令以改变状态。视窗可操作以管理显示的矩形区域，并负责 通过图形和文本的组合将数据显现给用户。
通常，每个XML文档必须具有两个组件：XML声明和根元素。 在生成新文档的过程中，首先必须创建具有适当的声明和根元素的、 新的空白的XML文档。但是，空XML文档的生成会遇到重大障碍。 首先，完全空的XML文档是不可能存在的，因为每个文档必须至少 具有根元素，以便被识别为XML文档。其次，在创建新XML文档时， 需要提供标签或者在形成文档的框架之后创建标签。再次，与采用标 记语言(例如XML)书写的文档有关的“命名空间”的使用给根据根 元素被适当指派的旧文档来创建新文档带来了问题。标记语言将利用 词汇来定义文档的成分。例如，词汇可以作为表述XML文档的DOM 树的子树出现。“词汇”是属于命名空间的一组标签(例如XML标签)。 但是，在本领域中可以理解的是，命名空间是唯一的名称(标签)的 集合，因此命名空间中的两个名称是不能够相同的。由于相同名称的 根元素将随着命名空间的不同而完全不同，因此在一个或多个公共名 称的基础上，生成具有期望的根元素的文档是不能够可靠地实现的。
因此，需要在使用标记语言、尤其是XML的文档处理和管理环 境中，提供容易地、可靠地生成具有期望的根元素的新文档的能力。

本发明涉及创建至少具有根元素和声明的新标记语言文档的方 法。该方法包括从存储中检索新片段标记语言文档，所述新片段标记 语言文档包括用于其自身具有根元素的新标记语言文件的至少一个标 记语言模板。然后，选择至少一个标记语言模板，并且利用被选择的 标记语言模板来创建标记语言文档。
本发明进一步涉及一种文档处理系统，其可操作以向用户提供创 建至少具有根元素和声明的新标记语言文档的能力。所述文档处理系 统包括至少一个存储器，用于至少存储标记语言形式的文档模板，并 且所述文档模板包括根部、声明和至少相关的名称属性。还包括至少 一个处理器，其操作以在指定的名称属性的基础上，搜索存储器以查 找标记语言形式的至少一个文档模板，并且提取出具有一个或多个匹 配名称属性的一个或多个文档模板。该系统具有至少一个显示装置， 用于显示来自存储器的文件形式的日记应用程序，所述文件为词汇连 接描述符文件，并且包含标记语言形式的至少一个候选模板。最后， 该系统至少具有用户输入，用于使用户能够从被显示的候选模板中选 择文档模板。
本发明还包括一种文档处理装置，其可操作以向用户提供创建至 少具有根元素和声明的新标记语言文档的能力。这种装置具有：存储 器，用于至少存储标记语言形式的文档模板，并且所述文档模板包括 根部、声明和至少相关的名称属性；以及处理器，其操作以在指定的 名称属性的基础上，搜索存储器以查找标记语言形式的至少一个文档 模板，并且提取出具有一个或多个匹配名称属性的一个或多个文档模 板。该装置包括：显示装置，用于显示来自存储器的文件形式的日记 应用程序，所述文件为词汇连接描述符文件，并且包含标记语言形式 的至少一个候选模板；以及用户输入，用于使用户能够从被显示的候 选模板中选择文档模板。
本发明还包括一种用于创建至少具有根元素和声明的新标记语言 文档的用户界面。该界面以新片段标记语言文档的显示的形式嵌入， 其中所述新片段标记语言文档包括用于新标记语言文件的至少一个标 记语言模板。还具有用户输入，用于检测所述至少一个标记语言模板， 其中，所述用户输入操作以用于在所述至少一个模板中选择标记语言 模板，从而创建标记语言文档。
本发明的进一步的特征在于一种程序员界面，用于向用户提供创 建至少具有根元素和声明的新标记语言文档的能力。所述程序员界面 具有：日记应用程序的显示，其中所述日记应用程序具有词汇连接描 述符文件的形式。还具有程序员输入，用于输入至少一个新片段，所 述至少一个新片段联合名称属性来表述用于新标记语言文件的标记语 言文档模板，并且程序员输入用于存储至少一个新片段及其相关的名 称属性。
本发明的再一个特征在于一种具有存储介质形式的产品，其中记 录有用于使计算机执行用于创建至少具有根元素和声明的新标记语言 文档的方法的程序。所述方法包括：检索新片段标记语言文档，所述 新片段标记语言文档包括用于新标记语言文件的至少一个标记语言模 板；以及检测所述至少一个标记语言模板。被检测的标记语言模板被 用来创建标记语言文档。
附图说明
下面参照附图来详细描述本发明的实施方案，在附图中，相同的 参考标记指代相同的元件，其中：
图1(a)示出了能够作为所公开的文档处理和管理系统的一个示 例性实现的基础的组件的传统结构；
图1(b)-(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)-(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的 示例性文档处理和管理系统中的步骤0-3；
图15示出了将示例文档MySampleXML载入图1的示例性文档处 理和管理系统中的步骤4；
图16示出了将示例文档MySampleXML载入图1的示例性文档处 理和管理系统中的步骤5；
图17(a)示出了将示例文档MySampleXML载入图1(b)的示 例性文档处理和管理系统中的步骤6；
图17(b)示出了将示例文档MySampleXML载入图1(b)的示 例性文档处理和管理系统中的步骤7；
图18(a)示出了在不具有相应的源节点而仅依赖于目的树的节 点上发生的事件流；
图18(b)示出了在通过TextOfConnector与源节点相关的目的树 的节点上发生的事件流；
图19(a)是图解说明在本发明的示例性环境中用于工作区的目 录系统的屏幕截图；
图19(b)是图解说明利用片段和/或方案来生成新文档的步骤的 流程图；
图19(c)是图解说明程序员采取步骤以设置一个或多个片段或 改变片段的流程图；
图20是示例性日记应用程序、特别是XML转换脚本(例如包含 两个新片段的词汇连接描述(VCD)文件)的屏幕截图；
图21是用于图20的示例性VCD文件的源代码的屏幕截图；以及
图22是在选择了图20的两个新片段中的一个片段之后载入的新 文档的屏幕截图。

下面参照附图详细描述本发明的示例性实施方案。
权利要求仅表示本发明的边界和界限。所讨论的实现、实施方案 和优点仅是示例性的，因而不应当被解释成是对本发明的限制。本发 明的说明书是示意性的，而不是要限制权利要求的范围。对本领域的 技术人员来说，许多替换、修改和改变都将是显而易见的。
图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文档相对应的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。
资源
资源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文档的特定实施例而言，画布可包括盒树(box tree)，该 盒树是文档在屏幕上如何被查看的逻辑表述。上述盒树可包含在与文 档管理器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”命令模板、“Insert fragment”命令模板等。这些模板被用来创建词汇连接命令。
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)中示出了服务的例子。根据应用程序服务的种类，系统 实用程序是相应服务提供器的示例。同样，editlet 206是一个种类， HTML editlet和SVG editlet是相应的服务提供器。区工厂205是服务 的另一种，并具有相应的服务提供器(未示出)。
之前描述的向文档处理和管理系统增加功能的插件可以看作是由 几个服务提供器402和与其相关的类构成的单元，如图4(c)和4(d) 所示。各个插件都应该具有在清单文件(manifest file)中写入的从属 和服务种类。
程序调用器和应用程序之间的关系
图4(e)详细显示了程序调用器103和用户应用程序106之间的 关系。所需的文档、数据等从存储中载入。所有需要的插件载入到服 务代理1041。服务代理1041管理并维护所有的插件。可物理地将插 件增加到系统，或者可从存储中载入其功能。在载入插件的内容后， 服务代理1041定义相应的插件。相应的用户应用程序106被创建，接 着被载入到执行环境101并联接到程序调用器103。
应用程序服务和环境之间的关系
图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 之间的关系。
应用程序核心
图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，基于由用户发出的命令，使用DOM API对文档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。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。
插件子系统、词汇连接和连接器之间的关系
图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”节点。
VCD文件相关的连接器树的示例
下面将解释与特定文档相关的处理。名为MySampleXML的文档 被载入到文档处理系统。图13显示了使用词汇连接管理器的VCD脚 本和用于文件MySampleXJML的连接器工厂树的实施例。在图中显示 了脚本文件内的词汇部分、模板部分以及它们在词汇连接管理器中的 相应组件。在标签“vcd:vocabulary”下提供了属性match＝″sample:root″、 label＝″MySampleXML″以及call-template＝″sampleTemplate″。
与该实施例相对应，在MySampleXML的词汇连接管理器中，词 汇包括顶点元素“sample:root”。相应的UI标注为“MySampleXML”。 在模板部分，标签为vcd:template，名称为“sample template”。
如何将文件载入系统的详细实施例
图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(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 调用。当执行设置在队列中的命令时，编辑源节点。在编辑源节点时， 发出变化事件，并且将对源节点的修改通知到注册为监听器的文本连 接器。文本连接器重新建立目的树，从而在相应的目的节点中反映出 对源节点的修改。如果包含文本连接器的模板包括控制声明，例如“for each”和“for loop”，则连接器工厂重新评估控制声明。在重建文本连 接器后，重建目的树。图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文档相对应的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。
资源
资源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为文档管理器108 1的使用提供了各种工具。例如， “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文档的特定实施例而言，画布可包括盒树(box tree)，该 盒树是文档在屏幕上如何被查看的逻辑表述。上述盒树可包含在与文 档管理器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”命令模板、“Insert fragment”命令模板等。这些模板被用来创建词汇连接命令。
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)中示出了服务的例子。根据应用程序服务的种类，系统 实用程序是相应服务提供器的示例。同样，editlet 206是一个种类， HTML editlet和SVG editlet是相应的服务提供器。区工厂205是服务 的另一种，并具有相应的服务提供器(未示出)。
之前描述的向文档处理和管理系统增加功能的插件可以看作是由 几个服务提供器402和与其相关的类构成的单元，如图4(c)和4(d) 所示。各个插件都应该具有在清单文件(manifest file)中写入的从属 和服务种类。
程序调用器和应用程序之间的关系
图4(e)详细显示了程序调用器103和用户应用程序106之间的 关系。所需的文档、数据等从存储中载入。所有需要的插件载入到服 务代理1041。服务代理1041管理并维护所有的插件。可物理地将插 件增加到系统，或者可从存储中载入其功能。在载入插件的内容后， 服务代理1041定义相应的插件。相应的用户应用程序106被创建，接 着被载入到执行环境101并联接到程序调用器103。
应用程序服务和环境之间的关系
图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 之间的关系。
应用程序核心
图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，基于由用户发出的命令，使用DOM API对文档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。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。
插件子系统、词汇连接和连接器之间的关系
图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”节点。
VCD文件相关的连接器树的示例
下面将解释与特定文档相关的处理。名为MySampleXML的文档 被载入到文档处理系统。图13显示了使用词汇连接管理器的VCD脚 本和用于文件MySampleXJML的连接器工厂树的实施例。在图中显示 了脚本文件内的词汇部分、模板部分以及它们在词汇连接管理器中的 相应组件。在标签“vcd:vocabulary”下提供了属性match＝″sample:root″、 label＝″MySampleXML″以及call-template＝″sampleTemplate″。
与该实施例相对应，在MySampleXML的词汇连接管理器中，词 汇包括顶点元素“sample:root”。相应的UI标注为“MySampleXML”。 在模板部分，标签为vcd:template，名称为“sample template”。
如何将文件载入系统的详细实施例
图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(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 调用。当执行设置在队列中的命令时，编辑源节点。在编辑源节点时， 发出变化事件，并且将对源节点的修改通知到注册为监听器的文本连 接器。文本连接器重新建立目的树，从而在相应的目的节点中反映出 对源节点的修改。如果包含文本连接器的模板包括控制声明，例如“for each”和“for loop”，则连接器工厂重新评估控制声明。在重建文本连 接器后，重建目的树。
新方案/新片段操作的细节
如已经描述的那样，整个系统的结构由可以处理标记语言文档(例 如XML)的框架组成。为了便于解释本发明，将该框架命名为 “chimaira”。假定系统采用整体的分级目录结构，那么chimaira框架 将使目录在整个系统的工作区目录内被创建，并且在附随的实施例中 为了方便而将其表示为“eclipse”。图1 9A提供了用于说明示例性框架 目录的屏幕截图，其中用于子目录的各种术语(Ark2Exe、ArkPlace、 SacParser等)涉及框架(chimaira)目录内的文件的非限定性实施例。 如图所示，除了库目录“Libraries.src”之外，几乎所有以“.src”结尾 的目录都是由源代码组成的目录，并且几乎所有的源目录都对应于先 前解释的一个插件。
新的实例词汇与本发明一起使用，其中新的实例词汇的命名空间 例如可像“ http://xmhis.chimaira.org/new-instance”一样构造。如上所 述，在上述命名空间中使用的术语“chimaira”表示系统的框架目录。 新的实例词汇的命名空间可以包括“new-fragment(新片段)”元素， 以作为最外面的元素。如下面将说明的那样，new-fragment元素可以包 括唯一的“name”和参照整个目录结构来指定文档位置的“save URL” 属性。新的实例词汇随着新活动或新事件(例如新文档)的识别而被 识别，并且在新文档中，new-fragment元素可以用来识别文档源的位 置。
根据本发明，生成新文档的过程包括至少两个基本步骤。第一步 骤包括建立可访问以用于文档生成的一个或多个预定的模型。第二步 骤包括随后选择用于文档生成的一个或多个预定的模型或者在用于文 档生成的一个或多个预定的模型中进行选择。两个步骤的关键在于路 径的识别，而该路径可以用来访问用于文档生成的期望模型，即“访 问路径”。额外的有用的特征在于事先识别用于存储新生成的文档的路 径，即“保存路径”。但是，本领域的技术人员可以理解的是，用于保 存文档的路径可以在文档生成之后由用户指定。至少利用通往先前存 储的模型的预定访问路径、以及可选地利用用于保存新文档的预先指 定的保存路径来创建新文档的全部技术在本文中被称作“新方案”技 术。
本发明一般适于与标记语言一起使用，并且特别适于与标记语言 XML一起使用。虽然下面的说明是针对XML给出的，但是它并不是 要将本发明局限于XML，而仅是为了示意。
根据传统的用来定义XML脚本的BNF一样的脚本，根据本发明 的示例性实施方案的“新方案”源代码指令的一般结构如下：
new-scheme＝″new:″(″！？″|″！/？″)
在示例性协议中，“(模板文件路径)”组件定 义通往原始文档所在位置的路径，并且根据来自该路径的文档来创建 新文档或定位模板。所述路径可以是绝对路径或相对路径。绝对路径 直接定义原始文档或模板的位置。与先前对框架目录结构的描述一致， 相对路径首先通过将该XML编辑子系统创建的用户文档目录作为根 目录来定义参考文档或模板的位置，随后可以检查所述参考文档或模 板的位置以选择期望的文档或模板。为了说明但并非限制，在附随的 实施例中采用术语“userDoc”来识别XML编辑中所使用的根目录。
图19B示出了根据本发明的、用于检索可用作生成新文档的基础 的模板或旧文档的示例性过程。在步骤1901，通过鼠标、键盘等的操 作来发出命令，开始用于生成新文档的过程。一旦开始了该过程，那 么用户便在下一个步骤1902发出命令，以请求可用作新文档的根的来 源的可获得的模板或旧文档的列表。通常通过显示上的唯一名称来识 别模板或旧文档，并且所述名称是与旧文档或模板的被指定的路径相 关的。如说明的那样，文档将伴随有标签，但是标签并没有内容。在 步骤1903，用户可以选择与单个模板或旧文档相关的名称，在被指定 路径的基础上检索文档，并且为了便于用户回顾而优选显示文档。在 步骤1905，用户确定该文档或模板是否是最适合用户要求的想要的文 档或模板。如果不是(N)，则重复该过程；如果是(Y)，则将该文档 或模板用作增加新文本或修改旧文档内容的基础，如步骤1906所示。 在创建/编辑过程开始之后的任何时间，都可以在步骤1907保存文档。 如随后所讨论的那样，可以预先指定用于保存文档的位置，或者在保 存文档时由用户指定。
上述指令的“(新方案询问)”部分用于传递 与新方案活动相关的可选的信息。在非限定性实施例中，所述询问可 包括以下配置：
new-scheme-query＝*(query-key″＝[″query-value″]；″)
可以通过“query-key(询问关键字)”和“query-value(询问值)” 来传递附加信息。“query-key”伴有各自的“query-value”，而 “query-value”包含用于管理新文档的相关信息。如果新方案询问具 有出现一次以上的相同的关键字，则仅使用第一个值。
new-scheme-query特征的使用的非限定性实施例与可保存新文档 的位置的预先说明有关。特别地，询问关键字/询问值的组合可以用来 识别save-URL。询问关键字将提供新创建的文件的优选的保存位置。 询问值在这种情况下将是被指定为绝对路径或相对路径的URL。如果 指定相对路径，则将“userDoc”目录作为根目录来计算路径。
询问关键字的使用的另一实施例是将在“template-file-path”中指 定的文件的仅一部分用作模板。如随后所讨论的那样，在这种情况下， 询问值将成为在模板文件中定义的片段的名称。
如上所述，新的实例词汇的命名空间可以包括“new-fragment” 元素，以作为最外面的元素。根据本发明的示例性实施方案， “new-fragment”元素具有如下的属性配置：
name＝id
save-url＝url>
<！-Content:new-fragment-contents->

在前述的配置中，“name”属性是用来指定“new-fragment”的ID。 利用新方案服务的特征，可以将“name”作为检索术语，以检索用于 定义新文档的期望片段。“name”被唯一指派用来区分不同的片段， 其中每个片段在不同“标签”的基础上定义具有不同特征的XML文 档。
在新方案服务中，“save-url”属性具有与“save-url”询问相同的 功能。特别地，“save-url”属性指定用于保存新创建文档的优选的位 置。根据示例性的实施方案，如果既设定了用于新方案服务的 “save-url”询问又设定了用于新实例词汇的“save-url”属性，则使用 用于新方案服务的“save-url”询问。
XPath函数也可以与“save-url”属性一起使用。如前所述，XPath 函数用作访问DOM的路径，并且可通过监控作为相关信息(例如， 与通往DOM的访问路径相关的信息)的过滤器的变化事件而操作。 在使用“save-url”属性时，通过采用波形括号({})来表示路径，以 指定XPath函数。此外，如果使用XPath函数，那么“save-url”属性 将用作上下文节点。在“save-url”询问中登记的URL可以是来自于 其中包含“new-fragment”的文档的绝对路径或相对路径。
“new-fragment-contents(新片段内容)”中包含的元素是用来创 建新文档的片段。根据传统的W3C标准，这些片段中的每一个都在 XML中定义，并且还必须满足以下附加的标准：
a)新片段元素可以具有作为孩子元素的零个或多个处理指令子 句。
b)新片段元素必须具有一个孩子元素；并且该孩子元素不能大于 1或0。
c)新片段元素除了具有空白之外，不必具有任何文本。
换句话说，每个新片段元素都包含没有正文内容的完整的XML 文档。
当通过“new-scheme”服务来指定特殊的片段时，从新方案指定 的文件开始，对具有给定的name属性的片段执行检索。如果这种片 段(具有name属性)存在，那么被指定的“new-fragment”(新片段 内容)下方的元素将用来创建新文档。在创建新文档时，通过波形括 号({})来识别XPath函数并将对其进行评估，其中XPath函数指定 一个或多个xpath表达式，而xpath表达式用于确定源DOM树的子集， 并且需要监测将会影响目的DOM树的、源DOM树的子集的改变/修 改。例如，如果：
给定
<？org.chimaira vocabulary-connection href＝″{functionrdocument- uriθ}″？>
则计算
″{function:document-uri()}″
并且实现
<？org.chimaira                             vocabulary-connection href＝″file:///C:/Chimaira/doc/hoge/foo.vcd″？>
应当注意，出现在处理指令或属性内部的XPath函数将被评估， 但是XPath函数的其他部分不会被评估。用于这些XPath函数的上下 文节点是具有XPath函数的节点。
图19C说明了程序员创建片段和相关属性的过程。在步骤1951， 程序员将日记应用程序显示为词汇连接描述符文件，这一点与前面对 整个系统的描述一致。在随后的步骤1952，在VCD文件的基础上， 识别用于新文件的期望的标记语言文档模板。然后，在步骤1953，程 序员将输入至少一个新片段和附随的唯一的name属性，其中如上所 述，该name属性用于检索。系统然后将所述至少一个片段和属性存 储于具有适当根目录(例如，以userDoc作为根目录)和指定路径的 框架目录中的位置。
图20说明了根据本发明的(日语)日记应用程序2050。日记应 用程序2050是包含两个“new-fragment”的XML转换脚本(例如， VCD)文件。name属性“goodDay”2060和“badDay”2070分别分 配给所述两个片段。
图21说明了源代码2150。从图21中可以看出，阴暗部分2160 涉及新片段“goodDay”并包括“save-url”部分2161，“save-url”部 分2161将用于生成URL的函数指定为名称(“nikki-”)2162、日期 (“yyyy”)2163和url 2164的连接。在具有save-url部分2171的第二 个阴暗部分2170中，在用于“badDay”的源代码中出现了类似的配 置，并且在此无需重复与名称2172、日期2173和url 2174有关的细 节。值得注意的是，屏幕示出了在术语“nikki”上执行的“vcd: vocabulary”匹配2180，并且示出了将调用模板分配为来源于所选的 片段的新文档的“根”。
如图22所示，例如，一选定“goodDay”，便根据结合图9和图 14-18描述的过程而载入文档2250。图22中的文档2250是新创建的 文档。对save-url选项进行设置，以便将该文件保存为 “nikki-2004-05-17.xml”2260，并且对片段询问进行设置，以便在存 储的文档中使用具有名称“goodDay”的片段2270。该名称可稍后用 来检索和访问作为另一个具有相同标签的新文档的模板的文档。在 “save-url”目录地址中将存储位置2280指定为：
[file:c/eclipse/workspace/doc/samples/isc/mkki/nikki.vcd]
假定载入新文档2250，并且新文档2250具有根据所选的片段或 模板而指定的根，那么根据所公开的系统的基本范例，所述新文档的 建立将存在为源DOM和目的DOM。然后，当通过复制、经由键盘或 其他来源的输入而接收可以被解析成相关组件的数据流时，将通过增 加相连的节点来修改源DOM，并且如已经至少结合图3描述的那样， 该修改将被传送到目的DOM树。
前述的实施方案和优点仅是示例性的，并且不应当被解释成是对 本发明的限制。本发明的说明书是示意性的，而不是要限制权利要求 的范围。许多替换、修改和变换对于本领域的技术人员来说都将是显 而易见的。
相关申请
本申请要求于2004年8月2日提交的、题为“文档处理和管理系 统”的共同未决的第60/592,369号美国临时申请的优先权，该申请的 内容并入本文作为参考。