CN100472512C - 文档处理装置和方法 - Google Patents

Abstract

本发明公开了一种文档处理装置以及相应的文档处理方法，用以处理以例如XML语言的一种或多种标记语言描述的文档。所述文档处理装置包括：可操作以处理以第一标记语言描述的文档的文档处理器，所述文档处理器能够处理所述第一标记语言而不能处理第二标记语言；文档转换器，如果一文档以所述第二标记语言描述，则所述文档转换器可操作以将该文档映射为所述第一标记语言；以及定义文件，可操作以描述所述第一和第二标记语言之间的映射，其中，所述文档转换器可操作以通过参考所述定义文件，在所述第一和第二标记语言之间映射所述文档。

Description

文档处理装置和方法

技术领域

本发明涉及一种文档处理技术，尤其涉及处理以多种标记语言描述的文档的技术。

背景技术

互联网的出现导致由用户处理和管理的文档的数目近乎指数增长。形成互联网核心的万维网联合会(亦即通常所说的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文档的部分进行寻址的公共的语法和语义。Xpath的功能的一个示例是对与XML文档相对应的DOM树进行遍历。它提供了用于操作与XML文档的各种表述相关联的字符串、数字和布尔字符的基本工具。Xpath对XML文档的摘要、逻辑结构(例如，DOM树)、而不是其表面语法(例如，描述哪根线或哪个字符位于序列中的语法)进行操作。使用Xpath，能够在分级结构中(例如，在XML文档的DOM树中)进行定位。除了用于寻址的用途之外，Xpath还被设计用来测试DOM树中的节点是否与某个模式相匹配。

其它涉及Xpath的细节可在http://www.w3.org/TR/中找到。

假设XML的有益效果和特征已经公知，需要一种能够对标记语言(例如，XML)构建的文档进行处理的有效的文档处理和管理系统，并提供一种用于创建和修改这些文档的友好的用户界面。可扩展标记语言(XML)特别适合作为用于复合文档(compound document)的格式，或者特别适合用于这种情况的格式，即，某个文档的相关数据与其它文档的数据通过网络等共用的情况。已经开发出许多用于创建、显示和编辑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(所见即所得)对所实现的屏幕进行编辑。

本发明针对上述情况而提出，并相应提供用于能够有效地处理结构数据以及通过一种或多种例如XML类型的语言的标记语言描述文档的的装置、方法和计算机程序产品。

本发明的一些示意性实施方案涉及文档处理装置，例如，一种包括文档处理器的文档处理系统，其中，所述文档处理器可操作以处理以第一标记语言描述的文档，所述第一标记语言与所述文档处理器相符。如果一文档以与所述文档处理器不相符的第二标记语言描述，则文档转换器可操作以将该文档映射为所述第一标记语言。

本发明的另一个方面是一种文档处理方法，该方法可包括在待处理文档以处理系统不能处理的标记语言描述时，将该文档映射到可被处理系统处理的标记语言，并显示所映射成的文档。

本发明的另一个方面是这样的计算机程序产品，它包括包含有使计算机能实现上述技术的指令的计算机可读媒体。

在这里应该注意，上述的结构组件的任意组合，以及在方法、装置和系统等之间变化的表述都像在本发明的实施方案中一样有效。

根据本发明，能够提供用于有效地处理以一种或多种标记语言描述的文档的技术，以用于实现生成、编辑、显示和/或存储操作中的至少一种或多种。

附图说明

图1以方框图的方式示出了根据本发明的一个示例性而非限制性实施方案的文档处理装置；

图2示出了XML文档的一个实施例；

图3示出了将图2的XML文档映射为HTML描述的表的一个实施例；

图4示出了用以将图2的XML文档映射为图3的表的定义文件的一个实施例；

图5示出了当利用图3的对应关系将图2的XML文档映射为HML时显示屏的一个实施例；

图6示出了可与本发明一起使用的图形用户界面；

图7示出了根据本发明生成的屏幕布局(layout)的另一实施例；

图8示出了根据本发明的、用于XML文档的编辑屏幕；

图9示出了根据本发明编辑的XML文档的另一实施例；

图10示出了可与本发明一起使用的编辑屏幕；

图11(a)示出了能够作为所公开的文档处理和管理系统的一个示例性实现基础的组件的传统结构；

图11(b)和11(c)是示例性的文档处理和管理系统的总体方框图；

图12示出了文档管理器的示例性实现的进一步细节；

图13示出了词汇连接子系统300的示例性实现的进一步细节；

图14(a)示出了程序调用器的示例性实现及其与其它组件的关系的进一步细节；

图14(b)示出了服务代理(broker)的示例性实现及其与其它组件的关系的进一步细节；

图14(c)示出了服务的示例性实现的进一步细节；

图14(d)示出了服务的实施例；

图14(e)示出了程序调用器与用户应用程序之间的关系的进一步细节；

图15(a)提供了载入程序调用器上的应用程序服务的结构的进一步细节；

图15(b)示出了框架、菜单栏和状态栏之间的关系的实施例；

图16(a)示出了应用程序核心的示例性实现的进一步细节；

图16(b)示出了涉及快照(snap shot)的示例性实现的进一步细节；

图17(a)示出了涉及文档管理器的示例性实现的进一步细节；

图17(b)在右侧示出了一组文档A-E如何排列为分级结构的实施例，在左侧示出了右侧所示的文档的分级结构在屏幕上如何显示的实施例；

图18(a)和18(b)提供了撤消框架和撤消命令的示例性实现的进一步细节；

图19(a)示出了文档如何载入如图11(b)-(c)所示的文档处理和管理系统中的总体图；

图19(b)示出了使用MVC范例的区的结构的概要；

图20示出了根据本发明的文档及其多种表述的实施例；

图21(a)示出了如图20所示的文档的XHTML组件的MV关系的简化视图；

图21(b)示出了用于如图21(a)所示的文档的词汇连接；

图22(a)-22(c)示出了分别涉及插件子系统、词汇连接与连接器的示例性实现的进一步细节；

图23示出了用于文件MySampleXML的使用词汇连接管理器的VCD脚本和连接器工厂树的实施例；

图24(a)-(c)示出了将示例文档MySampleXML载入图11(b)的示例性文档处理和管理系统中的步骤0-3；

图25示出了将示例文档MySampleXML载入图11(b)的示例性文档处理和管理系统中的步骤4；

图26示出了将示例文档MySampleXML载入图11(b)的示例性文档处理和管理系统中的步骤5；

图27示出了将示例文档MySampleXML载入图11(b)的示例性文档处理和管理系统中的步骤6；

图28示出了将示例文档MySampleXML载入图11(b)的示例性文档处理和管理系统中的步骤7；

图29(a)示出了在不具有相应的源节点而仅依赖于目的树的节点上发生的事件流；

图29(b)示出了在通过TextOfConnector与源节点相关的目的树的节点上发生的事件流。

具体实施方式

图1示出了根据本发明的一个示例性而非限制性实施方案的文档处理装置20的结构。文档处理装置20对结构化的文档进行处理，该文档中的数据被分为具有分级结构的多个组件。该实施方案中表示的是一个实施例，其中，对作为一种结构化文档的XML文档进行处理。文档处理装置20由主控单元22、编辑单元24、DOM(文档对象模块)单元30、CSS(层叠样式表)单元40、HTML(超文本标记语言)单元50、SVG(可缩放矢量图形)单元60以及用作转换单元一个示例的VC(词汇连接)单元80。在硬件组件方面，这些单元结构可由任意的传统处理系统或设备(包括任意计算机的CPU或存储器、存储器载入的程序、硬连线芯片等)来实现。因此，如本领域技术人员能够理解的那样，本文以示例性结构的方式描绘和记述了功能模块，所述结构实现为或可实现为任意的上述处理系统。因此，本领域技术人员能够理解，这些功能模块可仅通过硬件的方式、仅通过软件的方式或通过二者相结合的方式以多种形式来实现。

主控单元22提供插件的载入或提供执行命令的框架。编辑单元24提供了用于编辑XML文档的框架。文档处理装置20中的文档的显示和编辑功能是通过插件来实现的，而必要的插件是根据所处理的文档类型、通过主控单元20或编辑单元24来载入的。主控单元22或编辑单元24通过参考待处理的文档的命名空间来确定哪个或哪些词汇描述了待处理的XML文档的内容，并且对应于所确定的词汇而载入用于显示和编辑的插件，从而执行显示和编辑。例如，利用控制单元52、编辑单元54和显示单元56对HTML文档进行显示和编辑的HTML单元50，以及利用控制单元62、编辑单元64和显示单元66对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以及DOM编写器36。DOM单元30实现了与文档对象模型(DOM)相符的功能，在XML文档作为数据被处理时，所述文档对象模型被定义以提供访问方法。DOM提供器32是满足由编辑单元24定义的接口的DOM的实现。DOM构造器34从XML文档生成DOM树。如以下将描述的那样，当通过VC单元80将待处理的XML文档映射为其它词汇时，生成与映射源中的XML文档相对应的源树以及与映射目的中的XML文档相对应的目的树。在编辑的末尾，例如DOM编写器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)”)、发送和接收包括编辑命令的事件的控制单元(本发明中也称作“editlet”)以及在接收到编辑命令时对DOM进行编辑的编辑单元(本发明中也称作“区(zone)”)。在控制单元从外部源接收到用于DOM树的编辑命令时，编辑单元修改DOM树，而显示单元更新显示。这些单元具有与被称作MVC(Model-View-Controllers，模型-视图-控制器)的框架相类似的结构，MVC是一种众所周知的图形用户界面(GUI)范例。所述MVC范例提供了一种将应用程序(或甚至是一个应用程序的接口)分解为三部分(即，模型、视图和控制器)的方法。最初开发MVC是为了将传统的输入、处理和输出任务映射到GUI领域。

输入->处理->输出

控制器->模型->视图

根据所述MVC范例，用户输入、外界建模、以及对用户的视觉反馈被分离，并通过模型(M)、视窗(V)以及控制器(C)对象来处理。控制器可操作以解释输入(例如用户的鼠标和键盘输入)，并将这些用户动作映射为发送至模型和/或视窗的命令，以实现适当的改变。模型可操作以管理一个或多个数据元素、响应对其状态的询问、并响应指令以改变状态。视窗可操作以管理显示的矩形区域，并负责通过图形和文本的组合将数据显现给用户。

通常，根据本文所公开的本发明的示例性实施方案，显示单元(V)对应于“视图”，控制单元(C)对应于“控制器”，而编辑单元和DOM实体(M)对应于“模型”。在图1-10所示的示例性实施方案的文档处理装置20中，不仅能够以树型视图显示格式来编辑XML文档，而且能够根据相应的词汇来完成编辑。例如，HTML单元50提供了用户界面，通过该用户界面能够以一种类似于word处理器的方法对HTML文档进行编辑，而SVG单元60提供了一种用户界面，通过该用户界面能够以一种类似于图像绘制工具的方法对SVG文档进行编辑。

VC单元80包括映射单元82、定义文件获取单元84以及定义文件生成单元86。通过将以某个词汇描述的文档映射为另一词汇，VC单元80提供了一种框架，以通过与被映射成的词汇相对应的显示和编辑插件来显示或编辑文档。在本实施方案中，该功能被称为词汇连接(VC)。在VC单元80中，定义文件获取单元84获取描述了映射定义的定义文件。在该实施方案中，定义文件为脚本文件。

以第一词汇描述的文档被表述为具有节点的源树。同样地，以第二词汇描述的文档被表述为具有节点的目的树。定义文件为各节点描述了源树与目的树的节点之间的连接。如W3C领域中所公知的那样，可根据元素值和/或属性值来定义DOM树中的节点。在该实施方案中，可规定各节点的元素值或属性值是否可以编辑。

此外，在该实施方案中，也可描述使用节点的元素值或属性值的运算表达式。这些功能将在稍后进行描述。映射单元82使得DOM构个造器34通过参考定义文件获取单元84已经获取的定义文件(脚本文件)来生成目的树，以使得映射单元82能够管理源树与目的树之间的对应关系。定义文件生成单元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文档用于管理与学生已获得的评分或分数(marks)相关的数据。作为XML文档的上部节点的组件“marks”包括：在“marks”下方为各个学生设置的多个组件“student”。组件“student”具有属性“name”，并包括作为子元素的学科“Japanese”、“Math”(数学)、“Science”以及“Social”(社会科学)。属性“name”存储学生的姓名。组件“Japanese”、“Math”、“Science”和“Social”存储分别为日语、数学、自然科学和社会科学的学科的测试成绩。例如，姓名为“A”的学生的分数是：日语为“90”、数学为“50”、自然科学为“75”以及社会科学为“60”。下文中，该文档中使用的词汇(标签集)被称作“分数管理词汇”。

由于根据本示例性实施方案的文档处理装置20不具有与分数管理词汇的显示和/或编辑相符或能够处理分数管理词汇的显示和/或编辑的插件，因此，将使用以上描述的VC单元80，以不使用源显示和树显示的其它显示方法来显示该文档。也就是说，通过准备定义文件，使得分数管理词汇可映射为已具有插件的另一词汇，例如HTML或SVG。下面将要进行的说明是在假设已经具备了定义文件的情况下进行的，不过对于用户本身用以创建定义文件所必需的用户界面将在后面描述。

图3示出了图2中所示的XML文档映射为以HTML描述的表的一个实施例。在图3所示的实施例中，以分数管理词汇描述的“student”节点与以HTML描述的表(“TABLE”节点)的行(“TR”节点)相关。各行的第一列与属性值“name”相对应，第二列与“Japanese”节点的元素值相对应，第三列与“Math”节点的元素值相对应，第四列与“Science”节点的元素值相对应，而第五列与“Social”节点的元素值相对应。因此，图2所示的XML文档能以HTML的列表格式来显示。此外，这些属性值和元素值被指定为能够编辑，以使得用户能够使用HTML单元50的编辑功能在显示屏上对这些值进行编辑。在第六列中，指定了用来计算日语、数学、自然科学以及社会科学的分数的加权平均的运算表达式，并显示每个学生的分数的平均值。以这种方式，通过在定义文件中指定运算表达式来完成更灵活的显示，从而提高用户在进行编辑时的便利性。在图3所示的实施例中，将对第六列的编辑指定为不允许，以使得不能单独对平均值本身进行编辑。因此，在映射定义中，能够指定可编辑或不能编辑，以避免用户可能的错误操作。

图4表示定义文件的一个实施例，以将图2所示的XML文档映射为图3所示的表。该定义文件通过被定义用于和定义文件一起使用的脚本语言来描述。在图4所示的实施例中，“add student”和“deletestudent”被定义为命令，并分别涉及将节点“student”插入源树中的操作以及将节点“student”从源树中删除的操作。模板描述了诸如“name”和“Japanese”的标题显示于表的第一行中，而节点“student”的内容显示于第二行及其随后的行中。在显示节点“student”内容的模板中，包含“text-of”的项表示允许进行编辑，而包含“value-of”的项表示不允许进行编辑。在这些显示了节点“student”内容的行中，在第六行中描述了运算表达式“(src：japanese+src：math+scr：science+scr：social)div4”。这意味着显示学生的分数的平均值。

图5示出了将图2所示的由分数管理词汇描述的XML文档利用图3所示的对应关系映射为HTML以使其显示在显示屏上时，显示屏的一个实施例。在表90各行中从左至右显示的是各学生的姓名，以及日语分数、数学分数、自然科学分数、社会科学分数及其平均值。用户能够在屏幕上对XML文档进行编辑。例如，当第二行第三列中的值变为“70”时，源树中与该节点相对应的元素值(亦即学生“B”的数学分数)变为“70”。此时，为了使目的树与源树一致，目的树的相应部分因此而改变，从而使得HTML单元50能够根据改变的目的树来对显示进行更新。因此，学生“B”的数学分数变为“70”，而平均值相应地变为“55”。

在图5所示的屏幕上，例如“add student”和“delete student”的命令被显示为菜单，如图4所示的定义文件中所定义的那样。当用户从这些命令中选择一个命令时，节点“student”增加至源树中或从源树中删除。以这种方式，利用根据本实施方案的文档处理装置20，不仅能够对分级结构下端中的组件的元素值进行编辑，而且能够对该分级结构进行编辑。具有上述树型结构的编辑功能能够以命令的形式显现给用户。此外，增加或删除表中的行的命令可例如与增加或删除节点“student”的操作相关。嵌入其它词汇中的命令可显现给用户。该表可用作输入模板，以使得对于新学生的分数数据能够以填空(fill-in-the-blank)的方式来增加。如上所述，在使用HTML单元50的显示/编辑功能的同时，以分数管理词汇描述的文档可通过VC功能来编辑。

图6示出了由定义文件生成单元86显现给用户的图形用户界面的一个实施例，以使用户能够生成定义文件。待映射的XML文档在屏幕的左侧区域91显示为树。被映射成的XML文档的屏幕布局显示在屏幕的右侧区域92中。该屏幕布局可通过HTML单元50来编辑，用户在屏幕的右侧区域92中确定并创建用于对文档进行显示的屏幕布局。例如，使用诸如鼠标等的指示设备将屏幕的左侧区域91中显示的XML文档的待映射的节点拖动并放置到屏幕的左侧区域91中的HTML屏幕布局中，以指定映射源处的节点与映射目的处的节点之间的连接。例如，当作为元素“student”的子元素的“math”被放置到HTML屏幕上的表90中第一行与第三行的交叉处时，第三列中的“math”节点与“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示出了显示结果。

在对文档进行编辑期间，可向用户显示编辑菜单。该菜单可对应于复合文档的待编辑部分。因此，当用户在显示媒介上移动光标(或者托架(carriage))时，待显示的菜单可根据光标的位置被切换。也就是说，当光标位于显示SVG文档的区域中时，显现给用户的菜单响应于SVG单元60或响应于由用于映射SVG文档的定义文件所定义的命令。当光标位于显示XHTML文档的区域中时，显现给用户的菜单响应于HTML单元50或响应于由用于映射XHTML文档的定义文件所定义的命令。因此，可根据编辑位置提供适当的用户界面。

如果在复合文档中不存在与词汇相符的适当插件或映射定义，则以该词汇描述的部分可以源或树格式显示。在传统实践中，当要打开在某个文档中嵌有其它文档的复合文档时，如果没有安装能够显示该嵌入文档的应用程序，则它们的内容不能显示。但是，根据本实施方案，由文本数据组成的XML文档可显示为源或树格式，从而能够确定其内容。这是基于文本的XML文档或类似文档的一个特征。

以基于文本的语言来描述的数据的另一个有益方面例如在于，在同一文档中以其它词汇描述的部分的数据可被该复合文档中以某个词汇描述的另一文档所参考。此外，当在该文档中进行搜索时，嵌入图片(例如SVG)中的字符串也可作为被搜索的候选者。

在以某个词汇描述的文档中，可使用属于其它词汇的标签。虽然该XML文档通常并不有效，但只要它结构良好(well-formed)，就可作为有效的XML文档而被处理。在这种情况下，被插入的属于其它词汇的标签可使用定义文件来进行映射。例如，可使用诸如“Important”和“MostImportant”的标签以通过强调的方式来显示这些标签周围的部分，或者可将这些标签以重要性的顺序来排序以进行相应显示。

当用户在编辑显示器(例如，如图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的功能结构将在下面详细描述。

文档处理和管理系统的一个示例性实现将在本文中参照图11-29进行讨论。

图11(a)示出了能够作为具有本文随后描述的类型的文档处理和管理系统的基础的组件的传统装置。装置10包括具有CPU形式或微处理器形式的处理器11，处理器11通过通信路径13(通常实现为总线)耦合至可为任何当前或将来能获得的ROM和/或RAM存储形式的存储器12。用户输入14(例如鼠标、键盘、语音识别系统或类似设备)的I/O接口16以及显示设备15(或其它用户接口)也耦合至总线用于与处理器11和存储器12通信。如本领域所公知的那样，诸如打印机、通信调制解调器等的其它设备可耦合至该装置。该装置可为独立设备或者具有将多个终端以及一个或多个服务器耦合在一起的联网形式，或者以本领域公知的多种设置方式的其中之一。本发明并不受这些组件的结构、它们的集中式或分布式体系结构或者多种组件的通信方式的限制。

另外，应该注意到，本文所讨论的系统和示例性实现包括几种具有多种功能的组件和子组件。应该注意到，这些组件和子组件可仅使用硬件、仅使用软件以及使用硬件和软件的组合来实现，以提供上述的多种功能。另外，硬件、软件及其组合可使用通用计算装置或使用专用硬件或使用通用计算装置和专用硬件的组合来实现。因此，组件或子组件的结构包括运行特定软件的通用/专用计算装置，以提供该组件或子组件的功能。

图11(b)示出了一种示例性文档处理和管理系统的总体方框图。文档在上述文档处理和管理系统中被创建和编辑。这些文档能够以具有标记语言的特征的任何语言来表述(例如XML)。同样，为方便起见，已经创建了用于特定组件和子组件的术语和名称。但是，这些不应被视作对本文公开的一般教导范围造成了限制。

所述文档处理和管理系统可被视为具有两个基本组件。一个组件是“执行环境”101，它是处理和管理系统运行的环境。例如，执行环境提供了协助系统以及用户对文档进行处理和管理的基本效用和功能。另一组件是“应用程序组件”102，它由在执行环境中运行的应用程序构成。这些应用程序包括文档本身及其各种表述。

1.执行环境

执行环境101的关键组件是程序调用器103。程序调用器103是被访问以启动文档处理和管理系统的基本程序。例如，当用户登录并启动文档处理和管理系统时，程序调用器103被执行。程序调用器103能够(例如但并非限制)读取并处理作为插件增加至文档处理和管理系统的功能、启动并运行应用程序、以及读取与文档相关的性质。当用户希望发起计划在执行环境中运行的应用程序时，程序调用器103找到、发起然后执行该应用程序。例如，当用户希望对已经载入到系统中的文档进行编辑(它是执行环境中的一种应用程序)时，程序调用器103首先找到该文档，然后执行用于载入和编辑该文档所必需的功能。

程序调用器103联接至几个组件，例如插件子系统104、命令子系统105以及资源模块109。这些组件将随后进行更详细描述。

1.a.插件子系统

插件子系统104是向文档处理和管理系统增加功能的一种高度灵活和有效的设备。插件子系统104也能够被用来修改和去除文档处理和管理系统中存在的功能。此外，可使用插件子系统增加或修改多种功能。例如，如之前所提以及随后将详细描述的那样，插件子系统可用于增加功能“editlet”，其可操作以有助于在屏幕上呈现文档。插件editlet也有助于对增加至系统的词汇进行编辑。

插件子系统104包括服务代理1041。服务代理1041管理增加至文档处理和管理系统的插件，从而代理已增加至文档处理和管理系统的服务。

代表期望功能的单个功能以“服务”1042的形式被增加至系统。服务1042的可用类型包括但不限于：应用程序服务、区工厂服务、editlet服务、命令工厂服务、连接xpath服务、CSS计算服务等。这些服务及其与系统其余部分的关系将随后详细描述，以更好地理解文档处理和管理系统。

插件和服务之间的关系是，插件是可包括一个或多个服务提供器的单元，各个服务提供器具有与之相关的一个或多个类别的服务。例如，使用具有适当软件应用程序的单个插件，能将一个或多个服务增加至系统，从而向系统增加相应的功能。即使对于给定服务(例如editlet服务)，也可在各自的插件中提供处理单个或多个词汇的能力。

1.b.命令子系统

命令子系统105被用来执行与文档的处理相关的命令形式的指令。用户可通过执行一系列指令而执行对文档的操作。例如，通过发出命令形式的指令，用户在文档管理系统中处理XML文档，并编辑与该XML文档相对应的XML DOM树。这些命令可利用键盘敲打、鼠标点击或其它有效的用户接口动作而输入。有时，能够通过命令来执行一个以上的指令。在这种情况下，这些指令被封装成单个命令并连续执行。例如，用户可能希望将错误词语替换为正确词语。在这种情况下，第一指令可用以在文档中找寻错误词语。第二指令可用以删除该错误词语。第三指令可用以输入正确词语。这三个指令可被封装成单个命令。

在某些示例中，命令可具有相关功能，例如，下面将要详细讨论的“撤消”功能。这些功能可随后分配给用来创建对象的基类。

命令子系统105的一个组件是命令调用器1051，命令调用器1051可操作为选择性地提供并执行命令。虽然图11(b)中仅示出了一个命令调用器，但也可使用一个以上的命令调用器并同时执行一个以上的命令。命令调用器1051维护执行命令所需的功能和类。在操作中，要执行的命令1052被置于队列1053中。命令调用器创建连续执行的命令线程。如果在命令调用器中没有正在执行的命令，则由命令调用器1051执行待执行的命令1052。如果命令调用器正在执行命令，则新的命令被置于命令队列1053的末尾。不过，对于各命令调用器1051而言，一次仅执行一个命令。如果指定的命令执行失败，则命令调用器1051执行命令异常。

可由命令调用器1051执行的命令的类型包括但不限于：可撤消命令1054、异步命令1055以及词汇连接命令1056。可撤消命令1054是那些如果用户希望就能够回退其效果的命令。可撤消命令的示例为：剪切、复制、插入文本等。在操作中，当用户突出文档的一部分并向该部分应用剪切命令时，如果需要，通过使用可撤消命令，可使得被剪切的部分“恢复原样(uncut)”。

词汇连接命令1056被载入词汇连接描述符脚本文件中。词汇连接命令1056是能够由程序员定义的用户指定命令。这些命令可以是更抽象命令的组合，例如，用于增加XML片段、删除XML片段、设置属性等。这些命令特别涉及对文档进行编辑。

异步命令1055是用于载入或保存由系统执行的文档的命令，异步命令1055与可撤消命令或VC命令异步地执行。与可撤消命令不同，异步命令不能取消。

1.c.资源

资源109是向不同的类提供某些功能的对象。例如，串资源、图标和设定键绑定是系统中使用的资源。

2.应用程序组件

应用程序组件102，即文档处理系统的第二个主要特征，在执行环境101中运行。概括而言，应用程序组件102包括实际文档，实际文档包括其在系统内的多个逻辑和物理表述。应用程序组件102还包括系统的、用来管理文档的组件。应用程序组件102进一步包括用户应用程序106、应用程序核心108、用户界面107以及核心组件110。

2.a.用户应用程序

用户应用程序106连同程序调用器103一起被载入到系统中。用户应用程序106是将文档、文档的多种表述以及与文档进行交互所需的用户界面特征结合在一起的粘合剂(glue)。例如，用户可能希望创建作为工程(project)一部分的一套文档。载入这些文档，创建用于文档的适当表述，增加作为用户应用程序106一部分的用户界面功能。换言之，用户应用程序106将文档及其表述的各个方面结合在一起使得用户能够与形成工程一部分的文档进行交互。一旦创建了用户应用程序106，每当用户希望与形成工程一部分的文档进行交互时，用户就能够简单地将用户应用程序106载入到执行环境中。

2.b.核心组件

核心组件110提供了在多个窗格之间共享文档的一种方法。如将在随后详细讨论的那样，窗格表述DOM树，并处理屏幕的物理布局。例如，物理屏幕包括在屏幕内的多个窗格用于描述各条信息。实际上，由用户在屏幕上查看的文档可在一个或多个窗格中显示。此外，两个不同的文档可以出现在屏幕上的两个不同窗格中。

屏幕的物理布局还可以具有树型形式，如图11(c)所示。因此，如果组件1083要作为窗格显示在屏幕上，则该窗格可被实现为根窗格1084。作为一种选择，它也可以是子窗格1085。根窗格1084是窗格树根部的窗格，而子窗格1085是除了根窗格1084之外的任何窗格。

核心组件110也提供字体，并充当用于文档的多个功能性操作的源，例如，工具包(toolkit)。由核心组件110执行的任务的一个示例是在多个窗格之间移动鼠标光标。被执行的任务的另一个示例是标记一个窗格中的文档的一部分，并将其复制到包含不同文档的另一窗格上。

2.c.应用程序核心

如上所述，应用程序组件102由被系统处理和管理的文档组成。应用程序组件102包括对于系统内的文档的多种逻辑和物理表述。应用程序核心108是应用程序组件102的组件。其功能是保持实际文档及其内的所有数据。应用程序核心108包括文档管理器1081和文档1082本身。

文档管理器1081的多个方面将在随后更详细描述。文档管理器1081管理文档1082。文档管理器1081也连接至根窗格1084、子窗格1085、剪贴板实用程序1086以及快照实用程序1087。剪贴板实用程序1086提供了保持用户决定增加至剪贴板的部分文档的一种方法。例如，用户可能希望剪切文档的一部分，并将其保存到新的文档上，用于稍后查看。在这种情况下，剪切的部分被增加至剪贴板1086。

快照(snapshot)实用程序1087也将在稍后描述，从而当应用程序从一个状态变为另一状态时，能够记住应用程序的当前状态。

2.d.用户界面

应用程序102的另一组件是用户界面107，其为用户提供一种与系统进行物理交互的方式。例如，以物理接口1070来实现用户界面时，用户使用用户界面上载、删除、编辑和管理文档。用户界面107包括框架1071、菜单栏1072、状态栏1073以及URL栏1074。

如通常公知的那样，框架可被视为显示(例如物理屏幕)的活动区域。菜单栏1072是屏幕的、包括为用户提供选项的菜单的区域。状态栏1073是屏幕的、显示应用程序的执行状态的区域。URL栏1074提供了输入用于在互联网上定位的URL地址的区域。

3.文档管理器和相关的数据结构

图12示出了文档管理器1081的进一步细节。图12包括被用来在文档处理和管理系统内表述文档的数据结构和组件。为了更好的理解，在这部分描述的组件通过利用模型-视图-控制器(MVC)表述范例来进行描述。

文档管理器1081包括文档容器(containter)203，文档容器203保持并容纳文档处理和管理系统中的所有文档。联接至文档管理器1081的工具包201为文档管理器1081的使用提供了各种工具。例如，“DOM服务”是由工具包201提供的能够提供创建、维护和管理与文档相对应的DOM所需的所有功能的工具。作为工具包201提供的另一工具的“IO管理器”分别管理向系统的输入和来自系统的输出。同样地，“流处理器”是一种以比特流方式来处理文档上载的工具。这些工具形成了工具包201的组件，不过并未在图中明确示出或指定附图标记。

根据MVC范例表述，模型(M)包括文档的DOM树模型202。如上所述，所有文档均在文档处理和管理系统中被表述为DOM树。文档也形成文档容器203的一部分。

3.a.DOM模型和区

表述文档的DOM树是具有节点2021的树。作为DOM树的子集的区209包括该DOM树内部的一个或多个所关注的节点。例如，仅文档的一部分可在屏幕上显现。文档可见的这一部分可使用“区”209来表述。利用被称作“区工厂”205的插件来创建、操作和处理区。虽然区表述DOM的一部分，但它也可使用一个以上的“命名空间”。如本领域中公知的那样，命名空间是名称的汇集或集合，这些名称在该命名空间中是唯一。换言之，一个命名空间中不能够出现两个相同的名称。

3.b.“方面”(facet)及其与区的关系

“方面”2022是MVC范例的模型(M)部分内的另一组件。它被用来编辑区中的节点。“方面”2022使用不会影响区本身的内容的执行过程来组织对于DOM的访问。如以下将说明的那样，这些过程执行与节点相关的有意义且有用的操作。

各个节点2021具有相应的2022。通过利用“方面”来执行操作而不是直接对DOM中的节点进行操作，DOM的完整性得以确保。否则，如果直接对节点执行操作，那么几个插件可能同时对DOM进行改变，从而造成不一致性。

尽管在每个词汇或每个节点的基础上提供了特定操作，并且这些操作优选地提供为API，但是由W3C构建的DOM标准定义了用于对节点进行操作的标准接口。文档处理/管理系统提供了这种作为“方面”的节点特定API，并将“方面”联接至各个节点。这符合DOM标准，同时增加了有用的API。通过在已应用的标准DOM之上增加特定的API而不是为每个词汇实现特定的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中的一个或多个节点相对应的“方面”2022。这些服务并不直接操作区和DOM中的节点。“方面”是利用来自MVC范例的(C)组件(即控制器)的命令207来操作的。

用户通常通过例如移动屏幕上的光标和/或键入命令而与屏幕进行交互。提供屏幕的逻辑布局的画布2010接收这些光标操作。然后，画布2010使得对“方面”采取相应的动作。给定这一关系，光标子系统204即作为用于文档管理器1081的MVC范例的控制器(C)。

画布2010也具有处理事件的任务。例如，画布2010处理诸如鼠标点击、焦点移动和类似的用户发起的动作等事件。

3.c.区、“方面”、画布和窗格之间的关系概述

文档管理和处理系统内的文档可从至少四个角度来观察，即：1)用来保持文档管理系统中的文档的内容和结构的数据结构；2)不会影响文档完整性就能编辑文档内容的方式；3)文档在屏幕上的逻辑布局；以及4)文档在屏幕上的物理布局。区、“方面”、画布和窗格分别表述与上述四个方面相对应的文档管理系统的组件。

3.d.撤消系统

如上所述，人们希望对文档的任何改变(例如，编辑)应该是可撤消的。例如，用户可执行编辑操作，然后决定撤消该改变。参照图12，撤消子系统212是文档管理器的可撤消组件。撤消管理器2121保存可能被用户撤消的、对文档执行的所有操作。

例如，用户可执行命令来将文档中的词汇替换成另一个词语。之后，该用户可改变主意并决定保留原来的词语。撤消子系统212利用可撤消编辑2122来协助上述操作。撤消管理器2121保存上述可撤消编辑2122的操作。该操作可扩展为超越单个XML操作类型，因此可能涉及文档中多种语言(例如XHTML、SVG以及MathML)的变化特征，然后撤消对这些语言中每一个的改变。因此，在先进后出的操作中，不论词汇使用与否，最近的改变首先被取消，然后，下一个最近的改变被取消。因此，即使两个或更多editlet被编辑，但仍可依照正确顺序执行联合撤消，从而提供正常和合乎逻辑的操作。

3.e.光标子系统

如上所述，MVC的控制器部分可包括光标子系统204。该光标子系统204从用户处接收输入。这些输入通常具有命令和/或编辑操作的性质。因此，光标子系统204可被视作是与文档管理器1081相关的MVC范例的控制器(C)部分。

3.f.视图

如上所述，画布2010表述要显现在屏幕上的文档的逻辑布局。对于XHTML文档的特定实施例而言，画布可包括盒树(box tree)208，盒树208是文档在屏幕上如何被查看的逻辑表述。上述盒树208可包含在与文档管理器1081有关的MVC范例的视图(V)部分中。

4.词汇连接

文档处理管理系统的一个重要特征是，能够以两种不同的方式(例如，以两种标记语言)来表述和显示文档，从而使得两种不同的表述自动保持一致。

标记语言文档(例如XML文档)基于通过文档类型定义限定的词汇创建。词汇则是一组标签集，并可以任意定义，这就使得词汇的数量可能是无限的。但是，为多个可能的词汇中的每一个都提供专用的单独处理和管理环境是不切实际的。词汇连接是解决这种问题的一种方式。

例如，文档可以利用两种或更多标记语言来表述。这些文档例如可以是XHTML(可扩展超文本标记语言)、SVG(可缩放矢量图形)、MathML(数学标记语言)或其他的标记语言。换句话说，标记语言可以视为和XML中的词汇和标签集相同。

词汇可以使用词汇插件来实现。在文档处理和管理系统中，以插件不可用的词汇所描述的文档可以通过将该文档映射为插件可用的另一词汇来显示。因此，以非插件的词汇描述的文档仍然是可以正确显示的。

词汇连接包括获取定义文件、在(随后定义出的)定义文件之间进行映射、以及生成定义文件的能力。用某种词汇描述的文档能够映射为另外的词汇。因此，词汇连接提供了通过与文档已被映射成的词汇相对应的显示和编辑插件来显示或编辑文档的能力。

应该认识到，各个文档在文档处理和管理系统中被描述为通常具有多个节点的DOM树。“定义文件”为各个节点描述了该节点与其他节点之间的连接。规定了是否可以对各个节点的元素值和属性值进行编辑。还描述了使用节点的元素值和属性值的运算表达式。

利用映射特征，通过参考定义文件创建目的DOM树。因此，源DOM树和目的DOM树之间的关系被建立并维护。词汇连接监控源DOM树和目的DOM树之间的连接。在从用户接收到编辑指令后，词汇连接修改源DOM树中的相关节点。如上所述，发出表示已经修改了源DOM树的“变化事件”，并且相应地修改目的DOM树。

通过使用词汇连接，仅对于少量用户熟知的相对次要的词汇可以被转换为其他主要的词汇。因此，即便是对于那些仅有少量用户使用的次要词汇，也可以准确地显示文档，并提供理想的编辑环境。

因此，作为文档管理系统一部分的词汇连接子系统提供了能够对文档进行多种表述的功能。

图13显示了词汇连接(VC)子系统300。VC子系统300提供了一种维护同一文档的两种可替换表述之间的一致性的方式。在图中具有与上面描述和标识相同的组件，这些组件相互连接从而实现上述目的。例如，两种表述可以是同一文档以两种不同词汇实现的可替换表述。如上所述，其中一种可以是源DOM树，而另一种是目DOM树。

4.a.词汇连接子系统

利用被称为“词汇连接”301的插件在文档处理和管理系统中实现词汇连接子系统300的功能。将被表述的文档的各词汇305都需要相应的插件。例如，如果文档的一部分以HTML表述，而其他部分以SVG表述，则需要相应的HTML词汇插件和SVG词汇插件。

词汇连接插件301为区209或窗格211创建与适当词汇305的文档相对应的适当的词汇连接画布310。使用词汇连接301，利用转换规则，对源DOM树的区209的改变被转换到另一DOM树306的相应区。转换规则以词汇连接描述符(VCD)的形式给出。对于与源和目的DOM之间的这种转换相对应的各个VCD文件，创建相应的词汇连接管理器302。

4.b.连接器

连接器304连接源DOM树中的源节点和目的DOM树中的目的节点。连接器304可操作以观察源DOM树中的源节点，和与该源节点相对应的、对源文档的修改(变化)。接着，连接器304修改相应的目的DOM树中的节点。只有连接器304是能够修改目的DOM树的对象。例如，如果用户仅能够对源文档和相应的源DOM树进行修改，则连接器304对目的DOM树进行相应的修改。

连接器304被逻辑地链接在一起以形成树结构，如图13所示。连接器304形成的树被称为“连接器树”。连接器304通过一种服务而创建，该服务被称为“连接器工厂”303服务。连接器工厂303从源文档创建连接器304，并将连接器304以连接器树的形式链接起来。词汇连接管理器302维护连接器工厂303。

如上所述，词汇是命名空间中的标签集。如图13所示，通过词汇连接301为文档创建词汇305。这通过分析文档文件以及为源DOM和目的DOM之间的转换创建适当的词汇连接管理器302来实现。此外，在创建连接器的连接器工厂303、创建区209的区工厂服务205和创建与区中的节点相对应的画布的editlet服务206之间建立适当的关联。当用户从系统中除去或删除文档时，对应的词汇连接管理器302被删除。

词汇305接着创建词汇连接画布310。此外，连接器304和目的DOM树306被相应地创建。

应该理解，源DOM和画布分别对应于模型(M)和视图(V)。然而，仅当目标词汇能够在屏幕上呈现时，这种呈现才有意义。这种显示通过词汇插件来实现。词汇插件提供用于主要的词汇，例如XHTML、SVG和MathML。词汇插件相对于目标词汇使用。它们提供了一种使用词汇连接描述符在词汇之间进行映射的方式。

仅在目标词汇可被映射并具有预定的屏幕呈现方式时，这种映射才有意义。这种呈现方式为工业标准，例如由诸如W3C组织定义的XHTML。

在需要词汇连接时，使用词汇连接画布。在这种情况下，由于不能够为源直接创建视图，因此，不创建源画布。在这种情况下，使用连接器树来创建词汇连接画布。这种词汇连接画布仅仅处理事件转换，而并不会有助于将文档呈现在屏幕上。

4.c.目的区、窗格以及画布

如上所述，词汇连接子系统的目的在于创建并同时维护对同一文档的两种替换表述。第二替换表述还可以是先前被引入作为目的DOM树的DOM树形式。为了浏览第二种表述的文档，需要目的区、画布和窗格。

在创建词汇连接画布后，创建相应的目的窗格307，如图13所示。此外，相关的目的画布308和相应的盒树309被创建。同样，词汇连接画布还与源文档的窗格211和区209关联。

目的画布308提供了文档的第二种表述方式的逻辑布局。具体地，目的画布308提供了用户界面功能，例如光标和选择(selection)，用于以目的表述的方式呈现文档。在目的画布308中发生的事件被提供到连接器。目的画布308向连接器304通知鼠标事件、键盘事件、拖动和放置事件、以及通知文档的目的(或第二种)表述的词汇的特有事件。

4.d.词汇连接命令子系统

图13中的词汇连接子系统300的一部分是词汇连接命令子系统313。词汇连接命令子系统313创建词汇连接命令315，词汇连接命令315用来执行与词汇连接子系统300相关的指令。可通过内建的命令模板3131来创建词汇连接命令，和/或可通过在脚本系统314中使用脚本语言从无到有地创建命令而创建词汇连接命令。

命令模板的例子包括“If”命令模板、“When”命令模板、“Insertfragment”命令模板等。这些模板被用来创建词汇连接命令。

4.e.Xpath子系统

Xpath子系统316是文档处理和管理系统的一个重要组件，因为它能够有助于实现词汇连接。连接器304通常包括xpath信息。如上所述，词汇连接的任务是将源DOM树中的变化反映到目的DOM树中。xpath信息包括一个或多个用来确定源DOM树中需要被观察以确定改变/修改的子集的xpath表达式。

4.f.源DOM树、目的DOM树和连接器树的概述

源DOM树是对转换为另一种词汇之前以一种词汇表述的文档进行表述的DOM树或区。在源DOM树中的节点被称为源节点。

另一方面，目的DOM树则表示用于在利用映射进行转换之后以另一种词汇表述的同一文档的DOM树或区，该映射已在前面结合词汇连接描述。目的DOM树中的节点被称为目的节点。

连接器树是基于连接器的分级表述，用来表述源节点和目的节点之间的连接。连接器观察源节点和对源文档进行的修改。连接器随后修改目的DOM树。事实上，只有连接器是能够修改目的DOM树的对象。

5.文档处理和管理系统中的事件流

为了能够使用，程序必需对来自用户的命令进行响应。事件是一种描述和执行用户对程序实施的动作的方式。许多高级语言例如JAVA依靠描述用户动作的事件。在现有技术中，程序不得不主动收集用于理解用户动作和通过自身执行用户动作的信息。这可能意味着，例如，在对程序初始化后，程序进入重复地查看用户是否对屏幕、键盘和鼠标等执行了任何动作、并接着采取适当动作的循环。然而，这种处理可能难以操控。此外，这种处理在等候用户作某些事情时，还需要执行循环的程序，从而消耗了CPU周期。

许多语言通过包含不同的范例来解决这些问题，其中的一个范例构成了所有现代的window系统的基础：事件驱动程序。在这种范例中，所有的用户动作属于被称为“事件”的事务的抽象集合。一种事件足够详细地描述了特殊的用户动作。在感兴趣的事件发生时，这种系统通知程序，而不是程序主动地收集用户生成的事件。以这种方式处理用户交互的程序被称为“事件驱动”。

这通常使用事件类来进行处理，其中事件类捕获了所有用户生成事件的基础特性。

文档处理和管理系统定义和使用其自身的事件以及处理这些事件的方式。几种类型的事件被使用。例如，鼠标事件是来自用户的鼠标动作的事件。与鼠标有关的用户动作由画布210传递到鼠标事件。因此，画布可以被认为是用户与系统交互的最前沿。如果需要，最前沿的画布将把其与事件有关的内容传递到其下级(children)。

另一方面，按键事件从画布210产生。按键事件具有瞬时的焦点，即，按键事件涉及任意瞬时的活动。进入到画布210的按键事件接着被传递到其上级(parent)。键盘输入通过能够处理字符串插入的不同事件而被处理。在使用键盘插入字符时，将触发处理字符串插入的事件。其他的“事件”包括例如拖动事件、放置事件和其他能够以与鼠标事件相似的方式处理的事件。

5.a.在词汇连接之外处理事件

使用事件线程对事件进行传递。在接收到事件后，画布210改变其状态。如果需要，画布210将命令1052记入到命令队列1053。

5.b.在词汇连接之内处理事件

通过使用词汇连接插件301，目的画布1106接收现有的事件，例如鼠标事件、键盘事件、拖动和放置事件、以及词汇的特有事件。这些事件接着被通知到连接器1104。更具体地说，词汇连接插件301内的事件流经过源窗格1103、词汇画布1104、目的窗格1105、目的画布1106、目的DOM树和连接器树1104，如图21所示。

6.程序调用器及其与其他组件之间的关系。

在图14(a)中更加详细地显示了程序调用器103及其与其他组件之间的关系。程序调用器103是在执行环境中被执行以启动文档处理和管理系统的基本程序。用户应用程序106、服务代理104、命令调用器1051和资源109都被联接到程序调用器103，如图14(b)所示。如前所述，应用程序102是在执行环境中运行的组件。同样，服务代理104管理向系统增加各种功能的插件。另一方面，命令调用器1051维护用来执行命令的类和函数，从而执行用户提供的指令。

6.a.插件和服务

下面将参照图14(b)详细描述服务代理104。如上所述，服务代理104管理向系统增加各种功能的插件(及相关服务)。服务1041在最底层，在该层中可以将特征增加到文档处理和管理系统，或改变该系统中的特征。“服务”由两部分构成：服务种类401和服务提供器402。如图14(c)所示，单个的服务种类401可具有多个相关的服务提供器402，这些多个服务提供器402中的每一个都可操作以执行所有或部分的特定服务种类。另一方面，服务种类401则定义了服务的类型。

服务可分为三种类型：1)向系统提供特定特征的特征服务；2)应用程序服务，其是由文档处理和管理系统运行的应用程序；以及3)提供在整个文档处理和管理系统中需要的特征的环境服务。

图14(d)中示出了服务的例子。根据应用程序服务的种类，系统实用程序是相应服务提供器的示例。同样，editlet206是一个种类，HTMLeditlet和SVG editlet是相应的服务提供器。区工厂205是服务的另一种，并具有相应的服务提供器(未示出)。

之前描述的向文档处理和管理系统增加功能的插件可以看作是由几个服务提供器402和与其相关的类构成的单元，如图14(c)和14(d)所示。各个插件都应该具有在清单文件(manifest file)中写入的从属和服务种类。

6.b.程序调用器和应用程序之间的关系

图14(e)详细显示了程序调用器103和用户应用程序106之间的关系。所需的文档、数据等从存储中载入。所有需要的插件载入到服务代理104。服务代理104管理并维护所有的插件。可物理地将插件增加到系统，或者可从存储中载入其功能。在载入插件的内容后，服务代理104定义相应的插件。相应的用户应用程序106被创建，接着被载入到执行环境101并联接到程序调用器103。

7.应用程序服务和环境之间的关系

图15(a)进一步示出了载入程序调用器103中的应用程序服务的结构。作为命令子系统105组件的命令调用器1051调用或执行程序调用器103内的命令1052。命令1052则是用来在文档处理和管理系统中处理文档(例如，XML文档)和编辑相应的XML DOM树的指令。命令调用器1051维护执行命令1052所需的功能和类。

服务调用器1041也在程序调用器103中执行。用户应用程序106连接到用户界面107和核心组件110。核心组件110提供了一种在所有的窗格中共享文档的方式。核心组件110还提供字体并作为用于窗格的工具包。

图15(a)和(b)显示了框架1071、菜单栏1072和状态栏1073之间的关系。

8.应用程序核心

图16(a)进一步解释了应用程序核心110，其保持所有文档以及作为文档一部分并属于文档的数据。核心组件110联接到管理文档1082的文档管理器1081。文档管理器1081是存储到与文档处理和管理系统关联的存储器中的所有文档1082的所有者(proprietor)。

为了便于在屏幕上显示文档，文档管理器1081还连接到根窗格1084。剪贴板1085、快照1087、拖拉和放置601，覆盖602的功能也被联接到核心组件。

如图16(b)所示，快照1087用来撤消应用程序状态。在用户调用快照功能1087时，应用程序的当前状态被检测并存储。所存储的状态的内容在应用程序改变为另一状态时被保存下来。在图16(b)中示出了快照。在操作中，当应用程序从一个URL移动到另一个时，快照会记住先前的状态，从而能够无缝地执行后退和前进操作。

9.在文档管理器中组织文档

图17(a)更加详细地描述了文档管理器1081以及如何在文档管理器中组织并保存文档。如图17(b)所示，文档管理器1081管理文档1082。在图17(a)显示的实施例中，多个文档中的一个为根文档701，其他的文档为子文档702。文档管理器1081连接到根文档701，根文档701则连接到所有的子文档702。

如图12和17(a)所示，文档管理器1081耦合到文档容器203，文档容器203是容纳所有文档1082的对象。形成工具包(例如，XML工具包)201的一部分的工具(包括DOM服务703和IO管理器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创建撤消管理器706和撤消封装器(wrapper)707。撤消管理器706和撤消封装器707用来执行可撤消的命令。使用该特征，可以撤消使用编辑操作对文档所作的改变。子文档中的改变也会涉及到根文档。撤消操作考虑到了影响分级结构内其他文档的改变，并确保了在分级结构链中的所有文档之间所维护的一致性，例如，如图17(b)所示。

撤消封装器707将与容器203中的子文档相关的撤消对象进行封装，并将它们和与根文档相关的撤消对象耦合。撤消封装器707使得可撤消编辑接收器709能够收集撤消对象。

撤消管理器706和撤消封装器707连接到可撤消编辑接收器708和可撤消编辑源708。本领域技术人员应该理解，文档705可以是可撤消编辑源708，并因此可以是可撤消编辑对象。

10.撤消命令和撤消框架

图18(a)和(b)进一步详细地显示了撤消框架和撤消命令。如图18(a)所示，撤消命令801、重做命令802和可撤消编辑命令803是能够排列在命令调用器1051中的命令(如图11(b)所示)并且被相应地执行。可撤消编辑命令803还进一步联接到可撤消编辑源708和可撤消编辑接收器709。例如，可撤消编辑命令是“foo”编辑命令803和“bar”编辑命令804。

图18(b)显示了可撤消编辑命令的执行。首先，假设用户使用编辑命令来编辑文档705。在第一步骤S1，可撤消编辑接收器709被联接到可撤消编辑源708，而可撤消编辑源708为文档705的DOM树。在第二步骤S2，基于由用户发出的命令，使用DOM API对文档705进行编辑。在第三步骤S3，向变化事件监听器通知已经发生了改变。即，在该步骤，监控DOM树中所有改变的监听器检测编辑操作。在第四步骤S4，用撤消管理器706将可撤消的编辑存储为对象。在第五步骤S5，可撤消编辑接收器709与源708分开，源708可以是文档705本身。

11.向系统载入文档时需要的步骤

上述几个子部分描述了系统的各个组件和子组件。下面将描述在使用这些组件时用到的方法。图19显示了如何将文档载入到文档处理和管理系统中的总体图。参照图24-28详细地描述各个步骤。

简言之，文档处理和管理系统从由在文档中包含的数据构成的二进制数据流创建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。

再次参照图19(a)，在步骤1，将顶节点联接到窗格907(窗格907是屏幕的物理布局)。在步骤2，窗格907向应用程序核心908请求用于顶节点的区工厂。在步骤3，应用程序核心908返回区工厂以及editlet(其为用于顶节点906的画布工厂)。

在步骤4，窗格907创建区909，区909联接至窗格。在步骤5，区909为各个节点创建“方面”，并联接到相应的节点。在步骤6，窗格创建与其联接的画布910。在画布910中包括各种命令。在步骤7中，画布910则构建用于将文档呈现在屏幕上的数据结构。在XHTML的情况下，这包括盒树结构。

图19(b)使用MVC范例显示了区的结构概要。在这种情况下，模型(M)包括区工厂创建的区和“方面”，这是因为它们是与文档相关的输入。视图(V)对应于画布和数据结构，以利用editlet将文档在屏幕上呈现，这是由于这些呈现是用户在屏幕上看到的输出。控制(C)包括画布中所包含的命令，这是由于这些命令对文档及其关系执行控制操作。

12.文档的表述

下面将使用图20来描述复合文档及其各种表述的实施例。在该实施例中使用的文档包括文本和图片。文本使用XHTML表述，而图片用SVG表述。图20详细显示了用于文档组件的MVC表述以及相应对象的关系。对于该示例性的表述，文档1001联接到保持文档1001的文档容器1002。文档用DOM树1003表述。DOM树1003包括顶节点1004和其他子节点，如之前参照图19(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。如图所示，盒树通过html Box、body Box、head Box和/或table Box的适当组合来表述。维护和呈现文档的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部分呈现在屏幕上的数据结构和命令1014被联接到SVG画布1012。例如，这种数据结构可包括圆圈、线、矩形等，如图所示。

下面将使用先前描述的MVC范例，参照图21(a)和21(b)进一步讨论参照图20描述的、用于对该示例性文档进行表述的部件。图21(a)提供了文档1001的XHTM组件的MV关系的简化图。图中的模型是用于文档1001的XHTML组件的XHTM区1103。包括在XHTML区树中的是几个节点及其相应的“方面”。相应的XHTML区和窗格是MVC范例的模型(M)部分的一部分。MVC范例的视图(V)部分是用于文档1001的HTML组件的相应的XHTML画布1102和盒树。通过画布以及其中所包含的命令，文档的XHTML部分被呈现在屏幕上。例如键盘和鼠标输入的事件以如图所示的相反方向进行处理。

也就是说，源窗格具有附加功能，以起到DOM保持器的作用。图21(b)提供了在图21(a)中示出的用于文档1001的组件的词汇连接。作为源DOM保持器的源窗格1103包含了用于文档的源DOM树。连接器树1004通过连接器工厂创建，连接器树1004又创建作为目的DOM树保持器的目的窗格1105。目的窗格1105接着以盒树的形式被布置为XHTML目的画布1106。

13.插件子系统、词汇连接和连接器之间的关系

图22(a)-(c)分别显示了与插件子系统、词汇连接和连接器相关的附加细节。插件子系统被用来向文档处理和管理系统增加功能，或与之交换功能。插件子系统包括服务代理1041。如图22(a)所示，名称为“My Own XML vocabulary(我的XML词汇)”VCD文件耦合至包括MyOwnXML连接器工厂树和词汇(区工厂，Editlet)的VC基本插件。联接到服务代理1041的区工厂服务1201负责创建用于文档的部分的区。editlet服务1202还被联接到服务代理。editlet服务1202创建与区中的节点相对应的画布。

区工厂的实施例是分别创建XHTML区和SVG区的XHTML区工厂1211和SVG区工厂1212。如上参照示例性文档所述，文档的文本组件可通过创建XHTML区来表述，而图片则可使用SVG区来表述。editlet服务的示例包括XHTML editlet1221和SVG editlet1222。

图22(b)进一步详细显示了词汇连接，如上所述，词汇连接是文档处理和管理系统的重要特征，其能够使两种不同方式的文档的表述和显示保持一致。能够维护连接器工厂303的词汇连接管理器是词汇连接子系统的一部分，并耦合到VCD以接收词汇连接描述符并生成词汇连接命令301。如图22(c)所示，连接器工厂303为文档创建连接器304。如上所述，连接器观察源DOM中的节点，并修改目的DOM中的节点，以维护两种表述之间的一致性。

模板表述用于一些节点的转换规则。事实上，词汇连接描述符文件是表示一些规则的一系列模板，这些规则用于将满足某种路径或规则的元素或元素集合转换为其他的元素。词汇模板305和命令模板3131都联接到词汇连接管理器302。词汇连接管理器302是在VCD文件中所有部分的管理器对象。为一个VCD文件创建一个词汇连接管理器对象。

图22(c)表示了连接器的附加细节。连接器工厂303从源文档中创建连接器。连接器工厂联接于词汇、模板和元素模板，并分别创建词汇连接器、模板连接器和元素连接器。

词汇连接管理器302维护连接器工厂303。为了创建词汇，读取相应的VCD文件。接着创建连接器工厂303。该连接器工厂303与负责创建区的区工厂205和负责创建画布的editlet服务206相关联。

接着，用于目标词汇的editlet服务创建词汇连接画布。词汇连接画布为目的DOM树创建节点。词汇连接画布为源DOM树或区中的顶点元素创建连接器。接着，根据需要递归地创建子连接器。通过VCD文件中的一组模板创建连接器树。

模板是用于将标记语言的元素转换为其他元素的规则集合。例如，各个模板与源DOM树或区相匹配。在正确匹配时，创建顶点连接器。例如，模板“A/*/D”监测所有从节点A开始、在节点D结束的树分支，而不考虑节点A和节点D之间的节点。同样，“//B”对应于所有来自根节点的“B”节点。

14.VCD文件相关的连接器树的示例

下面将解释与特定文档相关的处理。名为MySampleXML的文档被载入到文档处理系统。图23显示了使用词汇连接管理器的VCD脚本和用于MySampleXJML的连接器工厂树的实施例。在图中显示了脚本文件内的词汇部分、模板部分以及它们在词汇连接管理器中的相应组件。在标签“vcd：vocabulary”下提供了属性match＝＂sample：root＂、label＝＂MySampleXML＂以及call-template＝＂sampleTemplate＂。

与该实施例相对应，在MySampleXML的词汇连接管理器中，词汇包括顶点元素“sample：root”。相应的UI标注为“MySampleXML”。在模板部分，标签为vcd：template，名称为“sample template”。

15.如何将文件载入系统的详细实施例

图24-28显示了载入文档MySampleXML的详细描述。在步骤1，如图24(a)所示，文档从存储1405中载入。DOM服务创建DOM树和文档管理器1406以及对应的文档容器1401。文档容器联接到文档管理器1406。文档包括用于XHTML和MySampleXML的子树。XHTML顶节点1403是用于XHTML的最顶部的节点，并具有标签x???html：html。另一方面，mysample顶节点1404对应于MySampleXML，并具有标签sample：root。

在步骤2，如图24(b)所示，根窗格为文档创建XTML区、“方面”和画布。根据图中示出的关系，在步骤1-5中创建与顶节点1403、其他节点以及它们相关的“方面”相应的窗格1407、XHTML区1408、XHTML画布1409和盒树1410。

在步骤3，如图24(c)所示，XHTML区域找到外来的标签“sample：root”，并从html画布上的区域创建子窗格。

图25显示了步骤4，在步骤4中，子窗格1501获取能够处理“sample：root”标签并创建适当的区的相应的区工厂。这种区域工厂将在能够实现区域工厂的词汇中。区域工厂包括MySampIeXML中的词汇部分的内容。

图26显示了步骤5，在步骤5中，与MySampleXML对应并与VC管理器相连的词汇创建缺省的区1061。相应的editlet被创建并被提供给子窗格1501，以创建相应的画布。editlet创建词汇连接画布。接着，editlet调用与连接器工厂树耦合的模板部分。连接器工厂树创建所有的连接器，接着将创建的连接器形成连接器树(连接器树形成VC画布的一部分)。根据前面的描述，对于与文档的XHTML内容相关的顶节点，根窗格和XHTML区的关系以及XHTML画布和盒树之间的关系是显而易见的。

图27基于如上所述的源DOM树、VC画布和目的DOM树之间的对应关系显示了步骤6。在步骤6中，各个连接器创建目的DOM对象。一些连接器包括xpath信息。xpath信息包括一个或多个xpath表达式，xpath表达式用来确定需要被监测是否发生了改变/修改的源DOM树的子集。

图28根据源、VC和目的关系显示了步骤7。在步骤7中，词汇从源DOM的窗格形成目的DOM树的目的窗格。这基于源窗格来完成。接着，将目的树的顶节点联接到目的窗格以及相应的区。接着为目的窗格设置其自身的editlet，editlet则创建目的画布，并构建数据结构和命令，从而以目的格式呈现文档。

图29(a)显示了发生于某节点的事件流，该节点不具有相应的源节点并仅依赖于目的树。在第一步骤，画布所获取的事件(例如鼠标事件和键盘事件)通过目的树，并被传输到元素模板连接器(ElementTemplateConnector)。元素模板连接器不具有相应的源节点，因此被传送的事件并不是对源节点的编辑操作。如果所传送的事件与命令模板(CommandTemplate)中描述的命令相匹配，则元素模板连接器在第二和第三步骤执行相应的动作。否则，元素模板连接器忽略所传送的事件。

图29(b)显示了发生于某目的树的节点的事件流，该目的树的节点通过文本连接器(TextOfConnector)与源节点相关联。文本连接器从由源DOM树的XPath规定的节点获取文本节点，并将该文本节点映射为目的DOM树的节点。在第一步骤，画布所获取的事件(例如鼠标事件和键盘事件)通过目的树，并被传送到文本连接器。文本连接器将所传送的事件映射为相应源节点的编辑命令，并将这些命令设置在队列1053中。编辑命令是通过“方面”执行的DOM的一组API调用。在第二步骤中，当执行设置在队列中的命令时，编辑源节点。在编辑源节点时，在第三步骤发出变化事件，并且将对源节点的修改通知到注册为监听器的文本连接器。在第四步骤中，文本连接器重新建立目的树，从而在相应的目的节点中反映出对源节点的修改。如果包含文本连接器的模板包括控制声明，例如“for each”和“for loop”，则连接器工厂重新评估控制声明。在重建文本连接器后，重建目的树。

上面基于仅为说明性的实施方案描述了本发明。本领域的技术人员应该理解，还可以对上述的各个组件和处理组合进行其他各种修改，并且这些修改落入本发明的保护范围。

尽管通过处理XML文档的实施例解释了上述实施方案，但根据这些实施方案的文档处理装置20还能够类似地处理以其他标记语言(例如SGML和HTML)描述的文档。

Claims (22)

1.一种文档处理装置，包括：

文档处理器，可操作以处理以第一标记语言描述的文档，其中，所述文档处理器能够处理所述第一标记语言而不能处理第二标记语言；以及

文档转换器，如果一文档以所述第二标记语言描述，则所述文档转换器可操作以将该文档映射为所述第一标记语言；以及

定义文件，可操作以描述所述第一和第二标记语言之间的映射，

其中，所述文档转换器可操作以通过参考所述定义文件，在所述第一和第二标记语言之间映射所述文档。

2.如权利要求1所述的文档处理装置，其中，

所述第一标记语言是结构语言，所述结构语言可操作以通过将文档中的数据分类为具有分级结构的多个组件来描述所述数据；以及

所述文档转换器可操作以将所述文档以所述组件为单元映射为所述第一标记语言。

3.如权利要求2所述的文档处理装置，其中，所述多个组件中的至少一个在所述定义文件中被定义为能够编辑。

4.如权利要求2所述的文档处理装置，其中，

所述定义文件包括至少一个运算表达式；以及

所述文档转换器可操作以将基于所述运算表达式的计算结果代入所述文档的、与所述运算表达式相对应的位置。

5.如权利要求1所述的文档处理装置，还包括：

构造器，可操作以从所述文档生成数据，所述数据具有这样的形式，即，可操作以生成能够提供对所述文档的访问的文档对象模型，

其中，所述构造器可操作以生成对应于所述第二标记语言的源文档对象模型数据，以及生成对应于所述第一标记语言的目的文档对象模型数据。

6.如权利要求5所述的文档处理装置，其中，所述处理装置可操作以通过参考所述目的文档对象模型数据来显示所述文档。

7.如权利要求5所述的文档处理装置，其中，当所述处理装置接收编辑所述文档的指令时，

所述文档转换器可操作以修改所述源文档对象模型数据所述目的模型的相关部分；以及

所述文档处理装置可操作以通过参考所述目的文档对象模型数据来更新显示。

8.如权利要求1所述的文档处理装置，还包括：连接器单元，所述连接器单元可操作以维持包含在所述源文档对象模型数据中的数据与包含在所述目的文档对象模型数据中的相应数据之间的对应关系。

9.如权利要求8所述的文档处理装置，其中，当所述处理装置接收编辑所述文档的指令时，

所述连接器单元可操作以获取所述编辑指令，基于所述对应关系提取所述源文档对象模型数据中待编辑的节点，以及对所述节点执行与所述编辑指令相对应的修改操作。

10.如权利要求8所述的文档处理装置，其中，当所述连接器单元接收到所述源文档对象数据模型的所述节点被修改的通知时，所述连接器单元可操作以基于所述对应关系提取所述目的文档对象数据模型的、与所述被修改的节点相对应的节点，以及重新构造所述目的文档对象数据模型的节点。

11.如权利要求8所述的文档处理装置，其中，所述连接器单元包括与所述目的文档对象数据模型的各个节点一一对应的连接器，以及

所述连接器包括：

第一连接器，所述第一连接器维持所述目的文档对象数据模型的节点与所述源文档对象数据模型的节点之间的对应关系；以及

第二连接器，所述第二连接器不具有所述源文档对象数据模型的节点。

12.如权利要求10所述的文档处理装置，其中，当所述处理装置接收编辑所述文档的指令时，

向被通知连接器通知所述编辑指令，该连接器与所述目的文档对象数据模型的、文档中编辑位置所属的节点相对应；以及

如果所述收到通知的连接器是所述第一连接器，则所述第一连接器将所述通知的编辑指令转换为对所述相应的源文档对象数据模型进行的修改操作。

13.如权利要求11所述的文档处理装置，其中，当所述连接器单元接收到所述源文档对象数据模型的节点被修改的通知时，所述连接器单元可操作以重新构造所述相应的目的文档对象模型数据。

14.如权利要求11所述的文档处理装置，其中，所述连接器中的至少一个是文本连接器，其中所述文本连接器创建的对应节点能够被编辑。

15.如权利要求11所述的文档处理装置，其中，所述连接器中的至少一个是值连接器，所述值连接器创建的对应节点不能被编辑。

16.如权利要求11所述的文档处理装置，其中，所述连接器中的至少一个是模板连接器，与所述模板连接器关联的对应节点是模板，与所述模板关联的值能够改变。

17.如权利要求11所述的文档处理装置，其中，所述连接器中的至少一个可操作以到达所述源文档对象数据模型树中的相应节点，即便是所述节点中的文本值被改变。

18.如权利要求17所述的文档处理装置，其中，所述连接器中的至少一个可操作以识别所述源文档对象数据模型树的最新结构中的最新文本，并通知所述目的文档对象数据模型树。

19.如权利要求17所述的文档处理装置，其中，到达所述源文档对象数据模型树中的相应节点是通过分析xpath表达式来实现的。

20.如权利要求19所述的文档处理装置，其中，所述xpath表达式包括路径。

21.如权利要求19所述的文档处理装置，所述xpath表达式包括函数。

22.一种用于处理文档的文档处理方法，包括：

获取定义文件，所述定义文件可操作以描述所述第一和第二标记语言之间的映射，其中，通过参考所述定义文件，能够在所述第一和第二标记语言之间映射文档；

当复杂的文档以所述第一标记语言描述时，将所述文档映射为第二标记语言，所述文档由能够处理所述第二标记语言而不能处理所述第一标记语言的文档处理装置来处理；以及

显示所映射成的文档。

Images