CN101268438A - 数据处理装置 - Google Patents

Abstract

简易地设计用于编辑结构化文档文件的用户界面屏幕。从定义源文件元素结构的模式文件生成绑定文件。通过绑定文件设计用于编辑源文件的显示布局，其结果作为布局文件保存。用户还可以编辑布局文件。从布局文件和绑定文件生成XSLT文件，生成定义文件以从XSLT文件生成用于编辑源文件的用户界面屏幕。

Description

数据处理装置

技术领域

本发明涉及文档处理技术，特别涉及用于处理由标记语言描述的结构化文档文件的技术。

背景技术

XML作为适于通过网络等与他人共享数据的形式备受关注，用于创建、显示和编辑XML文档的应用程序(例如，参照专利文献1)目前被开发出来。XML文档是根据由文档类型定义等定义的词汇(标签集)创建的。

专利文献1：日本未决的专利申请No.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示出了利用定义文件生成单元创建的屏幕布局的另一个实施例；

图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是用于说明根据示例性实施方式的定义文件生成过程的示意图；

图31示出了根据示例性实施方式的模式文件；

图32示出了与图31的模式文件对应的源文件；

图33示出了根据图31的模式文件和图32的源文件生成的定义文件；

图34示出了绑定文件的编辑屏幕；

图35示出了根据图34中的绑定文件的编辑结果形成的布局文件的编辑屏幕；

图36是用于根据图35中的编辑结果显示的目标文件的屏幕图；

图37示出了绑定文件的编辑屏幕的另一实施例；

图38示出了根据图37中的绑定文件编辑结果形成的布局文件的编辑屏幕；

图39是显示根据图38中的编辑结果形成的目标文件的屏幕图；

图40示出了用于绑定文件的编辑屏幕的另一实施例；

图41示出了根据图40中的绑定文件编辑结果形成的布局文件编辑屏幕；

图42是根据图41中的编辑结果显示目标文件时的屏幕图；

图43示出了用于绑定文件的编辑屏幕的另一实施例；

图44示出了用于根据图43中的绑定文件的编辑结果形成的布局文件的编辑屏幕；

图45是根据图44中的编辑结果显示目标文件时的屏幕图；以及

图46是用于进一步说明定义文件生成过程的示意图。

符号说明

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

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

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

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

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

60SVG单元             80VC单元           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文档的内容，并且载入与所确定的词汇对应的用于显示和编辑的插件，从而执行显示和编辑。例如，在文档处理装置20中，对HTML文档进行显示和编辑的HTML单元50、以及对SVG文档进行显示和编辑的SVG单元60等被实现为用于各词汇(标签集)的显示系统和编辑系统的插件，以分别在对HTML文档进行编辑时载入HTML单元50，和在对SVG文档进行编辑时载入SVG单元60。如以下将描述的那样，在要对既包括HTML又包括SVG组件的复合文档进行处理时，既载入HTML单元50又载入SVG单元60。

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

编辑单元24通过用户界面从用户处接收编辑指令的事件。编辑单元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的呈现引擎，并用来显示利用CSS设置的以诸如HTML等的词汇描述的文档。

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能够将以某词汇描述的文档映射为另一给定词汇，从而提供了一种能够通过与被映射的词汇相对应的显示或编辑插件来显示或编辑文档的框架。在本前提技术中，该功能被称为VC(Vocabulary Connection，词汇连接)。定义文件获取单元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功能，而不使用源显示和树显示的其它显示方法来显示该文档。也就是说，通过准备定义文件，使得成绩管理词汇可映射为已具有插件的另一词汇，例如HTML或SVG。下面将要进行的说明是在假设已经具备了定义文件的情况下进行的，不过对于用户本身用以创建定义文件所必需的用户界面将在后面描述。

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

图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和圆形图93用于显示以成绩管理词汇描述的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文档而被处理。在这种情况下，被插入的属于其它词汇的标签可使用定义文件来进行映射。例如，在XHTML文档中，可使用诸如“重要”和“最重要”的标签以通过强调的方式来显示这些标签周围的部分，或者可将这些标签按重要性的顺序来排序以进行相应显示。

当用户在图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.概要

由于因特网的出现，由用户处理、管理的文档的数量大致是成指数函数形式在增加。形成因特网核心的Web(World Wide Web：万维网)成了接受这些文档数据的大容器。除了文档以外，Web还提供用于这些文档的信息检索系统。这些文档通常是由标记语言描述的。作为标记语言的简单且常用的例子，HTML(HyperText Markup Language：超文本标记语言)是其中的一个。这样的文档还包括有指向记录在Web的其它位置的其他文档的链接。XML(eXtensible Markup Language：可扩展标记语言)是更高度普及的标记语言。用于访问和阅览Web文档的简单的浏览器是由像Java(注册商标)那样的面向对象的编程语言开发的。

由标记语言描述的文档通常在浏览器或者其他应用程序中以树数据结构的形式来表现。该结构相当于对文档进行语法分析结果的树。DOM(Document Object Model：文档目标模型)是用于表述和操作文档的、众所周知的基于树的数据结构模型。DOM提供表述含有HTML或XML文档等的对象集合。DOM包括两个基本组件，即表述文档内的组件的对象是如何连接在一起的标准模型，以及用于对这些对象进行访问或者操作的标准界面。

应用程序的开发者能够支持DOM作为与其自身的数据结构或者API(Application Program Interface：应用程序界面)的界面。另一方面，创建文档的应用程序的开发者可以使用DOM的标准界面而不是其自身的API的特定界面。因此，DOM提供标准界面的能力有效地促进了在各种环境下对文档进行共享，特别是用在Web上。DOM定义有几个版本，根据不同的编程环境及应用程序来使用。

DOM树是基于对应DOM的内容的文档的分级表述。DOM树包括“根”及由根生出的一个以上的“节点”。根有时表述全体文档。中间节点可表述元素，诸如表及表中的行和列。DOM树的“叶”通常表述数据，例如不可进一步分解的文本或者图像。DOM树的各个节点也可以与描述字形、大小、颜色、索引等由节点所表示的元素的参数的属性关联对应。

虽然HTML是一般的用于创建文档所使用的语言，但它是用于格式和布局的语言而不是用于描述数据的语言。表现HTML文档的DOM树的节点是预先定义作为HTML的格式化标签的元素。通常，由于HTML不提供用于数据的详述或者对数据添标签/添标注的功能，因而对HTML文档中的数据的查询格式化在很多场合是困难的。

网络设计者们的目标是，能够把Web上的文档通过软件应用程序进行查询或者处理。与显示方法无关，只要是分级结构化的语言，可以同样查询处理。诸如XML(eXtensible Markup Language)这样的标记语言可以提供这类特征。

众所周知，与HTML相反，XML的优点是文档的设计者可以使用可自由定义的“标签”对数据元素进行标注。这样的数据元素可以分级进行结构化。而且，XML文档可以包含文档类型定义，它描述文档内使用的标签及其相互关系的“语法”。为了定义结构化的XML文档的显示方法，使用CSS(Cascading Style Sheet：层叠式样式表)或者XSL(XML StyleLanguage：可扩展标记语言样式语言)。关于DOM、HTML、XML、CSS、XSL及其有关语言特征的附加信息也可以从Web获得。(例如，http://www.w3.org/TR/)

Xpath为了指定XML文档部分的位置，提供共同的语法及语义。作为功能性的示例，是对应于XML文档的DOM树的遍历(移动)。这提供了用于操作XML文档的各种表述所关联的字符串、数字及布尔型字符的基本功能。Xpath不是XML文档表现的语法(例如作为文本来看时是第几行或者是第几字符这样的语法)，而是在DOM树等抽象的、逻辑的结构中操作。通过使用Xpath，例如，可以通过XML文档的DOM树内的分级结构来定位。除了用于寻址的用途之外，XPath还被设计用来测试DOM树中的节点是否与某个模式相匹配。涉及XPath的细节可在http://www.w3.org/TR/XPath中找到。

希望有一种有效的文档处理系统，能够利用XML的已知的优点和特征，处理由标记语言(例如XML)描述的文档，并能够提供一种用于创建和修改文档的友好的用户界面。

在此说明的系统的构成中的一些将通过使用被称作MVC(Model-View-Controller：模型-视图-控制器)即众所周知的GUI(Graphical UserInterface：图形用户界面)范例进行说明。MVC范例将应用程序或应用程序的界面的一部分分解为三部分，即，模型、视图和控制器。最初开发MVC是为了将传统的输入、处理和输出任务分配到GUI区域。

输入->处理->输出

控制器->模型->视图

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

B.文档处理系统的总配置

文档处理系统的实施例将结合图11-29进行清楚说明。

图11(a)图示了包括将在下面描述的能够提供文档处理系统的、根据现有技术的基础功能的配置结构。装置10包括通过通信路径13连接到存储器12的CPU形式或微处理器等形式的处理器11。存储器12可为当前或将来能够使用的任意ROM和/或RAM形式。通信路径13作为典型的总线而设置。对于鼠标、键盘和语音识别系统等用户输入装置14以及显示装置15(或者其他用户界面)的输入输出界面16也连接在用于处理器11和存储器12通信的总线上。该结构可以是独立的形式，也可以是由多个终端以及一台以上的服务器连接的网络化的形式，也可以由公知的任何方式来构成。本发明并不受这些组件的配置、它们的集中式或分布式体系结构或者多种组件的通信方式的限制。

此外，本系统以及在此讨论的实施例将作为包括提供各种功能性的若干组件以及子组件的例子来讨论。为了提供期望的功能，这些组件以及子组件可以是硬件和软件的组合，也可以仅由硬件或者仅由软件来实现。而且，硬件、软件及其组合可以由通用计算装置、专用硬件或者它们的组合来实现。因此，组件或者子组件的构成包括执行用于提供组件或者子组件功能的专用软件的通用/专用的计算装置。

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

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

1.执行环境

执行环境101的关键组件是程序调用器(ProgramInvoker，即程序启动单元)103。程序调用器103是用于启动文档处理系统而被访问的基本程序。例如，当用户登录并启动文档处理系统时，程序调用器103被执行。程序调用器103例如可以读取并执行作为插件增加至文档处理系统的功能、启动并运行应用程序、以及读取与文档相关的属性。程序调用器103的功能并不限于此。

当用户希望启动计划在执行环境中运行的应用程序时，程序调用器103找到并启动该应用程序，然后执行该应用程序。

在程序调用器103上联接有插件子系统104、命令子系统105以及资源模块109等若干组件。这些构成将随后进行更详细描述。

a)插件子系统

插件子系统104能够高度灵活和有效地向文档处理系统增加功能。插件子系统104也可以用来修改和去除文档处理系统中存在的功能。此外，可使用插件子系统增加或修改多种功能。例如，可以增加编辑功能(Editlet：编辑单元)以起到支持在屏幕上呈现文档的作用。编辑插件也支持对增加至系统的词汇进行编辑。

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

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

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

b)命令子系统

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

命令可具有相关功能，例如是下面将要详细记述的“撤消”功能。这些功能可分配给用来创建对象所使用的若干个基类。

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

可由命令调用器(CommandInvoker)1051执行的命令的类型包括但不限于：可撤消命令(UndoableCommand)1054、异步命令(AsynchronousCommand)1055以及词汇连接命令(VCCommand)1056。可撤消命令1054是那些如果用户希望就能够撤销其结果的命令。可撤消命令的示例为：剪切、复制、插入文本等。在操作中，当用户选择文档的一部分并对该部分应用剪切命令时，如果需要，通过使用可撤消命令，可使被剪切的部分恢复至其未被剪切的状态。

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

异步命令1055是用于文档的载入或保存等基于系统的命令，与可撤消命令或词汇连接命令不同，是异步执行。由于异步命令不是可撤消命令，所以其执行的结果不能取消。

c)资源

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

2.应用程序组件

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

a)用户应用程序

用户应用程序106连同程序调用器103一起被载入到系统中。用户应用程序106是将文档、文档的各种表述以及与文档进行交互所需的用户界面结合在一起的“粘合剂”。例如，用户可能希望创建作为项目的一部分的一套文档。载入这些文档后，将创建用于文档的适当表述。用户界面功能作为用户应用程序106的一部分被追加。换言之，用户应用程序106既保持文档的表述也保持文档的各种形式，这些文档的表述使用户能够与形成项目的一部分的文档进行交互。一旦创建了用户应用程序106，每当用户希望与形成项目一部分的文档进行交互时，用户就能够简单地将用户应用程序106载入到执行环境中。

b)核心组件

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

如图11(c)所示，屏幕的物理布局也具有树型形式。因此，窗格可被实现为根窗格(RootPane)1084，也可以为子窗格(SubPane)1085。根窗格1084是位于窗格树的根部的窗格，而子窗格1085是除了根窗格1084之外的任何窗格。

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

c)应用程序核心

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

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

接着，也对快照实用程序1088进行说明。快照实用程序1088在应用程序从一个状态变为另一状态时，能够记住应用程序的当前状态。

d)用户界面

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

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

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

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

文档管理器1081包括文档容器(DocumentContainer)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树的子树。这种子树包括区(Zone)。在特定实施例中，标签集的边界由区来限定。区209是利用被称为“区工厂”205的服务创建的。如上所述，区209是对表述文档的DOM树的一部分的内部表述。为了提供对该文档的上述部分的访问，需要逻辑表述。这种逻辑表述通知计算机如何在屏幕上对文档进行逻辑显示。画布(Canvas)210是一种可操作为提供与区相对应的逻辑布局的服务。

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

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

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

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

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

4.撤消子系统

如上所述，人们希望对文档的任何改变(例如，编辑)都可撤消。例如，用户可执行编辑操作，然后决定撤消该改变。参照图12，撤消子系统212是文档管理器的可进行撤消操作的组件。撤消管理器(UndoManager：撤销管理单元)2121保存可被用户撤消的、对文档执行的所有操作。例如，用户可执行命令来将文档中的词语替换成另一个词语。之后，该用户可改变主意并决定保留原来的词语。撤消子系统212协助上述操作。撤消管理器2121保存上述可撤消编辑(UndoableEdit：可撤消编辑)2122的操作。

5.光标子系统

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

6.视图

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

D.词汇连接

文档处理系统的一个重要特征是提供一种环境，该环境能够把XML文档映射为其他表述来处理，而且对映射后的表述编辑时，将该编辑反映到源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的文档相对应的适当的词汇连接画布(VCCanvas)310。使用词汇连接301，根据转换规则，对源DOM树的区209的改变被传递到另一DOM树306的相应区。转换规则以词汇连接描述符(Vocabulary Connection Descriptor：VCD)的形式给出。对于与源DOM和目的DOM之间的这种转换相对应的各个VCD文件，创建相应的词汇连接管理器(VCManager)302。

2.连接器(Connector)

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

连接器304被逻辑地链接在一起以形成树结构。连接器304形成的树被称为连接器树(ConnectorTree)。连接器304通过一种服务(Service)而创建，该服务被称为连接器工厂(ConnectorFactory：连接器生成单元)303的服务。连接器工厂303从源文档创建连接器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)提供词汇插件。词汇插件与目标词汇关联使用。它们提供了一种使用词汇连接描述符在词汇之间进行映射的方式。

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

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

3.目的区(DestinationZone)、窗格(Pane)以及画布(Canvas)

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

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

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

4.词汇连接命令子系统

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

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

5.XPath子系统

XPath子系统316是文档处理系统的一个重要组件，它有助于实现词汇连接。连接器304通常包括XPath信息。如上所述，词汇连接的任务之一是将源DOM树的变化反映到目的DOM树中。XPath信息包括一个或多个XPath表述，用来确定对改变/修改加以监视的源DOM树的子集。

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

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

另一方面，如已在前面结合词汇连接描述的，目的DOM树是通过映射转换后以不同词汇表述的文档的DOM树或区。目的DOM树中的节点被称为目的节点。

连接器树是基于用来表述源节点和目的节点之间的对应关系的连接器的分级表述。连接器监视源节点和对源文档进行的修改，修改目的DOM树。连接器是被允许修改目的DOM树的唯一对象。

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

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

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

在多数场合，使用“事件(Event)”类来进行处理，其中事件类获取所有用户创建事件的基本特性。

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

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

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

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

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

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

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

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

1.插件和服务

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

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

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

已经描述的向文档处理系统增加功能的插件，可以看作是由几个服务提供器402和与其相关的类构成的单元。各个插件都具有在定义文件中记载的从属关系和服务种类401。

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

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

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

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

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

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

H.应用程序核心

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

为了便于在屏幕上显示文档，文档管理器1081还连接到根窗格(RootPane)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耦合到文档容器203，文档容器203是管理所有文档1082的对象。形成包括DOM服务(DOMService)703和IO管理器(IOManager)704的工具包201(例如，XML工具包)的一部分的工具也提供给文档管理器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(UndoManager：撤消管理单元)和撤消封装器(Undo Wrapper)707。撤消管理器706和撤消封装器707用来执行可撤消的命令。使用该特征，可以撤消使用编辑操作对文档所作的改变。子文档中的改变也会涉及到根文档。撤消操作考虑到对分级结构内其他文档产生影响的改变，例如，如图7(c)所示，确保维护在分级结构链中的所有文档之间的一致性。

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

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

J.撤消命令和撤消框架

图18(a)和18(b)进一步详细地显示了撤消框架和撤消命令。如图18(a)所示，撤消命令(UndoCommand)801、重做命令(RedoCommand)802和可撤消编辑命令(UndoableEditCommand)803是能够排列在如图11(b)所示的命令调用器1051中的命令，并且被顺序执行。可撤消编辑命令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顶节点(ApexNode)905。同样，SVG子树具有SVG顶节点906。

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

在步骤4，窗格907创建区909，区909联接至窗格907。在步骤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树包括顶节点1004。

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

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

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

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

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

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

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

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

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

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

图22(c)提供了有关连接器的进一步的细节。连接器工厂303从源文档中创建连接器。连接器工厂303与词汇、模板和元素模板联接，并分别创建词汇连接器(VocabularyConnector)模板连接器(TemplateConnector)和元素连接器(ElementConnector)。

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

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

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

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

下面将解释与特定文档相关的处理。名为“MySampleXML”的文档被载入到文档处理系统。图23显示了用于“MySampleXJML”文件的使用词汇连接管理器及连接器工厂树(ConnectorFactoryTree)的VCD脚本的实施例。

在图中显示了脚本文件内的词汇部分、模板部分以及在词汇连接管理器中的相应组件。在标签“vcd:vocabulary”下提供了属性“match”为″sample:root″，“label”为″MySampleXML″，以及“call-template”为″sampleTemplate″。

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

O.将文件载入系统的方法的详细实施例

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

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

在步骤3，如图24(c)所示，在发现XHTML区所不理解的标签“sample:root”后，从XHTML画布上的区域创建子窗格。

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

图26显示了步骤5，在步骤5中，与“MySampleXML”对应的词汇创建缺省区(DefaultZone)1061。创建相应的Editlet并提供创建相应的画布的子窗格1501。Editlet创建词汇连接画布。接着，词汇连接画布调用包括连接器工厂树的模板部分(TemplateSection)。连接器工厂树创建将构成连接器树的所有的连接器。

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

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

图29(a)显示了只是存在于目的树上的节点上发生时的事件流，而不具有相应的源节点。如鼠标事件和键盘事件等由画布所获取的事件是通过目的树而被传递到元素模板连接器(ElementTemplateConnector)。元素模板连接器不具有相应的源节点，因此被传送的事件并不是对源节点的编辑操作。如果所传送的事件与命令模板(CommandTemplate)中描述的命令相匹配，则元素模板连接器执行相应的动作。如果没有相匹配的命令，则元素模板连接器忽略所传送的事件。

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

(实施方式)

根据本实施方式的数据处理装置包括前提技术中说明的文档处理装置20的功能作为其一部分，并能够由前提技术中说明的词汇连接器简易生成表示源树和目的树的对应关系的定义文件。首先，在图30中概述了根据本实施例方式的定义文件生成过程，接着参照图31及其之后的图主要详细描述显示模式。

图30是用于说明本实施方式的定义文件生成过程的示意图。数据处理装置获取要编辑的XML文档文件(以下称作“源文件”)、和用来定义源文件的元素结构的模式文件。这里所说的模式文件是指根据XML-Schema、DTD(Document Type Definition，文档类型定义)等规范描述。作为生成物的定义文件用于生成为了编辑该源文件而具备适当的显示布局信息的目标文件。目标文件可以说是前提技术中描述的文件化的目标树。

当有模式文件时，数据处理装置从模式文件生成绑定文件(BindingFile)。绑定文件用于编辑目标文件中的显示布局。如果没有模式文件，数据处理装置则从源文件本身抽出元素及其结构来生成绑定文件。这种情况下，数据处理装置以树遍历的方式，从源文件的根元素抽出子元素，从而抽出元素及其构造。此外，可由绑定文件重定义与源文件元素相关的规则。例如，在从源文件生成绑定文件的情况中，源文件中的元素A具有四个子元素B。此时，绑定文件中记载了表示元素A可具有的子元素B的个数是4个的规则。用户通过绑定文件提供的方法，可重定义该元素A和子元素B相关的规则，例如，元素A可具有的子元素B的个数也可以定义为1～10。即使在从模式文件生成绑定文件的情况下，在模式文件中定义的规则范围内，也可以重定义这种与元素相关的规则。由此，绑定文件还提供与元素相关的规则、和用于定义规则的功能。在下文中，以从模式文件获取表示源文件元素结构的模式信息进行说明。

用户可使用数据处理装置编辑绑定文件。通过GUI(Graphical UserInterface，图形用户界面)，用户可在绑定文件中设定目标文件的基本显示布局。由此，通过将绑定文件定义的显示布局信息应用到模式信息的各元素创建布局文件。布局文件是表示模式文件中包括的各元素的具体显示布局的HTML文件。此外，布局文件并非局限于由标记限定结构的结构化文档文件类型，只要是包括布局信息的文件即可，例如表计算应用程序、用于呈现的应用程序。用户通过编辑布局文件，可进一步精致地编辑显示布局。在本示例性的实施方式中，使用绑定文件进行目标文件显示布局的基本设定，而使用布局文件对目标文件显示布局进行详细设定。

根据绑定文件所示的元素和布局文件显示区域之间的对应关系生成XSLT文件，以决定源文件和目标文件之间的数据变换形式。最后，根据该XSLT文件生成定义文件，该定义文件表示与绑定文件对应的源文件、和与布局文件对应的目标文件之间的对应关系。下面以用户界面为中心说明它们的处理流程。

图31示出了该实施方式的模式文件。该图中所示的模式文件描述了后述的图32所示源文件应遵循的与元素结构相关的规则。另外，该模式文件是按照XML-Schema描述的。在图31中，例如在从上第3行中对名为“customerList”的元素定义其数据型是“CustomerListType”。在下行中，“custmerListType”数据型在各自的名称空间“sfa”中被定义为包括“listID”、“totalEstimate”、“totalNumber”、“customer”四个子元素。并且，“customer”元素的数据型是“customerType”，还定义了其内容。另外，“customer”元素的个数定义为0个以上。源文件必须按照模式文件所示规则描述。由于模式文件是用于规定源文件中包括的各元素数据型和结构的文件，因此相比于源文件本身，更容易理解与元素间结构相关的规则。

图32示出了与图31的模式文件对应的源文件。在该源文件中，作为“customerList”的子元素定义了“listID”、“totalNumber”、“totalEstimate”以及“customer”。另外，这些元素中包括值。包括三个“customer”元素。

图33示出了根据图31的模式文件和图32的源文件生成的定义文件。图33显示了定义文件的一部分。在该图所示的定义文件中，描述了用于将源文件中的各元素(例如，“sfa:customerList/sfa:listID”和“sfa:customerList/sfa:totalNumber”)变换为XHTML形式的目标文件的规则。该实施方式的数据处理装置可在直观的用户界面中简易生成该定义文件。

图34示出了绑定文件的编辑屏幕。数据处理装置使从模式文件生成的绑定文件以图31所示的规定形式进行图像显示。在图34下部区域(下面称作“属性区域”)中，模式文件中的各元素被以树形结构的方式显示，并且例如其数据型也可编辑地显示。在属性区域中，通过选中接近于元素名的复选框能够展开显示其子元素。根据这种方式，即使当模式文件中定义了庞大数量的元素时，也可以仅显示要编辑的元素。

数据处理装置对各元素设定独特的ID。例如，“listID”元素的ID设定为“L1”。ID是通过结合元素名的第一个文字“L”和序列号“1”来决定。另外，数据处理装置对各元素设定独特的样本值。“listID”元素的样本值被设定为“2005-G30182”。图34的中央上部设置了用于定义这些元素显示形式的区域(以下称作“布局区域”)。用户在布局区域中通过配列各元素的ID，可反映在布局文件中。对布局区域和布局文件的关系将参照图43或其后的图在下文中详述。此外，在图33的属性区域的中间行中，指定了显示形式使得以表的形式显示元素“customer”。该指定反映在下面的图35所示的布局文件中。

图35示出了根据图34中的绑定文件得到的编辑结果形成的用于布局文件的编辑屏幕。根据图34中的指定，元素“customer”的子元素以表形式显示。例如，模式文件的元素“customerList/customer/name”与布局文件中所示表的最左显示区域对应。另外，图34的布局区域中的设定以显示形式被反映出来。用户可在该编辑屏幕中以所谓WYSIWYG(What You See Is What You Get，所见即所得)的方式编辑布局文件。

由此，模式文件中所示的各元素的显示布局作为布局文件保存。数据处理装置根据这种模式文件的元素和布局文件的元素之间的对应关系生成XSLT文件，并且生成前提技术中说明的定义文件。

用户可在布局文件的编辑屏幕中通过拖拉操作改变元素的显示位置。如果在已经生成定义文件后进行编辑，则数据处理装置必须在定义文件中反映模式文件的元素和布局文件的显示位置的对应关系变化。数据处理装置监视布局文件中的样本值和模式文件的元素之间的对应关系。因此，即使改变布局文件中的元素位置，也可根据样本值的位置更新定义文件。在此，布局文件中包括的各显示元素由样本值确定。为此，当生成XSLT文件时将布局文件中的样本值作为键值使用，从而重定义对应关系。

图36是显示根据图35中的编辑结果的目标文件时的屏幕图。所示出的目标文件是根据定义文件从源文件生成的。图35是显示该目标文件的屏幕。由于源文件的元素“customer”具有三个，因此根据图35的表形式显示三个“customer”元素。用户可通过图36的屏幕编辑源文件的数据。该方式在前提技术中作为词汇连接进行了说明。

图37示出了绑定文件编辑屏幕的另一实施例。在图37的属性区域的中段中与图34不同的是，元素“customer”被指定为以列表形式显示。

图38示出了根据图37的绑定文件的编辑结果形成的布局文件的编辑屏幕。根据图37中指定的显示形式，元素“customer”的子元素以列表形式显示。由此，布局文件根据绑定文件中指定的显示形式发生了变化。在图37中，模式文件的元素“customerList/customer/name”与布局文件中所示的各列表的最先的元素对应。数据处理装置从这种模式文件的元素和布局文件的元素的对应关系生成前提技术中说明的定义文件。

图39是根据图38中的编辑结果显示目标文件时的屏幕图。由于源文件的元素“customer”有三个，因此根据图37的列表形式，以列表的形式显示了三个元素“customer”的内容。用户可通过图39的屏幕编辑源文件。

图40示出了绑定文件编辑屏幕的另一实施例。在图40中，作为用于计算元素“totalNumber”值的计算式，由来自用户的编辑操作设定“count(N1)”。由于“N1”即是元素“name”的ID，因此元素“totalNumber”值是源文件中的元素“name”的数。另外，作为用于计算元素“totalEstimate”值的计算式，设定了“sum(E1)”。由于E1即是元素“estimate”的ID，因此元素“totalEstimate”值是源文件中的元素“estimate”值的合计值。由此，在绑定文件的编辑屏幕中，能够由ID值而不是长的元素名以简单的输入形式处理各元素。

图41示出了根据图40中的绑定文件的编辑结果形成的布局文件的编辑屏幕。图41与图35没有不同之处。

图42是根据图41中的编辑结果显示的目标文件时的屏幕图。“totalNumber”的项目中显示了“3”，即源文件中的元素“name”的数。同样地，“totalEstimate”的项目中显示了“8000”，即源文件中的元素“estimate”的值的合计值(1000+3500+3500＝8000)。

图43示出了绑定文件的编辑屏幕的另一实施例。在此，使用与图31所示的模式文件不同的模式文件为例进行说明。如图43所示，用户通过在布局区域中配列ID，可设定布局文件中的基本布局。当显示绑定文件时，布局区域中各元素ID以缺省的方式配列。此时的配列也可以是反映了模式文件中的元素结构的配列。例如，可以通过对具有亲-子或兄弟关系的元素进行配列以使得它们相互靠近。另外，当元素名接近时，例如“totalNumber”、“Number”和“subtotalNumber”，这些元素也可以通过配列而相互靠近。与需要初始ID设定并从最初开始创建配列相比，本发明在实现布局创建时节省了工作。

图44示出了根据图43的绑定文件的编辑结果形成的布局文件的编辑屏幕。在该布局文件中，根据图43的布局区域的编辑内容显示各元素。

图45是显示根据图44中的编辑结果的目标文件时的屏幕图。

图46是用于进一步说明定义文件生成过程的示意图。在图46中，通过用户对绑定文件编辑操作，对绑定文件附加补充信息。补充信息例如是与元素相关的规则定义、重定义等。以该绑定文件为基础生成定义文件，但是也可以生成XSLT文件来替代定义文件。除此之外，还可以生成用于实现源文件和目标文件之间数据映射的对象，例如Java(注册商标)对象。

以上根据实施方式对本发明进行了说明。所述的实施方式仅是示例性的，这些构成元素或者处理过程的组合可以形成各种变形例，而且这些变形例也落入本发明的保护范围，这对于本领域的技术人员来说都将是可以理解的。

根据本发明，可提高对由标记语言构造的数据进行处理时的用户方便性。

Claims (9)

1.数据处理装置，包括：

模式信息获取单元，获取显示结构化文档文件的元素结构的模式信息，所述结构化文档文件以预定的标签集描述；以及

定义数据生成单元，根据所述模式信息生成定义数据，以显示用于编辑所述结构化文档文件的用户界面屏幕。

2.根据权利要求1所述的数据处理装置，其中，所述模式信息获取单元从模式文件获取所述模式信息，在所述模式文件中规定了与所述结构化文档文件的元素结构相关的规则。

3.根据权利要求1所述的数据处理装置，其中，所述模式信息获取单元通过参照所述结构化文档文件确定所述元素结构来获取所述模式信息。

4.根据权利要求1至3的任意一项所述的数据处理装置，还包括：

布局文件生成单元，生成表示所述模式信息中所示各元素的显示布局的布局文件，

所述定义数据生成单元根据所述布局文件生成定义文件作为所述定义数据，所述定义文件用于使所述结构化文档文件变换为用于编辑的数据形式。

5.根据权利要求4所述的数据处理装置，其中，还包括：

编辑处理单元，显示用于编辑在所述模式信息中所示元素的显示布局的编辑屏幕，

所述布局文件生成单元根据用户对所述编辑屏幕的编辑操作生成所述布局文件。

6.根据权利要求5所述的数据处理装置，其中，所述编辑处理单元进一步在屏幕上显示所述布局文件，以及根据用户对所述布局文件的编辑操作更新所述布局文件。

7.根据权利要求5或6所述的数据处理装置，其中，所述编辑处理单元在所述编辑屏幕中初始化并显示所述模式信息中包括的各元素的显示布局。

8.根据权利要求7所述的数据处理装置，其中，所述编辑处理单元根据所述模式信息中所示的元素结构初始化各元素的显示布局。

9.根据权利要求5至8的任意一项所述的数据处理装置，其中，所述编辑处理单元在所述编辑屏幕上显示用于选择所述布局文件的显示形式的输入界面，

所述布局文件生成单元根据选择的显示形式生成布局文件。

Images