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

Abstract

本发明提供了适当地处理利用标记语言结构化的文档的技术。当文档处理装置获取第一词汇描述的文档并生成源DOM树时，即应用与该文档相关的第一定义文件，将该文档映射为用第二词汇描述的文档，从而生成目的DOM树(1)。此外，文档处理装置应用第二定义文件，将该文档映射为第三词汇描述的文档，生成目的DOM树(2)。文档处理装置通过负责第三词汇的处理系统，显示映射到第三词汇的文档。

Description

文档处理装置和文档处理方法

技术领域

本发明涉及文档处理技术，特别涉及处理由标记语言描述的文档的文档处理装置和文档处理方法。

背景技术

XML作为适用于通过网络等与他人共享数据的格式受到人们的关注，且人们正开发用于编写、显示和编辑XML文档的应用软件(例如，请参考专利文献1)。XML文档由根据文档类型定义等所定义的词汇(标签集)编写。

专利文献1：特开2001-290804号公报

发明内容

发明要解决的课题

词汇可以任意进行定义，在理论上可以存在无限多的词汇。对应于所有这些词汇提供专用的显示和编辑环境是不太现实的。在现有技术中，在对由专用编辑环境未准备的词汇描述的文档进行编辑的情况下，直接用文本编辑器等编辑由文本数据构成的文档的源。

本发明是鉴于这种状况而做出的，其目的在于提供一种支持创建新词汇的技术。

解决课题的方案

本发明的实施方式是关于文档处理装置的。该文档处理装置包括：第一连接器单元，在获取了由第一标记语言描述的第一文档时，将所述第一文档映射为由不同于第一标记语言的第二标记语言描述的第二文档，监视作为映射源的所述第一文档和作为映射目的的所述第二文档的对应关系，保持其整体性；第二连接器单元，将所述第二文档映射为由不同于所述第二标记语言的第三标记语言描述的第三文档，监视作为映射源的所述第二文档和作为映射目的的所述第三文档的对应关系，保持其整体性；处理系统，将所述第三文档布局并显示，并接受来自用户的编辑操作。

文档处理装置进一步包括：获取单元，获取描述了用于将所述第一文档向所述第二文档映射的规则的第一定义文件，和描述了用于将所述第二文档向所述第三文档映射的规则的第二定义文件，所述第一连接器单元可基于所述第一定义文件生成，所述第二连接器单元可基于所述第二定义文件生成。

所述处理系统接收到用户对所述第三文档的编辑操作时，所述第二连接器单元可将所述第二文档的与成为所述第三文档的所述编辑操作对象的部分对应的部分确定为编辑对象，所述第一连接器单元可将所述第一文档中与成为所述第二文档的编辑对象的部分对应的部分确定为编辑对象。

所述处理系统接收到用户对所述第三文档的编辑操作时，对所述第二连接器单元发布所述第二文档的编辑事件，所述第二连接器单元从所述处理系统获取了所述编辑事件后，对所述第一连接器单元发布对于与该编辑事件对应的所述第一文档的编辑事件，所述第一连接器单元获取所述编辑事件后，发布对于与该编辑事件对应的所述第一文档的编辑命令，编辑所述第一文档，所述第一连接器单元获取所述第一文档的变更通知后，重新建立所述第二文档，使之反映所述第一文档的变更，所述第二连接器单元获取所述第二文档的变更通知后，重新建立所述第三文档，使之反映所述第二文档的变更，所述处理系统获取所述第三文档的变更通知后，将所述第三文档重新布局显示。

描述用于将所述第二文档向所述第三文档映射的规则的第二定义文件还可以描述将对所述第二文档执行的编辑事件变换为对所述第一文档的编辑事件的规则。

所述处理系统接收用户对第三文档的编辑操作后，发布对与该编辑事件对应的所述第二文档的编辑命令，编辑所述第二文档，所述第一连接器单元获取所述第二文档的变更通知后，将所述第二文档的改变反映到所述第一文档中；所述第二连接器单元获取所述第二文档的变更通知后，重新建立所述第三文档，使之反映所述第二文档的变更，所述处理系统获取所述第三文档的变更通知后，将所述第三文档重新布局显示。

描述用于将所述第一文档向所述第二文档映射的规则的第一定义文件，也可描述用于将所述第二文档的变更反应于所述第一文档的规则。所述第一连接器单元也可参考描述了用于将所述第二文档的变更反映到所述第一文档的规则的第三定义文件，将所述第二文档的变更反映到所述第一文档中。

本发明的另一实施方式涉及文档处理方法。该文档处理方法的特征在于，包括以下步骤：反复多次进行把标记语言描述的文档映射为其他标记语言描述的文档的步骤以生成三个以上的不同的文档的步骤；显示生成的文档中最后阶段文档的步骤；在获取了对所述最后阶段文档的编辑操作时，发布对与该编辑操作对应的前段文档的编辑事件的步骤；将对后段文档的所述编辑事件变换为对于对应的前段文档的编辑事件，向前段传播编辑事件的步骤；将对预定阶段的文档的编辑事件变换为对其文档的编辑命令，编辑该文档的步骤；和将所编辑的文档的变更反映到其他文档的步骤。

另外，作为本发明的实施方式，以上构成要素的任意组合、以及将本发明的描述在方法、装置、系统等之间进行变换的方式也是有效的。

发明的效果

根据本发明，可提供适当地处理利用标记语言结构化的文档的技术。

附图说明

图1是与前提技术相关的文档处理装置的构成示意图；

图2示出了作为处理对象的XML文档的例子；

图3示出了将图2所示的XML文档映射为HTML描述的表的例子；

图4(a)示出了用于将图2所示的XML文档映射为图3所示的表的定义文件的例子；

图4(b)示出了用于将图2所示的XML文档映射为图3所示的表的定义文件的例子；

图5示出了当利用图3所示的对应关系将图2所示的用成绩管理词汇描述的XML文档映射为HTML时显示屏幕的例子；

图6示出的是为了用户创建定义文件而由定义文件生成单元向用户提示的图形用户界面的例子；

图7示出了利用定义文件生成单元生成的屏幕布局(layout)的另一实施例；

图8示出了文档处理装置提供的XML文档的编辑屏幕的例子；

图9示出了利用文档处理装置编辑的XML文档的另一例子；

图10示出了显示图9所示文档的屏幕显示的例子；

图11(a)示出了文档处理系统的基本构成；

图11(b)是文档处理系统的总体方框图；

图11(c)是文档处理系统的总体方框图；

图12示出了文档管理器的细节；

图13示出了词汇连接子系统的细节；

图14示出了程序调用器与其它组成的关系的细节；

图15示出了利用程序调用器载入的应用程序服务的构造的细节；

图16示出了核心组件的细节；

图17示出了文档管理器的细节；

图18示出了提供了撤消框架和撤消命令的细节；

图19示出了文档处理系统中的文档载入的情况；

图20示出了文档及其表现的例子；

图21示出了模型与控制器关系的图；

图22示出了分别涉及插件子系统、词汇连接与连接器的细节；

图23示出了VCD文件的例子；

图24示出了文档处理系统中载入复合文档的顺序的图；

图25示出了文档处理系统中载入复合文档的顺序的图；

图26示出了文档处理系统中载入复合文档的顺序的图；

图27示出了文档处理系统中载入复合文档的顺序的图；

图28示出了文档处理系统中载入复合文档的顺序的图；

图29示出了命令流；

图30中，图30(a)(b)(c)(d)说明了在将定义文件应用于多阶段的情况下的编辑方法。

图31是用单词本词汇描述的文档的例子。

图32是用卡片(card)词汇描述的文档的例子。

图33显示了第二定义文件的例子。

图34显示了第一定义文件的例子。

图35是图31所示的文档根据图34所示的定义文件和图33所示的定义文件，变换为两阶段显示的屏幕的例子。

图36显示了DB-result XML描述的文档的例子。

图37显示了将DB-result XML描述的文档向DirML映射的定义文件的例子。

图38显示了用图37的定义文件映射图36的文档的结果的例子。

符号说明

20文档处理装置        22主控单元      24编辑单元

30 DOM单元            32 DOM提供单元  34 DOM生成单元

36输出单元            40 CSS单元      42 CSS分析单元

44 CSS提供单元        46呈现单元      50 HTML单元

52，62控制单元        54，64编辑单元  56，66显示单元

60 SVG单元            80 VC单元       82映射单元

84定义文件获取单元    86定义文件生成单元

具体实施方式

(前提技术)

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

主控单元22提供插件的载入或提供执行命令的框架。编辑单元24提供了用于编辑XML文档的框架。文档处理装置20中的文档的显示和编辑功能是通过插件来实现的，而必要的插件是根据所处理的文档类型、通过主控单元22或编辑单元24来载入的。主控单元22或编辑单元24通过参考作为处理对象的XML文档的命名空间来确定哪个或哪些词汇描述了待处理的XML文档的内容，并且对应于所确定的词汇而载入用于显示和编辑的插件，从而执行显示和编辑。例如，利用对HTML文档进行显示和编辑的HTML单元50，以及对SVG文档进行显示和编辑的SVG单元60等在文档处理装置20中被实现为处理单元。也就是说，对于各个词汇(标签集)，将显示系统和编辑系统实现为插件，以使得在对HTML文档和SVG文档进行编辑时，分别将HTML单元50和SVG单元60与其各自的控制单元进行协同载入。如以下将描述的那样，在要对既包括HTML又包括SVG组件的复合文档进行处理时，既载入HTML单元50又载入SVG单元60。

通过实现以上结构，用户能够仅选择必要的功能以安装该功能，如果需要，也能够在稍后阶段增加或删除一个和多个功能。因此，能够有效利用记录媒介的存储区域(例如硬盘)，并能够避免在执行程序的时候存储器使用的浪费。此外，由于这一结构有利于性能扩展，因此开发者自己能够以插件的形式处理新的词汇，因而能够促进开发过程。因此，用户也能够通过增加插件而以较低成本轻易地增加功能。

编辑单元24通过用户接口从用户处接收编辑指令的事件，将事件通知适当的插件并控制处理，所述处理可包括重新执行事件的重做(redo)处理以及取消事件的撤消(undo)处理。

DOM单元30包括DOM提供单元32、DOM生成单元34以及输出部36。DOM单元30实现了与文档对象模型(DOM)相符的功能，在XML文档作为数据被处理时，所述文档对象模型被定义以提供访问方法。DOM提供单元32是满足由编辑单元24定义的接口的DOM的实现。DOM生成单元34从XML文档生成DOM树。如以下将描述的那样，当通过VC单元80将待处理的XML文档映射为其它词汇时，生成与映射源中的XML文档相对应的源树以及与映射目的中的XML文档相对应的目的树。在编辑的末尾，例如输出部36输出作为XML文档的DOM树。

CSS单元40提供与CSS相符的显示功能，并包括CSS分析单元42、CSS提供单元44以及呈现单元46。CSS分析单元42具有用于分析CSS语法的分析功能。CSS提供单元44是CSS对象的实现，并执行对DOM树的CSS层叠处理。呈现单元46是CSS的呈现引擎，并用来显示以诸如HTML的词汇描述的、利用CSS设置的文档。

HTML单元50对以HTML描述的文档进行显示或编辑。SVG单元60对以SVG描述的文档进行显示或编辑。这些显示/编辑系统以插件的形式实现，各个系统包括对文档进行显示的显示单元“画布(Canvas)”56、66、发送和接收包括编辑命令的事件的控制单元“Editlet”52、62以及在接收到编辑命令时对DOM进行编辑的编辑单元“区(zone)”54、64。在控制单元52或62从外部源接收到用于DOM树的编辑命令时，编辑单元54或64修改DOM树，而显示单元56或66更新显示。这些单元具有与被称作MVC(Model-View-Controllers，模型-视图-控制器)的框架相类似的结构，通常，显示单元56及66对应于“视图(View)”，控制单元52及62对应于“控制器(Controller)”，而编辑单元54及64和DOM实体对应于“模型(Model)”。在本前提技术的文档处理装置20中，不仅能够以树型视图显示格式来编辑XML文档，而且能够根据相应的词汇来完成编辑。例如，HTML单元50提供了用户界面，通过该用户界面能够以一种类似于Word处理器的方法对HTML文档进行编辑，而SVG单元60提供了一种用户界面，通过该用户界面能够以一种类似于图像绘制工具的方法对SVG文档进行编辑。

VC单元80包括映射单元82、定义文件获取单元84以及定义文件生成单元86。通过将以某个词汇描述的文档映射为另一词汇，VC单元80提供了一种框架，以通过与被映射的词汇相对应的显示和编辑插件来显示或编辑文档。在本前提技术中，该功能被称为词汇连接(VocabularyConnection：VC)。在VC单元80中，定义文件获取单元84获取描述了映射定义的脚本文件。该定义文件逐个节点地描述了节点间的对应关系(连接)。此时，可规定各节点的元素值或属性值是否可以编辑。也可描述使用了节点的元素值或属性值的运算表达式。这些功能将在稍后进行描述。映射单元82使得DOM生成单元34通过参考VC定义文件获取单元84已经获取的脚本文件来生成目的树，以管理源树与目的树之间的对应关系。定义文件生成单元86为用户提供图形用户界面，以生成定义文件。

VC单元80对源树与目的树之间的连接进行监控。当VC单元80通过由负责显示的插件提供的用户接口从用户处接收编辑指令时，它首先修改源树的相关节点。因此，DOM单元30将发出指示源树已经被修改的变化事件。然后，VC单元80接收该变化事件，并对应于被修改的节点而修改目的树的节点，以使得目的树与源树的修改同步。当为显示/编辑目的树提供必要的处理的插件(例如HTML单元50)接收了指示目的树已经被修改的变化事件时，该插件通过参考被修改的目的树而对显示进行更新。通过执行将词汇转换为另一主要词汇的上述结构，即使是以少数用户使用的局部词汇来描述文档，也能够显示文档，并提供编辑环境。

文档处理装置20显示和/或编辑文档的操作将在下文中描述。当文档处理装置20载入待处理的文档时，DOM生成单元34从XML文档生成DOM树。主控单元22或编辑单元24通过参考待处理的XML文档的命名空间来确定哪个词汇描述XML文档。如果与词汇相对应的插件安装在文档处理装置20中，则该插件被载入以显示/编辑文档。另一方面，如果插件并未安装其中，则进行检查以查看是否存在定义文件。如果存在定义文件，则定义文件获取单元84获取该定义文件，并根据定义生成目的树，以使得能够通过与被映射成的词汇相对应的插件来显示/编辑文档。如果该文档是包含多个词汇的复合文档，则通过与各词汇相对应的插件来显示/编辑该文档的相关部分，以下将详细描述。如果不存在定义文件，则显示文档的源或树型结构，并在显示屏中进行编辑。

图2示出了待处理的XML文档的例子。根据该示例性表示，XML文档用于管理与学生已获得的评分或分数(成績)相关的数据。作为XML文档的上部节点的组件“成績”包括：在“成績”下方为各个学生设置的多个元素“生徒”。元素“生徒”具有属性“名前”，并包括作为子元素的学科“国語”(日语)、“数学”、“理科”以及“社会”(社会科学)。属性“名前”存储学生的姓名。组件“国語”、“数学”、“理科”和“社会”存储分别为日语、数学、自然科学和社会科学的学科的测试成绩。例如，姓名为“A”的学生的成绩是：日语为“90”、数学为“50”、自然科学为“75”以及社会科学为“60”。下文中，该文档中使用的词汇(标签集)被称作“成绩管理词汇”。

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

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

图4(a)和4(b)表示定义文件的例子，以将图2所示的XML文档映射为图3所示的表。该定义文件通过被定义用于和定义文件一起使用的脚本语言来描述。在图4(a)和4(b)所示的例子中，“生徒の追加”和“生徒の削除”被定义为命令，并分别涉及将节点“生徒”插入源树中的操作以及将节点“生徒”从源树中删除的操作。模板描述了诸如“名前”和“国語”的标题显示于表的第一行中，而节点“生徒”的内容显示于第二行及其随后的行中。在显示节点“生徒”内容的模板中，包含“text-of”的项表示允许进行编辑，而包含“value-of”的项表示不允许进行编辑。在这些显示了节点“生徒”内容的行中，在第六列中描述了运算表达式“(src：国語+src：数学+src：理科+src：社会)div 4”。这意味着显示学生成绩的平均值。

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

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

图6示出了由定义文件生成单元86显现给用户的图形用户界面的例子，以使用户能够生成定义文件。待映射的XML文档在屏幕的左侧区域91显示为树。被映射成的XML文档的屏幕布局显示在屏幕的右侧区域92中。该屏幕布局可通过HTML单元50来编辑，用户在屏幕的右侧区域92中确定并创建用于对文档进行显示的屏幕布局。例如，使用诸如鼠标等的指示设备将屏幕的左侧区域91中显示的XML文档的待映射的节点拖动并放置到屏幕的左侧区域91中的HTML屏幕布局中，以指定映射源处的节点与映射目的处的节点之间的连接。例如，当作为元素“生徒”的子元素的“数学”被放置到HTML屏幕上的表90中第一行与第三列的交叉处时，第三列中的“数学”节点与“TD”节点之间建立连接。各节点均被如此被指定为可编辑或者不可编辑。此外，可在显示屏中嵌入运算表达式。当完成屏幕编辑时，定义文件生成单元86生成定义文件，其描述屏幕布局与节点之间的连接。

已经开发出了能够处理主要词汇(例如XHTML(可扩展超文本标记语言)、MathML(数学标记语言)以及SVG(可缩放矢量图形))的浏览器或编辑器。但是，不可能开发出适于以自创词汇描述的所有文档(例如图2中所示的文档)的浏览器或编辑器。然而，如果如上所述创建了用于映射为其它词汇的定义文件，那么以自创词汇描述的文档就能够使用VC功能来显示和/或编辑，而不需不断开发新的浏览器或编辑器。

图7示出了由定义文件生成单元86生成的屏幕布局的另一例子。在图7所示的例子中，在屏幕上产生表90和圆形图92用于显示以成绩管理词汇描述的XML文档。圆形图93以SVG描述。如以下将讨论的那样，根据本前提技术的文档处理装置20能够对在单个XML文档内以多个词汇描述的复合文档进行处理。这就是为什么以HTML描述的表90以及以SVG描述的圆形图93能够显示在同一屏幕上的原因。

图8示出了用于由文档处理装置20处理的XML文档的编辑屏幕的一例。在图8所示的例子中，单个屏幕被分割为多个区域，而待处理的XML文档在各个区域以多种不同显示格式显示。该文档的源在区域94中显示，该文档的树结构在区域95中显示，而图5所示的、以HTML描述的表在区域96中显示。该文档在这些区域中的任意区域均可被编辑，当用户对这些区域中的任意区域的内容进行编辑时，源树将被相应修改，从而负责各屏幕显示的插件更新应反映源树变更的屏幕。具体而言，负责显示对应编辑屏幕的插件的显示单元被预先注册为变化事件的监听器，所述变化事件提供源树中发生了改变的通知。当源树被任意插件或VC单元80修改时，显示编辑屏幕的所有显示单元接收发出的一个或多个变化事件，并从而更新屏幕。此时，如果插件正在通过VC功能进行显示，则VC单元80根据对源树的修改来修改目的树。之后，插件的显示单元通过参考上述经过修改的目的树而对屏幕进行更新。

例如，当通过专用插件来实现源显示和树型视图显示时，源显示插件和树显示插件通过直接参考源树而不是利用目的树来实现它们的显示。在这种情况下，当在屏幕的任何区域中完成编辑时，源显示插件和树显示插件通过参考修改后的源树来更新屏幕。同样，负责显示区域96的HTML单元50通过参考目的树来更新屏幕，该目的树已根据对源树的修改而做了修改。

源显示和树型视图显示也可通过使用VC功能而实现。也就是说，例如，如果HTML被用于源和树型结构的布局，则XML文档可映射为HTML以通过HTML单元50来显示。在这种情况下，将生成具有源格式、树格式、表格式的三个目的树。如果在屏幕上的三个区域的任意一个中进行编辑，则VC单元80对源树进行修改，并在之后分别对具有源格式、树格式、表格式的三个目的树进行修改。然后，HTML单元50通过参考三个目的树来更新三个屏幕显示。

以这种方式，在单个屏幕上以多种显示格式显示文档，从而提高了用户的便利性。例如，用户能够利用表90或类似物来以视觉上易于理解的格式显示和编辑文档，同时通过源显示或树显示来理解文档的分级结构。在上述实施例中，单个屏幕被划分为多个显示格式，它们被同时显示。但是，也可在单个屏幕上显示单个显示格式，从而可通过用户指令来切换显示格式。在这种情况下，主控单元22从用户处接收用于切换显示格式的请求，并随后命令对应的插件进行显示切换。

图9示出了由文档处理装置20编辑的XML文档的另一例。在图9所示的XML文档中，XHTML文档被嵌入SVG文档的“foreignObject”标签中，而该XHTML文档包含以MathML描述的公式。在这种情况下，编辑单元24通过参考命名空间而将描绘任务分配或指派给适当的显示系统。在图9所示的实施例中，编辑单元24首先使SVG单元60描绘矩形，然后使HTML单元50描绘XHTML文档。此外，编辑单元24使MathML单元(未示出)描绘公式。以这种方式，包含多个词汇的复合文档被适当地显示。图10示出了显示结果。

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

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

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

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

当用户在图10所示的编辑屏幕上对文档进行编辑时，负责对被编辑的部分进行处理的插件或VC单元80对源树进行修改。能够为源树中的各个节点注册对于变化事件的监听器。通常，与属于各个节点的词汇相符的插件的显示单元或VC单元80被注册为监听器。当源树被修改时，DOM提供单元32从被修改的节点向较高层次探索。如果存在注册的监听器，则DOM提供单元32向该监听器发出变化事件。例如，参考如图9中所示的文档，如果位于<html>节点下方的节点被修改，那么该变化事件被通报给被注册为<html>节点的监听器的HTML单元50。在同一时刻，该变化事件被通报给被注册为位于<html>节点上方的<svg>节点中的监听器的SVG单元60。此时，HTML单元50通过参考被修改的源树而更新显示。由于属于SVG单元60本身的词汇的节点并未被修改，因此SVG单元60可忽视该变化事件。

根据编辑的内容，由HTML单元50对显示进行的修改可改变总体布局。在这种情况下，对于各插件的各个显示区域的布局将由管理屏幕布局的组件(例如，负责显示最高节点的插件)来更新。例如，当由HTML单元50显示的区域较之以前变大时，HTML单元50首先描绘HTML单元50本身所负责的区域，然后确定显示区域的大小。然后，显示区域的大小被通报给管理屏幕布局的组件，以请求对布局进行更新。负责屏幕布局的组件一收到该通知便为各个插件重新布置显示区域。因此，被编辑的部分的显示被适当更新，且总体屏幕布局被更新。

用以实现具有该先决条件技术的文档处理装置20的功能结构将在下面详细描述。以下的说明中，在描述类名等的情况下，使用原来的英文字母。

A.概述

互联网的出现导致由用户处理和管理的文档的数目近乎成指数函数地增长。形成互联网核心的万维网联合会(World Wide Web)包括由这些文档数据构成的大规模数据中心库。除了文档，Web还提供用于这些文档的信息检索系统。这些文档通常用标记语言描述，一种简单且常用的标记语言是HTML(HypeText Markup Language：超文本标记语言)。这种文档还包括指向可能位于该Web其它部分中的其它文档的链接。XML(eXtensible Markup Language：可扩展标记语言)是另一种更高级、更常用的标记语言。用于访问和查看该Web文档的简单浏览器使用面向对象的编程语言(例如Java(注册商标))来开发。

以标记语言描述的文档通常在浏览器和其它应用程序中表述为树型数据结构的格式。这种结构与文档的语法分析树相对应。DOM(Document Object Model：文档对象模型)是一种众所周知的用于表述和操作文档的基于树的数据结构模型。文档对象模型提供了用于表述文档的标准对象集合，包括HTML和XML文档等。DOM包括两个基本组件，即，如何将表述文档中组件的对象进行组合的标准模型，以及用于访问和操作这些对象的标准接口。

应用程序开发者能够支持DOM作为其自身的特定数据结构的API(Application Program Interface：接口和应用程序接口)。另一方面，创建文档的应用程序开发者可使用标准DOM接口而不是使用其自身API的特定接口。因此，由于这种能够提供标准的能力，DOM能有效地增加各种环境中、尤其是Web上的文档的相互利用。已经定义了DOM的几种变化，由不同的编程环境和应用程序来使用。

DOM树是基于相应的DOM的内容对文档的分级表述。DOM树包括“根”以及从根产生的一个或多个“节点”。在某些情况下，根表述整个文档。中间节点可表述元素，诸如表及表中的行和列。DOM树的“叶子”通常表述数据，例如不可进一步分解的文本项目或图像。DOM树中的各个节点可与属性相关联，属性描述了由节点表述的元素的参数，例如字体、大小、颜色、缩进等。

虽然HTML是一种创建文档的常用语言，但它是格式和版式语言。HTML不是一种数据描述语言。表述HTML文档的DOM树的节点包括与HTML格式标签相对应的预先定义的元素。由于HTML通常不提供任何数据描述，也不提供任何对数据的标签/标注，因此，常常难以对HTML文档中的数据进行查询。

网络设计者的目标是使得Web文档能够被软件应用程序查询或处理。独立显示的分级组织的语言能够通过这种方式查询和处理。诸如XML(可扩展标记语言)的标记语言能够提供这些特征。

与HTML相反，众所周知，XML的优点是使得文档设计者能够使用可自由定义的“标签”来对数据元素进行标注。上述数据元素可进行分级组织。另外，XML文档可包含文档类型定义(DTD)，它是对文档中所使用的“语法”(标签及其相互关系)的描述。使用CSS(Cascading StyleSheet：层叠样式表)或XSL(XML Style Language：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)描述的文档进行处理，并能够提供一种用于创建和修改这些文档的友好的用户界面。

此处说明的系统构成中的一些将使用MVC(Model-View-Controllers，模型-视图-控制器)来说明，MVC是一种众所周知的图形用户界面(GUI)范例。MVC范例提供了一种将应用程序(或甚至是一个应用程序的接口)分解为三部分(即，模型、视图和控制器)的方法。最初开发MVC是为了将传统的输入、处理和输出任务映射到GUI环境中。

输入→处理→输出

控制器→模型→视图

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

B.文档处理系统的总体构成

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

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

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

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

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

1.执行环境

执行环境101的关键组件是程序调用器(ProgramInvoker：程序启动单元)103。程序调用器103是被访问以启动文档处理系统的基本程序。例如，当用户登录并启动文档处理系统时，程序调用器103被执行。能够例如读取并处理作为插件增加至文档处理系统的功能、启动并运行应用程序、以及读取与文档相关的属性。程序调用器103的功能并不限于此。当用户希望发起计划在执行环境中运行的应用程序时，程序调用器103找到、发起然后执行该应用程序。

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

a)插件子系统

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

插件子系统104包括服务代理(ServiceBroker：服务中介单元)1041。服务代理1041管理增加至文档处理系统的插件，从而代理已增加至文档处理系统的服务。

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

插件和服务之间的关系是，插件是可包括一个或多个服务提供单元(ServiceProvider：服务提供单元)的单元，各个服务提供单元具有与之相关的一个或多个类别的服务。例如，使用具有适当软件应用程序的单个插件，能将一个或多个服务增加至系统，从而向系统增加相应的功能。

b)命令子系统

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

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

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

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

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

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

c)资源

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

2.应用程序组件

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

a)用户应用程序

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

b)核心组件

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

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

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

c)应用程序核心

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

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

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

d)用户界面

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

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

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

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

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

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

1.DOM模型和区

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

2.“方面”(Facet)及其与区的关系

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

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

由W3C构建的DOM标准定义了用于对节点进行操作的标准接口。实际上，对每个词汇或每个节点提供了特定操作，并且这些操作优选地提供为API。文档处理系统提供了这种作为“方面”的节点特定API，并将“方面”联接至各个节点。这符合DOM标准，同时增加了有用的API。通过在已应用的标准DOM之上增加特定的API而不是为每个词汇实现特定的DOM，可集中处理多种词汇，并正确地处理其中具有多个词汇任意组合的混合的文档。

“词汇”是属于命名空间的标签(例如XML标签)的集合。如上所述，命名空间具有唯一的名称集(在该特定情况下为标签集)。词汇表现为表述XML文档的DOM树的子树。这种子树包括区。在特定实施例中，标签集的边界由区来限定。区209是利用被称作“区工厂服务”205的服务而创建的。如上所述，区209是对表述文档的DOM树的仅仅一部分的内部表述。为了提供对该文档的上述部分的访问，需要逻辑表述。这种逻辑表述通知计算机关于文档如何在屏幕上进行逻辑显示。如上所述，“画布(Canvas)”(例如画布210)是一种可操作为提供与区相对应的逻辑布局的服务。

另一方面，窗格(例如窗格211)是与由画布210提供的逻辑布局相对应的物理屏幕布局。实际上，用户仅能看见以字符和图片形式呈现在显示屏上的文档。因此，文档必须通过用于在屏幕上描绘字符和图片的处理来呈现在屏幕上。根据由窗格211提供的物理布局，文档由画布210呈现在屏幕上。

与区209相对应的画布210是利用“Editlet服务”206来创建的。文档的DOM是利用Editlet服务206和画布210来编辑的。为了维护原始文档的完整性，Editlet服务206和画布服务210使用与区209中的一个或多个节点相对应的“方面”2022。这些服务并不直接操作区和DOM中的节点。“方面”是利用命令207来操作的。

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

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

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

4.撤消子系统

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

例如，用户可执行命令来将文档中的词语替换成另一个词语。之后，该用户可改变主意并决定保留原来的词语。撤消子系统212利用可撤消编辑(UndoableEdit)2122来支持上述操作。撤消管理器2121保存上述可撤消编辑2122的操作。

5.光标子系统

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

6.视图

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

D.词汇连接

文档处理系统的一个重要特征是，提供这样一种环境，能够将XML文档映射成另外的表述，并且在对作为映射目的的表述进行编辑时，保持其与作为映射源的XML文档的一致性。

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

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

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

词汇连接包括获取定义文件、在(所得到的定义文件的基础上在两个不同的词汇之间进行映射的能力。用某种词汇描述的文档能够映射为另外的词汇。因此，词汇连接能够通过与文档已被映射成的词汇相对应的显示和编辑插件来显示或编辑文档。

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

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

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

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

图13显示了词汇连接(VC：Vocabulary Connection)子系统300。VC子系统300提供了一种维护同一文档的两种可替换表述之间的一致性的方法。例如，两种表述可以是同一文档以两种不同词汇实现的可替换表述。如上所述，其中一种可以是源DOM树，而另一种是目的DOM树。

1.词汇连接子系统

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

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

2.连接器

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

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

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

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

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

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

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

3.目的区、窗格以及画布

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

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

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

4.词汇连接命令子系统

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

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

5.Xpath子系统

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

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

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

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

连接器树(ConnectorTree)是基于连接器的分级表述，用来表述源节点和目的节点之间的对应关系。连接器观察源节点和对源文档进行的修改。连接器随后修改目的DOM树。事实上，只有连接器是被允许修改目的DOM树的唯一对象。

E.文档处理系统中的事件流

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

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

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

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

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

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

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

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

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

F.程序调用器(ProgramInvoker)及其与其他组件之间的关系。

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

1.插件和服务

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

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

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

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

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

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

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

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

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

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

H.应用程序核心

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

为了便于在屏幕上容易地显示文档，文档管理器1081还连接到根窗格1084。剪贴板(ClipBoard)1087、快照(SnapShot)1088、拖放工具(Drag&Drop)601，以及覆盖(Overlay)602的功能也被联接到核心组件110。

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

I.在文档管理器中文档的构成

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

如图12和17(a)所示，文档管理器1081耦合到文档容器(DocumentContainer)203，文档容器203是管理所有文档1082的对象。形成工具包(例如，XML工具包)201的一部分的工具(包括DOM服务703和IO管理器(IOManager)704)也提供给文档管理器1081。再参照图17(a)，DOM服务703基于由文档管理器1081管理的文档来创建DOM树。各个文档705，不管是根文档701还是子文档702都容纳在相应的文档容器203中。

图17(b)显示了一组文档A-E是如何以分级结构排列的实施例。文档A为根文档。文档B-D是文档A的子文档。文档E则是文档D的子文档。图17(b)的左侧还显示了如何将文档的同一分级结构显示在屏幕上的实施例。作为根文档的文档A显示为基础框架。文档A的子文档B-D显示为在基础框架A内的子框架。文档D的子文档E在屏幕上显示为子框架D的子框架。

再参照图17(a)，为各个文档容器203创建撤消管理器(UndoManager)706和撤消封装器(UndoWrapper)707。撤消管理器706和撤消封装器707用来执行可撤消的命令。使用该特征，可以撤消使用编辑操作对文档所作的改变。子文档中的改变也会涉及到根文档。撤消操作考虑到了影响分级结构内其他文档的改变，并确保了在分级结构链中的所有文档之间所维护的一致性，例如，如图17(b)所示。

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

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

J.撤消命令和撤消框架

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

1.可撤消编辑命令的执行

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

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

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

简言之，文档处理系统从由在文档中包含的数据构成的二进制数据流创建DOM树。为文档中的感兴趣的并位于“区”中的一部分创建顶节点(ApexNode)，接着确定相应的“窗格”。所确定的窗格从顶节点和物理屏幕表面创建“区”和“画布”。“区”接着为各个节点创建“方面”，并为它们提供所需信息。画布创建用于呈现DOM树的节点的数据结构。

具体地，文档从存储器901载入。接着，创建文档的DOM树902。创建保持文档的相应文档容器903。接着将文档容器903联接到文档管理器904。DOM树包括根节点，并且可选地包括多个次级节点。

典型地，这种文档包括文本和图形。因此，DOM树例如能够具有XHTML子树以及SVG子树。XHTML子树具有XHTML顶节点905。同样，SVG子树具有SVG顶节点906。

在步骤1，将顶节点906联接到窗格907(窗格907是屏幕的逻辑布局)。在步骤2，窗格907向应用程序核心(即窗格所有者(PaneOwner)908)请求用于顶节点906的区工厂。在步骤3，窗格所有者908返回区工厂以及作为用于顶节点906的画布工厂的Editlet。

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

1.区的MVC

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

L.文档的表述

下面将使用图20来描述复合文档及其各种表述的实施例。在该实施例中使用的文档包括文本和图片。文本使用XHTML表述，而图片用SVG表述。图20详细显示了用于文档组件的MVC表述以及相应对象的关系。对于该示例性的表述，文档1001联接到保持文档1001的文档容器1002。文档用DOM树1003表述。DOM树1003包括顶节点1004。

顶节点用阴影圆圈表示。非顶节点用非阴影圆圈表示。用来编辑节点的“方面”用三角形表示，并被联接到相应的节点。由于文档具有文本和图片，所以用于该文档的DOM树包括XHTML部分和SVG部分。顶节点1004是XHTML子树的最顶部的节点。该顶节点被联接到XHTML窗格1005，XHTML窗格1005是文档XHTML部分的物理表述的最顶部窗格。该顶节点1004还联接到XHTML区1006，其中XHTML区1006是文档DOM树的一部分。

与节点1004相对应的“方面”1041还联接到XHTML区1006。XHTML区1006则联接到XHTML窗格1005。XHTML的Editlet创建XHTML画布1007，XHTML画布1007是文档的逻辑表述。XHTML画布1007联接到XHTML窗格1005。XHTML画布1007为文档1001的XHTML组件创建盒树1009。维护和呈现文档的XHTML部分所需的各种命令1008也被增加到XHTML画布1007。

同样，该文档的SVG子树的顶节点1010被联接到SVG区1011，SVG区1011是文档1001的DOM树的、用于表述文档的SVG组件的部分。顶节点1010被联接到SVG窗格1013，SVG窗格1013是文档的SVG部分的物理表述的最顶部窗格。表述文档的SVG部分的逻辑表述的SVG画布1012通过SVGEditlet创建，并被联接到SVG窗格(SVGPane)1013。用于将文档的SVG部分呈现在屏幕上的数据结构和命令1014被联接到SVG画布(SVGCanvas)1012。例如，这种数据结构可包括圆圈、线、矩形等，如图所示。

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

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

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

图22(a)-(c)分别显示了与插件子系统、词汇连接和连接器相关的附加细节。插件子系统被用来向文档处理系统增加功能，或与之交换功能。插件子系统包括服务代理(ServiceBroker)1041。联接到服务代理1041的区工厂服务(ZoneFactoryService)1201负责创建用于文档的部分的区。Editlet服务(EditletService)1202还被联接到服务代理1041。Editlet服务(EditletService)1202创建与区中的节点相对应的画布。

区工厂的例子是分别创建XHTML区和SVG区的XHTML区工厂1211和SVG区工厂(SVGZoneFactory)1212。如上参照示例性文档所述，文档的文本组件可通过创建XHTML区来表述，而图片则可使用SVG区来表述。Editlet服务(EditletService)的示例包括XHTMLEditlet 1221和SVGEditlet 1222。

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

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

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

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

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

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

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

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

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

O.将文件载入系统的详细例子

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

在步骤2，如图24(b)所示，根窗格(RootPane)为文档创建XTML区、“方面”和画布。创建与顶节点1403相应的窗格(Pane)1407、XHTML区(XHTMLZone)1408、XHTML画布(XHTMLCanvas)1409和盒树(BoxTree)1410。

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

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

图26显示了步骤5，在步骤5中，与MySampleXML对应的词汇创建缺省的区(DefaultZone)1601。相应的Editlet被创建并被提供给子窗格1501，以创建相应的画布。Editlet创建词汇连接画布，称为模板部分(TemplateSection)还包括连接器工厂树(ConnectorFactoryTree)。连接器工厂树创建所有的连接器，创建的连接器形成连接器树。

图27显示了步骤6，各个连接器创建目的DOM对象。一些连接器包括xpath信息。xpath信息包括一个或多个xpath表达式，xpath表达式用来确定需要被监测是否发生了改变/修改的源DOM树的子集。

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

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

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

(实施方式)

在本实施方式中，提出了用多个定义文件处理文档的技术。即，提出了将用定义文件映射源树后得到的目的树进一步用定义文件映射为别的目的树进行处理的技术。

在将定义文件多阶段应用的情况下，最终显示的、用户所看到的是最终的目的树。因此，用户对最终的目的树进行编辑操作。使该编辑操作向前段的目的树传播，最终需要准备编辑源树的结构(计划)。为此，在实施例中，扩展前提技术中所说明的VC机能，使之在多阶段应用定义文件的情况下，也能匹配各段的DOM树进行编辑。

图30(a)～(d)是用于说明将定义文件适用于多阶段的情况下的编辑方法的图。图30(a)是图29(b)所示的仅在一个阶段适用定义文件的情况下的编辑流程。文本连接器从画布(Canvas)得知对于自已所监视的目的DOM树的文本节点的编辑事件的发生(步骤1)，将该编辑事件映射为对于相应的源DOM树的编辑命令，编辑源DOM树的文本节点(步骤2)。源DOM树发布通报自己被改变的变化事件(步骤3)，收到该事件的文本连接器重新建立相应的目的DOM树，使之反映源DOM树的改变。这样，源DOM树和目的DOM树可以保持整体性和同步。

图30(b)显示了将定义文件应用于二个阶段的情况下的编辑流程。基于第一定义文件生成第一连接器树，根据第一连接器树，从源DOM树生成目的DOM树。进而，基于第二定义文件，生成第二连接器，根据第二连接器从目的DOM树1生成目的DOM树2。第一连接器和第二连接器监视映射前和映射后的对应，保持其整体性。本图中，着眼于文本连接器情况下的编辑流程。

将画布中发生的编辑事件与图29(b)同样地处理时，则第二阶段的文本连接器将接受的编辑事件映射为目的DOM树1的编辑命令，编辑目的DOM树1，但由于该编辑事件没有向第一阶段的文本连接器传达，因此不向源DOM树传播编辑。因此，看到的是文档正在被编辑的，但由于源DOM树没有改变，即使保存文档，保存的也是没有被编辑的原文档。

在本实施例中，为解决这样的问题，提出了两种新的编辑方法。第一种方法如图30(c)所示，扩展两个阶段以后的文本连接器的功能，接收的编辑事件不向编辑命令映射，使之保持发布编辑事件的功能。即，扩展文本连接器在接收到编辑事件(步骤1)时，不编辑自身能够编辑的DOM树(图30(c)的例子中为目的DOM树1)，而变换为对于前段的DOM树(图30(c)的例子中为源DOM树1)的编辑事件(步骤2)，流向前段的画布(Canvas)(在图30(c)的例子中，为第一段的文本连接器)(步骤3)。这样，画布上发生的编辑事件依次向前段回溯传达，最终到达第一段的文本连接器。第一段的文本连接器将接收到的编辑事件映射为对源DOM树的编辑命令，编辑源DOM树(步骤4)。源DOM树被编辑时，与前提技术同样地与文档生成时同方向地依次反映变更。即，从源DOM树获取变化事件的第一文本连接器(步骤5)，重新建立目的DOM树1(步骤6)，进而从目的DOM树1获取变化事件的扩展文本连接器(步骤7)，重新建立目的DOM树2(步骤8)。这样，画布上发生的编辑被全都反映到DOM树上，显示被更新。

该扩展文本连接器可为另外准备的文本连接器，也可在文本连接器中作为扩展功能进行添加。前者的情况下，给以与描述定义文件时的指令不同“text-of”的命名。定义文件的制作者在完成第二阶段以后的定义文件时，对于要使编辑反映到源DOM树的节点，如同使用了扩展文本连接器指令。后者的情况下，VC单元80判断指定的变换前的DOM树是源DOM树还是目的DOM树，如果是源DOM树，向编辑命令映射，如果是目的DOM树，则发布编辑事件即可。

第二种方法如图30(d)所示，当不是源DOM树，而是某种的目的树被编辑的情况下，设置成使该编辑向反方向传播，向源DOM树反映的结构。这里，将具有该功能的新结构称为“ReverseConnector”。ReverseConnector保持是否将变换前的DOM树(图30(d)的例中为目的DOM树1)的改变向变换后的DOM树(在图30(d)的例子中为源DOM树)的某一节点反映的对应关系。该对应关系既可以由定义变换前的DOM树向变换后的DOM树的映射的定义文件同时给出，也可由显示从变换后的DOM树向变换前的DOM树的逆方向的对应关系的其他定义文件给出。为了使变换后的DOM树的改变确实向变换前的DOM树传播，优选将变换前的DOM树的各节点和变换后的DOM树的各节点一一对应。

以下，关于上述两种编辑方法，提出具体的实施例进行进一步说明。

第一实施例

对图30(c)所示的第一种方法进一步进行说明。用第一定义文件将某词汇(源树)映射为第一目的树。需要利用多种定义文件将该第一目的树作为目的树使用。但是，由于第一目的树的显示模板的制作比较困难，所以用第二定义文件准备第一目的树的显示。在此情况下，编辑逻辑由第一定义文件提供。

对第二定义文件有如下限制。

●不能使用“text-of”等直接编辑的模板。但是，可以使用上述“扩展text-of”模板。

●不能使用“set-text”等编辑源树的指令。

●可以使用能够对源树发布事件的特殊的指令。

这样，不对第一目的树直接进行编辑。另外，能够从第一目的树发布事件。即，在第一定义文件中，能够描述在第一目的树中发生的事件的处理。

假定列举英语单词及其日文翻译的单词本词汇。为了对此进行表示，希望利用排列卡片的表示。通常这样的排列卡片的表示能够用XHTML进行描述，由于排列卡片的方法可用于各种场合，因此做出卡片词汇，单词本词汇向卡片词汇映射。

卡片词汇的样式如下。

●纵向排列卡片

●卡片内容只有文本

●卡片内容不能编辑

●只发送删除(除去)卡片的事件

图31显示了用单词本词汇描述的文档的例子。图32是由卡片词汇描述的文档的例子。图33显示了第二定义文件的例子。图34显示了第一定义文件的例子。另外，为简化起见，在这些例子中，省略了XML声明及命名空间声明等。

图33所示的第二定义文件在由图32所示的卡片词汇描述的文档中，将“card：card”元素的各种元素值用框围起来，按卡片形状沿纵向排列显示。“card：card”元素的模板中描述了该元素中的事件发生时的动作。具体地说，描述了这样的情况：在该元素中有插入(caret)符号时，如果发生按下删除键的事件，则会对与该元素对应的变换前的元素发布事件名为“card：card-delete”的事件。

在图34所示的第一定义文件中，在“单词本：单词”元素的模板中描述了该元素被映射到“card：card”元素的情况，而且描述了该元素中发生事件时的动作。具体地说，描述了：如果对该元素发生了事件名为“card：card-delete”的事件，则发布把对应的变换前的元素删除的编辑命令。

图35显示了图31所示的文档由图34所示的定义文件和图33所示的定义文件变换为两个阶段显示的屏幕。“单词本：单词”元素映射为“card：card”元素，接着，变换为带“border”的“div”元素，由HTML单元50以卡片的形式进行显示。

在该画布上，在某卡片被聚焦时，如果发生“删除键被按下”的事件，首先，第二定义文件生成的连接器树(VC画布)将其变换为“card：card-delete”事件，对与“删除键被按下”事件发生的目的DOM树2的节点(html：div)对应的目的DOM树1的节点(card：card)，发布“card：card-delete”事件。接着，第一定义文件生成的连接器树(VC画布)将其变换为对应的源DOM树的节点“单词本：单词”的删除命令，从源DOM树删除“单词本：单词”元素。如果源DOM树被改变，则发布变更事件，由于第一目的DOM树会被重新建立，对应的“card：card”元素被删除。接着，从第一目的DOM树发布变化事件，由于第二目的DOM树会被重新建立，因此对应的“div”元素被删除。这样，1枚卡片从图35所示的显示屏幕中消失了。

(第二实施例)

对图30(d)所示的第二方法进一步加以说明。它是将某词汇由定义文件来编辑。这里，由于与该词汇的结构非常相似的词汇在其他地方已经考虑了很多，因此，一旦变换成抽象的词汇，即用第二定义文件对该抽象词汇进行编辑，并且抽象词汇的编辑向原来的词汇传达。另外，用第一定义文件进行向抽象词汇的映射。在这种情况下，编辑逻辑由第二定义文件提供。

为了将对作为抽象词汇的第一目的树的编辑反映到源树，要使源树的节点与第一目的树的节点一一对应。这样，第一目的树的直接编辑就可传播到源树。也可以用硬编码插件将原来不是XML的源映射为抽象词汇，并将抽象词汇的编辑反映到源。例如，将温度计、湿度计等获取外部环境的传感器连接到主装置上，将各传感器的输出通过输入输出装置存储到DOM的节点中。也可将该源树映射为抽象词汇。例如，将空调的设定温度存储到源树的节点中时，如果用户通过第一目的树将该节点改变为“30℃”，则可将其传达给空调，从而设定温度为30℃。

显示目录的DirML是用于显示本地文件系统上的目录或webDav上的目录等各种存储目录结构时所讨论过的词汇。DirML可由定义文件编辑。如果进行DirML的编辑，如同实际上对文件系统进行了改变一样，会安装各种的存储用的硬编码的插件。即，DirML作为抽象词汇，具有将实际的存储和XML(DirML)连接起来的硬编码插件。这里，如果发生了访问某数据库的要求时，结果该数据库会以XML(DB-result ML)形式返回文档一览，由于这与DirML非常相似，操作也基本相同，因此可以原样使用DirML。这可以通过准备使DB-resultXML与DirML对应的定义文件来解决。

图36显示了用DB-result XML描述的文档的例子。图37显示了将DB-result XML描述的文档映射为DirML的定义文件的例子。图38显示了用图37的定义文件映射图36的文档的结果。在这种情况下，图37的定义文件在描述图36所示文档向图38所示文档的变换所用的元素的对应关系的同时，也要描述用于将图38所示文档的变更反映至图36所示文档的变更的元素间的对应关系。ReverseConnector保持这些对应关系，将目的DOM树的变更反映到源DOM树。

在该例中，由于源DOM树和目的DOM树是一一对应的关系，ReverseConnector只要用与对目的DOM树1进行的编辑同样的编辑改变源DOM树即可。源DOM树和目的DOM树1不完全一一对应也可以，在这种情况下，对目的DOM树1的编辑不允许任意的编辑，只能固定地进行某种特定的编辑。并且，有必要保持其对应关系，使ReverseConnector关于对目的DOM树1的设定的编辑能够确实反映到源DOM树。

在本实施方式中，显示了根据两个定义文件进行两阶段映射的例子，也可以应用三个以上的定义文件进行三阶段以上的映射。在这种情况下，可以组合第一种方法和第二种方法，实现多阶段映射。即使是将定义文件应用于多阶段映射的情况下，对最后阶段的画布的事件也会使用第一方法作为编辑事件向前段通报，直至某阶段的DOM树。在中间阶段中，变换成编辑命令的DOM树被编辑时，可以用第二种方法将改变反映到其前一段的DOM树上。即，从被编辑的DOM树开始，与正方向生成文档时相同，重新建立DOM树，通过ReverseConnector将变换向反方向反映。

以上，通过实施方式对本发明进行了说明。本领域的普通技术人员应该理解，实施方式仅为示例，本发明还存在对各构成元素或各处理过程进行组合的各种各样的变形实施例，这些变形实施例也包含在本发明的范围内。

在实施方式中，对处理XML文档的例子进行了说明，但本实施方式的文档处理装置20同样也可以处理以其他标记语言例如SGML、HTML等描述的文档。

产业上利用的可能性

本发明可以用于处理利用标记语言结构化的文档的文档处理装置。

Claims (10)

1.文档处理装置，其特征在于，包括：

第一连接器单元，在获取由第一标记语言描述的第一文档时，将所述第一文档映射为由不同于所述第一标记语言的第二标记语言描述的第二文档，监视作为映射源的所述第一文档和作为映射目的的所述第二文档的对应关系，保持其整体性；

第二连接器单元，将所述第二文档映射为由不同于所述第二标记语言的第三标记语言描述的第三文档，监视作为映射源的所述第二文档和作为映射目的的所述第三文档的对应关系，保持其整体性；和

处理系统，将所述第三文档进行布局和显示，接收来自用户的编辑操作。

2.如权利要求1所述的文档处理装置，其特征在于，还包括获取单元，获取描述了将所述第一文档映射为所述第二文档的规则的第一定义文件，和描述了将所述第二文档映射为所述第三文档的规则的第二定义文件，

所述第一连接器单元基于所述第一定义文件生成，所述第二连接器单元基于所述第二定义文件生成。

3.如权利要求1或2所述的文档处理装置，其特征在于，所述处理系统接收到用户对所述第三文档的编辑操作时，所述第二连接器单元将所述第二文档中与成为所述第三文档的所述编辑操作对象的部分对应的部分确定为编辑对象，所述第一连接器单元将所述第一文档中与成为所述第二文档的编辑对象的部分对应的部分确定为编辑对象。

4.如权利要求1至3任一项所述的文档处理装置，其特征在于，

所述处理系统接收到用户对所述第三文档的编辑操作时，对所述第二连接器单元发布所述第二文档的编辑事件，

所述第二连接器单元从所述处理系统获取所述编辑事件时，对所述第一连接器单元发布对应于该编辑事件的所述第一文档的编辑事件，

所述第一连接器单元获取所述编辑事件时，发布对与该编辑事件对应的所述第一文档的编辑命令，以编辑所述第一文档，

所述第一连接器单元获取所述第一文档的变更通知时，重新建立所述第二文档，以反映所述第一文档的变更，

所述第二连接器单元获取所述第二文档的变更通知时，重新建立所述第三文档，以反映所述第二文档的变更，

所述处理系统获取所述第三文档的变更通知时，对所述第三文档重新布局进行显示。

5.如权利要求4所述的文档处理装置，其特征在于，描述用于将所述第二文档映射为所述第三文档的规则的第二定义文件进一步描述用于将对于所述第二文档发布的编辑事件变换为对于所述第一文档的编辑事件的规则。

6.如权利要求1至3任一项所述的文档处理装置，其特征在于，所述处理系统接收到用户对所述第三文档的编辑操作时，发布与该编辑事件对应的所述第二文档的编辑命令，编辑所述第二文档，

所述第一连接器单元获取所述第二文档的变更通知时，将所述第二文档的变更反映于所述第一文档，

所述第二连接器单元获取所述第二文档的变更通知时，重新建立所述第三文档，反映所述第二文档的变更，

所述处理系统在获取所述第三文档的改变时，对所述第三文档重新布局进行表示。

7.如权利要求6所述的文档处理装置，其特征在于，描述用于将所述第一文档映射为所述第二文档的规则的第一定义文件进一步描述用于将所述第二文档的变更反映到所述第一文档的规则。

8.如权利要求6所述的文档处理装置，其特征在于，所述第一连接器单元参照描述了用于将所述第二文档的变更反映到所述第一文档的规则的第三定义文件，将所述第二文档的变更反映到所述第一文档。

9.文档处理方法，其特征在于，包括以下步骤：

多次循环进行将标记语言描述的文档映射为其他标记语言描述的文档的步骤，生成三个以上的不同文档；

显示生成的文档中最后阶段的文档；

在获取了对所述最后阶段文档的编辑操作时，发布对应于其编辑操作的前段文档的编辑事件；

将对于后段文档的所述编辑事件变换为对于对应的前段文档的编辑事件，使编辑事件向前段传播；

将对于预定的阶段的文档的编辑事件变换为对该文档的编辑命令，编辑该文档；

将已编辑的文档的变更反映于其他文档。

10.计算机程序，其特征在于，所述计算机程序使计算机实现以下功能：

在获取了由第一标记语言描述的第一文档时，将所述第一文档映射为由不同于所述第一标记语言的第二标记语言描述的第二文档，监视作为映射源的所述第一文档与作为映射目的的所述第二文档的对应关系，保持其整体性，和

将所述第二文档映射为由不同于所述第二标记语言的第三标记语言描述的第三文档，监视作为映射源的所述第二文档和作为映射目的的所述第三文档的对应关系，保持其整体性，和

将所述第三文档布局并显示，接收来自用户的编辑操作的功能。

Images