CN1947114A - 处理使用标记语言的文档的装置 - Google Patents

Abstract

用于对以多种标记语言描述的、通过标签集且使用插件来表述的文档进行处理的文档处理装置，例如HTML单元和SVG单元。在待处理的文档以多个标签集来描述的情况下，文档选择能够在元素名和元素的命名空间基础上对文档中所包含的元素进行处理的处理系统。选定的处理系统从所述元素向该元素的子孙元素按顺序地确定元素是否能够处理，处理系统将元素的处理委托给另一处理系统。因此，适当的处理系统被分配给每个元素。

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)div 4”。这意味着显示学生的分数的平均值。

图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”和“Most Important”的标签以通过强调的方式来显示这些标签周围的部分，或者可将这些标签以重要性的顺序来排序以进行相应显示。

当用户在编辑显示器(例如，如图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)中示出了服务的例子。根据应用程序服务的种类，系统实用程序是相应服务提供器的示例。同样，editlet 206是一个种类，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 editlet 1221和SVG editlet 1222。

图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的最顶部的节点，并具有标签xhtml: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”，则连接器工厂重新评估控制声明。在重建文本连接器后，重建目的树。

该实施方案提供了一种在处理文档时分配适当的处理单元或系统的方法。

如参照图24(a)所述的那样，当载入文档并生成DOM树时，选择顶节点处理单元。如参照图19(a)所述的那样，顶节点被传送到根窗格，窗格拥有者选择能处理该顶节点的处理单元。

窗格拥有者预先注册可由用于系统中存在的词汇插件或VCD文件的各个处理单元处理的命名空间和顶节点元素名称的条目，并根据由窗格传送的命名空间和顶节点的元素名称来选择适当的处理单元。被选择的处理单元提供区工厂和editlet，并分别由区工厂和editlet生成区和画布。该处理的流程已参照图19(a)至24(a)进行了说明。

当区遇到对于该区而言未知的节点(即，该区不能向其联接“方面”)时，虽然该区试图向节点联接“方面”，但是该区不能处理该节点。该区可忽略该节点或者可将对该节点的处理委托给另一处理单元。在后一种情况下，该区将该节点返回至窗格。该窗格为以该节点为顶节点的区生成子窗格，并将该节点和子窗格返回至父节点。窗格拥有者选择能处理该节点的处理单元。通过这种方式，可向DOM树中的各个节点分配至少一个处理单元，从而能使用分配的处理单元来处理DOM树中的所有节点。

处理单元是根据命名空间和顶节点的元素名称来选择的。也可考虑顶节点的属性名称和属性值。还可同样考虑对顶节点指定的全局属性。作为顶节点的属性或全局属性，待选择的候选处理单元可被明确指定。可提供列举了能够由处理单元进行处理的元素的表，用于选择能够处理顶节点下方的元素的处理单元。此外，可考虑该顶节点的祖先节点上的信息。在这一点上，DOM树上的、作为主题节点(subjectnode)的后代节点或兄弟节点的任一节点可被称为“祖先”或“后代”。例如，节点可参考其祖先的兄弟/姐妹。

当将另一词汇的全局属性指定给一词汇的元素时，仅能用于一个词汇的处理单元可能无法处理该词汇。为了解决这一问题，例如，如果指定了全局属性，则可选择用于全局属性的处理单元，并将其与用于顶节点所属词汇的处理单元一起载入。在这种情况下，全局属性处理单元和顶节点处理单元可依据多种因素、并根据一种或多种分配算法而并行处理、交替处理或选择性地处理。

如果选择了多个能够进行处理的处理单元，则可接受来自用户的选择指令，或者可参考历史记录来确定适当的处理单元。例如，对于一直使用某特定开发商的处理单元的用户，该开发商的处理单元可以作为第一优先级而选择。

在上述实施例中，尽管遇到了不能处理的节点的区将对该节点的处理委托给另一处理单元，但能够处理节点的节点也可将对该节点的处理委托给另一处理单元。例如，当XHTML处理单元处理XHTML文档时，如果用以对表进行处理的另一处理单元载入该系统中，则对表元素的处理可委托给所述另一处理单元。如果处理单元能够处理的节点被嵌套入DOM树，则被选择的处理单元可搜索祖先节点，以检查该处理单元能够处理的节点，并指定能作为新的顶节点处理的最高级别的节点。该处理单元可确定是否逐个节点地将处理委托给另一处理单元。

如果多个处理单元都能处理节点，那么可预先设定为待选择的处理单元赋予第一优先级的条件，或者可向用户发出选择哪个处理单元的询问。如果一文档中包含了多个标签集，则用以确定处理单元的最佳组合的条件可在分配算法中预先设定。例如，可以为与相应DOM树中的节点相关的各个元素分配候选处理单元，可以选择处理单元的组合以使得处理单元的边界最小化。例如，假设处理系统A能够处理标签a和b，处理系统B能够处理标签b、d和e，处理系统C能够处理标签a、c和e，那么，当待处理的文档包含自最高级别降序排列的标签a、c、d和e时，最高级别的标签“a”可由处理系统A或C来处理，标签“c”可由处理系统C来处理、标签“d”可由处理系统B来处理、标签“e”可由处理系统B或C来处理。因此，处理系统C被分配给标签“a”和“c”，而处理系统B被分配给标签“d”和“e”。

在分配处理单元时的其他考虑包括整个系统的资源消耗的优化或响应性能的优化。换句话说，对处理单元的选择可基于一种或多种分配算法和/或标准。此外，在多个候选单元都能处理给定节点的情况下，多个处理单元可并行地进行处理，但仅被选择的一个或多个结果可显示给用户，而其他结果则简单地运行于后台。

区边界并非必须与命名空间边界相匹配。区边界并非必须与标签集边界相匹配。例如，当提供了既能处理SHTML又能处理SVG的词汇插件时，可通过使用单个词汇插件来处理包含XHTML和SVG的复合文档。可提供处理单元来以电子数据表应用的方式仅处理XHTML的表部分。换句话说，处理单元可能能够处理多个词汇、标签集和标记语言。

因而，如根据前述的能力已清楚说明的那样，复合文档的片段可被多个处理单元处理，这些单元可相互共享处理共用词汇和/或标签的能力。此外，这些处理单元中可具有共用或共享的能力，以处理撤消步骤。这种共用能力可操作以在共用显示媒介上执行聚焦管理和定位管理，并可被调整以处理对复合文档进行处理时的暂停和恢复。这种共用能力可通过排列命令来操作。

处理单元还可在文件名或文档文件的扩展名的基础上选择。另外，处理单元可在处理细节的基础上选择。例如，在浏览文档的情况下，可选择专用于浏览的处理单元。在编辑文档的情况下，可选择能够进行编辑的处理单元。

以这种方式，通过在载入文档后可插入地分配适当的处理单元，包含词汇的任意组合的文档能被正确地处理。即使是在文档载入之后，当前处理单元也能被另一处理单元取代。

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

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

Claims (40)

1.一种文档处理装置，其可操作以处理具有一个或多个词汇的复合文档，用于显示给用户以进行编辑，从而有利于对所述复合文档进行编辑，所述文档处理装置包括：

多个处理单元，所述多个处理单元中的每一个可操作以在预定标签集的基础上对文档或文档的一部分进行处理；以及

显示处理装置，其响应于所述多个处理单元，用于为在单一显示媒介上向所述用户显示所述复合文档做准备。

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

词汇转换器，当所述复合文档包括了所述多个处理单元中的至少一个单元不能处理的标签集所定义的部分时，所述词汇转换器可操作以将用于该部分的标签集映射为能够由所述多个处理单元中的至少一个来处理的标签集。

3.如权利要求1所述的文档处理装置，其中，当所述复合文档包括了所述多个处理单元中的至少一个单元不能处理的标签集所定义的部分时，所述文档处理装置将该部分呈现为源显示或者树显示。

4.如权利要求1到3中任一项所述的文档处理装置，其中，所述显示处理装置可操作以呈现与所述复合文档待编辑的部分相对应的编辑菜单。

5.如权利要求1到4中任一项所述的文档处理装置，其中，对于包括多种标签集的复合文档，能够对用于第一种标签集的数据进行处理的处理单元可操作以访问所述复合文档的、由不同于所述第一标签集的第二标签集构成的部分的数据。

6.如权利要求1到4中任一项所述的文档处理装置，其中，所述复合文档由多个元素表述，所述多个元素中的每一个包含选择信息；根据从一元素中获取的选择信息，将所述多个处理单元中能够处理所述文档中的该元素的一个处理单元选为选定的处理单元。

7.如权利要求6所述的文档处理装置，其中，从所述元素中获取的所述选择信息包括元素名和元素命名空间的至少其中之一。

8.如权利要求6或7所述的文档处理装置，其中，从所述元素中获取的所述选择信息包括所述元素中所包含的属性的属性名和属性值的至少其中之一。

9.如权利要求6到8中任一项所述的文档处理装置，其中，被选择来处理元素的处理单元从所述元素向其子元素按顺序地确定元素是否能够处理，当存在不能处理的元素时，所述处理单元可操作以至少委托另一个处理单元作为选定的处理单元处理所述元素，或者制止所述元素的处理。

10.如权利要求9所述的文档处理装置，其中，当所述处理单元能够处理元素，且另一个处理单元也能够处理所述元素时，所述处理单元能够选择：是由所述处理单元还是由所述另一个处理单元作为选定的处理单元来处理所述元素。

11.如权利要求1到4中任一项所述的文档处理装置，还包括管理单元，所述管理单元用于生成和管理具有与文档对象模型相符的格式的数据，所述文档对象模型被定义成提供一种访问方法，用来以处理数据方式处理所述文档，

其中，所述管理单元生成对应于所述文档的文档对象模型数据；以及

根据从表述所述文档对象模型数据的DOM树的子树的顶节点中获得的信息，将一处理单元选为选定的处理单元。

12.如权利要求11所述的文档处理装置，其中，所述选定的处理单元从所述顶节点向所述顶节点的子节点增加对象，所述增加的对象包括专用于所述节点的s，并且所述选定的处理单元委托另一个处理单元对不能增加所述对象的节点进行处理。

13.如权利要求6到12中任一项所述的文档处理装置，其中，所述处理单元中的至少一个可操作以处理多个标签集。

14.一种文档处理方法，用于对具有一个或多个词汇的复合文档进行处理以有利于对所述复合文档进行编辑，所述方法包括：

提供多个处理，所述多个处理中的每一个在用于显示的预定标签集的基础上对文档或文档的一部分进行处理；

处理所述文档的所述多个标签集以在共用的显示媒介上进行显示；以及

对用户输入进行响应以编辑所述文档。

15.一种计算机程序产品，其可操作以控制计算机执行用于处理具有一个或多个词汇的复合文档的方法，以有利于对所述复合文档进行编辑，包括：

提供多个处理，所述多个处理中的每一个在用于显示的预定标签集的基础上对文档或文档的一部分进行处理；

处理所述文档的所述多个标签集以在共用的显示媒介上进行显示；以及

对用户输入进行响应以编辑所述文档。

16.一种用于编辑和/或显示具有多个词汇的复合文档的方法，包括：

载入待处理的所述复合文档；

从所述复合文档生成DOM树；

通过参考所述复合文档的命名空间或元素的至少其中之一，确定所述复合文档由哪个或哪些词汇描述；

如果对应于所述词汇的词汇处理部件是可用的，则操作所述词汇处理部件以显示和/或编辑所述文档；

如果所述词汇处理部件是不可用的，则确定是否存在相应的定义文件；以及

如果存在所述定义文件，则获取所述定义文件并生成相应的目的树，从而能够通过与所述词汇对应的、映射的处理部件来显示和/或编辑所述文档。

17.如权利要求16所述的方法，其中，对于多个词汇中的每一个，通过与各词汇相对应的处理部件来显示和/或编辑所述复合文档的相关部分。

18.如权利要求16所述的方法，其中，如果不存在所述定义文件，则显示所述复合文档的源或树结构，并在显示媒介中执行编辑。

19.如权利要求17所述的方法，其中，所述复合文档的至少一部分能够通过多个处理部件来显示和/或编辑。

20.如权利要求17所述的方法，其中，所述复合文档的至少两部分能够通过共用的处理部件来显示和/或编辑。

21.一种用于处理复合文档以显示给用户从而有利于显示所述复合文档的方法，所述复合文档具有至少两个标签集并能够分为分离的片段，所述方法包括：

根据所述片段逻辑地分割所述文档；

为至少两个片段中的每一个分配至少一个对应的处理部件；

使用至少一个对应的处理部件分别处理所述片段中的至少两个，所述处理部件的每一个可操作以处理预定的标签集；以及

在共用的编辑显示器上显示对所述至少两个片段进行处理的结果。

22.如权利要求21所述的方法，还包括：

在存储器中将所述复合文档表示为具有多个节点的DOM树；以及

执行所述处理步骤作为对所述DOM树的至少一部分进行修改。

23.如权利要求22所述的方法，其中，所述DOM树包括多个元素节点，所述分割步骤在与至少一个所述元素节点相对应的信息的基础上执行。

24.如权利要求23所述的方法，其中，与所述元素节点相对应的所述信息包括命名空间名和元素名的至少其中之一。

25.如权利要求23所述的方法，还包括：

为所述DOM树中的每个节点分配至少一个处理部件，以及

其中，所述处理步骤包括使用所述分配的处理部件来处理所述DOM树中的所有节点。

26.如权利要求22所述的方法，其中，将多个编辑处理部件分配给给定节点，以及对所述给定节点通过所述多个处理部件执行所述处理步骤；以及

其中，对所述多个处理部件中的至少一个执行所述显示步骤，而对所述多个处理部件中的至少还有一个不执行所述显示步骤。

27.如权利要求21所述的方法，其中，所述分配步骤根据至少两个分配标准的其中之一来执行。

28.如权利要求21所述的方法，其中，至少一个所述处理部件能够由用户选择。

29.如权利要求21所述的方法，其中，所述分配步骤基于使资源消耗优化的处理部件。

30.如权利要求21所述的方法，其中，所述分配步骤基于提供最佳响应性能的编辑处理部件。

31.如权利要求21所述的方法，其中，所述分配步骤基于由用户预先指定的两个或多个处理部件。

32.如权利要求21所述的方法，其中，所述处理步骤包括通过参考DOM树，用对应的处理部件和不对应的处理部件中的一个处理所述复合文档的片段。

33.如权利要求32所述的方法，其中，多个处理部件相互共享共用部件。

34.如权利要求33所述的方法，其中，多个处理部件的所述共用部件可操作以处理撤消步骤。

35.如权利要求33所述的方法，其中，多个处理部件的所述共用部件可通过排列命令来操作。

36.如权利要求33所述的方法，其中，多个处理部件的所述共用部件可操作以执行共用显示媒介上的聚焦管理和位置管理。

37.如权利要求33所述的方法，其中，多个处理部件的所述共用部件可操作以暂停和恢复对复合文档的处理。

38.如权利要求22所述的方法，还包括：

如果使用所述多个处理部件不能为所有节点执行所述分配步骤，则委派源显示处理部件处理不具有相应处理部件的节点。

39.如权利要求22所述的方法，还包括：

如果不能通过所述多个处理部件为所有节点执行所述分配步骤，通过将结构转换为相应的处理部件不存在的部件执行待分配给现存的处理部件的处理。

40.如权利要求21所述的方法，还包括：

至少根据与所述共用显示媒介上的当前编辑相对应的处理部件，切换用户界面的一部分。

Images