数据处理装置的制作方法

专利名称：数据处理装置的制作方法
技术领域：
本发明涉及文档处理技术，特别涉及用于处理由标记语言描述的结 构化文档文件的技术。
背景技术：
XML作为适于通过网络等与他人共享数据的形式备受关注，用于创 建、显示和编辑XML文档的应用程序(例如，参照专利文献l)目前祐: 开发出来。XML文档是根据由文档类型定义等定义的词汇(标签集)创 建的。专利文献l:日本未决的专利申请No.2001-290804发明内容发明要解决的课题词汇是允许任意定义的，理论上存在无限多的词汇。而对这些词汇 的全部提供专用的显示/编辑环境是不现实的。目前，在编辑由不具有专 用编辑环境的词汇所描绘的文档时，直接例如使用文本编辑器等来编辑 由文本数据构成的文档源。本发明是鉴于这种状况而做出的，其目的在于提供一种在对由标记 语言构造的数据进行处理时能够提高用户方便性的技术。解决课题的方案本发明的一方面涉及数据处理装置。该装置取得显示由规定的标签 集描述的结构化文档文件的元素结构的模式信息，以及根据模式信息生 成定义数据，用于显示用于编辑结构化文档文件的户界面屏幕。此外，以上构成要素的任意组合，以及将本发明在方法、装置和系 统等表现形式之间的变换都是本发明的附加实现方式。发明的效果根据本发明，可提高对由标记语言构造的数据进行处理时的用户方 便性。


图l是与前提技术相关的文档处理装置的构成示意图； 图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所示文档的屏幕显示的实施例；图ll (a)示出了文档处理系统的基本构成；图ll (b)示出了文档处理系统的总体框图；图ll (c)示出了文档处理系统的总体框图；图12示出了文档管理单元的细节；图13示出了词汇连接子系统的细节；图14示出了程序调用单元与其它组件之间的关系的细节；图15示出了载入到程序调用单元的应用程序服务的结构细节；图16示出了核心组件的细节；图17示出了文档管理单元的细节；图18示出了撤消框架和撤消命令的细节；图19示出了在文档处理系统中载入文档的操作；图20示出了文档及其表现的实施例；图21示出了模型和控制器的关系；图22示出了插件子系统、词汇连接与连接器的细节；图23示出了 VCD文件的例子；图24示出了用于将复合文档载入到文档处理系统中的操作； 图25示出了用于将复合文档载入到文档处理系统中的操作； 图26示出了用于将复合文档载入到文档处理系统中的操作； 图27示出了用于将复合文档载入到文档处理系统中的操作； 图28示出了用于将复合文档载入到文档处理系统中的操作； 图29示出了命令流；图；5 、,、、 、'、图31示出了根据示例性实施方式的模式文件； 图32示出了与图31的模式文件对应的源文件； 图33示出了根据图31的模式文件和图32的源文件生成的定义文件； 图34示出了绑定文件的编辑屏幕；图3 5示出了根据图3 4中的绑定文件的编辑结果形成的布局文件的编 辑屏幕；图36是用于根据图35中的编辑结果显示的目标文件的屏幕图；图37示出了绑定文件的编辑屏幕的另一实施例；图38示出了根据图37中的绑定文件编辑结果形成的布局文件的编辑屏幕；图39是显示根据图38中的编辑结果形成的目标文件的屏幕图；图40示出了用于绑定文件的编辑屏幕的另 一实施例；图41示出了根据图40中的绑定文件编辑结果形成的布局文件编辑屏图42是根据图41中的编辑结果显示目标文件时的屏幕图； 图43示出了用于绑定文件的编辑屏幕的另 一 实施例； 图44示出了用于根据图43中的绑定文件的编辑结果形成的布局文件 的编辑屏幕；图45是根据图44中的编辑结果显示目标文件时的屏幕图；以及 图46是用于进一步说明定义文件生成过程的示意图。符号说明 20文档处理装置 30 DOM单元 36输出单元 44 CSS提供单元 52、 62控制单元 60 SVG单元22主控单元 32 DOM提供单元 40 CSS单元 46呈现单元 54、 64编辑单元 80 VC单元84定义文件获取单元24编辑单元34 DOM生成单元42 CSS分析单元50 HTML单元56、 66显示单元82:映射单元86定义文件生成单元具体实施方式
(前提技术)图l示出了与前提技术相关的文档处理装置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文档 相对应的目的树。例如，在编辑结束时，llT出单元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,以及在4妄收到编辑命令时对DOM进4亍编辑的编辑单元(在本文中还称为"区(zone) ) "54、 64。在控制单元52或62从外部源接收到用于DOM树的编辑命令时，编辑单元54或64修改DOM树，而显示单元55或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中，则该插件#1载入以显示/编辑文档。另一方 面，如果插件并未安装在其中，则进行检查以确认是否存在映射的定义 文件。如果存在定义文件，则定义文件获取单元84获取该定义文件， 并根据定义创建目的树，以使得能够通过与要被映射的词汇相对应的插 件来显示/编辑文档。如果该文档是包含多个词汇的复合文档，如后面所 述，则通过与各词汇相对应的插件来显示/编辑该文档的相关部分。如果 不存在定义文件，则显示文档的源或树型结构，并在显示屏中进行编 辑。图2示出了作为处理对象的XML文档的例子。该XML文档用于管理 学生的成绩数据。作为XML文档的上部节点的构成元素"成績"包括在 "成績"下方为各个学生设置的多个元素"生徒"。构成元素"生徒"具有属 性值"名前"，以及子元素"国語，，(日语)、"数学"、"理科，，以及"社会，，(社会科学)。属性值"名前"存储学生的姓名。构成元素"国語"、"数 学"、"理科"和"社会"分别存储日语、数学、自然科学和社会科学的成绩。例如，姓名为"A"的学生的成绩是日语为"90"、数学为"50"、自然 科学为"75"以及社会科学为"60"。下文中，该文档中使用的词汇(标签 集)被称作"成绩管理词汇"。由于本前提技术的文档处理装置20不具有与成绩管理词汇的显示和/ 或编辑相对应的插件，因此，将使用以上描述的VC功能，而不使用源显 示和树显示的其它显示方法来显示该文档。也就是i兌，通过准备定义文 件，使得成绩管理词汇可映射为已具有插件的另一词汇，例如HTML或 SVG。下面将要进行的说明是在假设已经具备了定义文件的情况下进行 的，不过对于用户本身用以创建定义文件所必需的用户界面将在后面描 述。图3示出了将图2中所示的XML文档映射为以HTML描述的表的例 子。在图3所示的例子中，使以成绩管理词汇描述的"生徒"节点与以 HTML描述的表("TABLE"节点)的行("TR"节点)相对应。各行的第 一列与属性值"名前"相对应，第二列与"国語"节点的元素值相对应，第 三列与"数学"节点的元素值相对应，第四列与"理科"节点的元素值相对 应，而第五列与"社会"节点的元素值相对应。因此，图2所示的XML文 档能以HTML的列表格式来显示。此外，这些属性值和元素值被指定为 能够编辑，以4吏得用户能够使用HTML单元50的编辑功能在利用HTML 显示的屏幕上对这些值进行编辑。在第六列中，指定了用来计算日语、 数学、自然科学以及社会科学的分数的加权平均的运算表达式，并显示每个学生的分数的平均值。以这种方式，通过在定义文件中指定运算表 达式来完成更灵活的显示，从而提高用户在进行编辑时的便利性。另 外，将对第六列的编辑指定为不允许，以使得不能单独对平均值本身进 行编辑。因此，在映射定义中，能够指定可编辑或不能编辑，以避免用 户可能的错误操作。图4(a)和4(b)表示定义文件的例子，以将图2所示的XML文档映射为 图3所示的表。该定义文件通过被定义用于和定义文件一起使用的脚本 语言来描述。在图4(a)和4(b)所示的例子中，"生徒O追加"和"生徒O削除"被定义为命令，并分别涉及将节点"生徒"插入源树中的操作以及将节 点"生徒"从源树中删除的操作。该定义文件以模板的形式描述了诸如"名 前"和"国語"的标题显示于表的第 一行中，而节点"生徒"的内容显示于第二行及其随后的行中。在显示节点"生徒"内容的模板中，包含"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所示的屏幕上，例如"生徒O追加"和"生徒O削除，，的命令被显 示为菜单，如图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中显示。该文档在这些区域中的任意区域均可^L编辑，当用户 对这些区域中的任意区域的内容进行编辑时，源树将被相应》务改，从而负责各屏幕显示的插件将更新屏幕，以反映源树的变更。具体而言，负 责显示对应编辑屏幕的插件的显示单元被预先注册为变化事件的监听 器，所述变化事件提供源树中发生了改变的通知。当源树被任意插件或VC单元80修改时，显示编辑屏幕的所有显示单元接收发出的一个或多个 变化事件，并从而更新屏幕。此时，如果插件正在通过VC功能进行显 示，则VC单元80根据对源树的修改来修改目的树。之后，插件的显示单 元通过参考上述经过修改的目的树来对屏幕进行修改。例如，当通过专用插件来实现源显示和树型视图显示时，源显示插 件和树显示插件通过直接参考源树而不是利用目的树来实现它们的显 示。在这种情况下，当在屏幕的任何区域中完成编辑时，源显示插件和 树显示插件通过参考修改后的源树来更新屏幕。同样，负责显示区域96新屏幕。源显示和树显示也可通过使用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示出了显示结果。在对文档进行编辑期间，待显示的菜单可根据光标(《X ij 7 ) 的位置被切换。也就是说，当光标位于显示SVG文档的区域中时，显示 SVG单元60提供的菜单、或用于映射SVG文档的定义文件中定义的命 令。当光标位于显示XHTML文档的区域中时，显示HTML单元50提供的据编辑位置提供适当的用户界面。如果在复合文档中不存在与某词汇相符的适当插件或映射定义，则 以该词汇描述的部分可以源或树格式显示。在传统实践中，当要打开在 某个文档中嵌有其它文档的复合文档时，如果没有安装能够显示该嵌入 文档的应用程序，则它们的内容不能显示。但是，根据本前提技术，即 使不存在用于显示的应用程序，也可以将由文本数据组成的XML文档显 示为源或树格式，从而能够确定其内容。这是基于文本的XML文档或类 似文档的一个特征。以基于文本的语言来描述数据的另一个有益方面例如在于，在同一 文档中以其它词汇描述的部分的数据可被该复合文档中以某个词汇描述 的另一文档所参考。此外，当在该文档中进行搜索时，嵌入SVG等图片中的字符串也可作为被搜索的对象。在以某个词汇描述的文档中，可使用其它词汇的标签。虽然该XML 文档通常并不有效，4旦只要它结构良好(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.概要由于因特网的出现，由用户处理、管理的文档的数量大致是成指数 函凄t形式在增加。形成因特网核心的Web (World Wide Web:万维网) 成了接受这些文档数据的大容器。除了文档以外，Web还提供用于这些 文档的信息;险索系统。这些文档通常是由标记语言描述的。作为标记语 言的简单且常用的例子，HTML (HyperText Markup Language:超文本 标记语言)是其中的一个。这样的文档还包括有指向记录在Web的其它 位置的其他文档的链4妄。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上的文档通过软件应用程序进 行查询或者处理。与显示方法无关，只要是分级结构化的语言，可以同 才羊查询处理。i者3口XML (extensible Markup Language)这才羊的才示"i己i吾言 可以提供这类特征。众所周知，与HTML相反，XML的优点是文档的设计者可以使用可 自由定义的"标签"对数据元素进行标注。这样的数据元素可以分级进行 结构化。而且，XML文档可以包含文档类型定义，它描述文档内使用的标签及其相互关系的"语法"。为了定义结构化的XML文档的显示方法， 使用CSS (Cascading Style Sheet:层叠式样式表)或者XSL (XML Style Language:可扩展标记语言样式语言)。关于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 User Interface:图形用户界面)范例进行说明。MVC范例将应用程序或应用 程序的界面的一部分分解为三部分，即，模型、视图和控制器。最初开 发MVC是为了将传统的输入、处理和输出任务分配到GUI区域。输入->处理->输出控制器-〉模型-〉视图根据MVC范例，外界的建模、对用户的视觉反馈以及用户输入通过 模型(M)、视图(V)以及控制器(C)对象来分离从而进行处理。控 制器操作以解释诸如用户的鼠标和键盘输入的输入，并将这些用户动作 映射为发送至模型和/或视图的命令，以实现适当的改变。模型发挥作用 以管理一个以上的数据元素、响应对其状态的询问、并对改变状态的指 示作出响应。-现图操作以管理显示的矩形区域，并有通过图形和文本的组合将数据显现给用户的功能。B.文档处理系统的总配置文档处理系统的实施例将结合图11 - 2 9进行清楚说明。图ll (a)图示了包括将在下面描述的能够提供文档处理系统的、根 据现有技术的基础功能的配置结构。装置10包括通过通信路径13连接到 存储器12的CPU形式或微处理器等形式的处理器11。存储器12可为当前 或将来能够使用的任意ROM和/或RAM形式。通信路径13作为典型的总 线而设置。对于鼠标、键盘和语音识别系统等用户输入装置14以及显示 装置15 (或者其他用户界面)的输入输出界面16也连接在用于处理器11 和存储器12通信的总线上。该结构可以是独立的形式，也可以是由多个 终端以及一 台以上的服务器连接的网络化的形式，也可以由公知的任何 方式来构成。本发明并不受这些组件的配置、它们的集中式或分布式体 系结构或者多种组件的通信方式的限制。此外，本系统以及在此讨论的实施例将作为包括提供各种功能性的 若千组件以及子组件的例子来讨论。为了提供期望的功能，这些组件以 及子组件可以是硬件和软件的组合，也可以仅由硬件或者仅由软件来实 现。而且，硬件、软件及其组合可以由通用计算装置、专用硬件或者它 们的组合来实现。因此，组件或者子组件的构成包括执行用于提供组件 或者子组件功能的专用软件的通用/专用的计算装置。图ll (b)示出了文档处理系统一个例子的总体方框图。文档在这 种文档处理系统中^C创建和编辑。这些文档(例如XML等)能够以具有 标记语言特征的任何语言来表述。同样，为方便起见，已经创建了用于 特定的组件和子组件的术语和标题。但是，这些不应被视作对本文公开 的一般教导范围的限制。文档处理系统可被视为具有两个基本构成。 一 个构成是"执行环 境"IOI,它是文档处理系统运行的环境。例如，执行环境在对文档进行 处理中和管理中不仅支持用户，而且支持系统，提供基本效用和功能。 第二构成是"应用程序"102,它由在执行环境中运行的应用程序构成。这 些应用程序包括文档本身及其各种表述。1.执行环境执行环境101的关4建组件是程序调用器(Programlnvoker,即程序启 动单元)103。程序调用器103是用于启动文档处理系统而被访问的基本 程序。例如，当用户登录并启动文档处理系统时，程序调用器103被执 行。程序调用器103例如可以读取并执行作为插件增加至文档处理系统 的功能、启动并运行应用程序、以及读取与文档相关的属性。程序调用 器103的功能并不限于此。当用户希望启动计划在执行环境中运行的应用程序时，程序调用器 103找到并启动该应用程序，然后执行该应用程序。在程序调用器103上联接有插件子系统104、命令子系统105以及资 源模块109等若干组件。这些构成将随后进行更详细描述。a)插件子系统插件子系统104能够高度灵活和有效地向文档处理系统增加功能。 插件子系统104也可以用来修改和去除文档处理系统中存在的功能。此 外，可使用插件子系统增加或修改多种功能。例如，可以增加编辑功能 (Editlet:编辑单元)以起到支持在屏幕上呈现文档的作用。编辑插件 也支持对增加至系统的词汇进行编辑。插件子系统104包括服务代理(ServiceBroker:服务中介单元) 1041。服务代理1041通过管理增加至文档处理系统的插件，作为增加至 文档处理系统的服务的中介。期望的每个功能以服务(Service) 1042的形式增加至系统。服务1042 的可用类型包括但不限于应用程序(A卯lication)服务、区工厂 (ZoneFactory,即区生成单元)服务、Editlet (编辑单元)服务、命令工 厂 (CommandFactory : 命令生成单元)服务、连接xpath (ConnectXPath: XPath管理单元)服务、CSS计算(CSSComputation: css计算单元)服务等。这些服务及其与系统其余部分的关系将随后详细描述，以更好地理解文档处理系统。插件和服务之间的关系如下所述。插件是可包括一个以上的服务提供器(ServiceProvider:服务提供单元)的单元。各个服务提供器具有与之相关服务的一个以上的类。例如，通过使用具有适当软件应用程序 的单个插件，可将一个以上的服务增加至系统，爿Mv而可向系统增加相应的功能。b)命令子系统命令子系统105被用来执行与文档的处理相关的命令形式的指令。 用户可通过执行一系列指令而执行对文档的操作。例如，通过发出命令 形式的指令，用户对文档处理系统中的XML文档相对应的XML的DOM 树编辑来处理XML文档。这些命令可利用键盘击4建、鼠标点击或其它有 效的用户界面动作来输入。有时，也可通过一个命令来执行一个以上的 指令。在这种情况下，这些指令被封装(包含)成一个命令并连续执 行。例如，用户希望将错误词语替换为正确词语。在这种情况下，第一 个命令可用以在文档中找寻错误词语，第二个命令可用以删除该错误词 语，第三个命令可用以输入正确词语。这三个命令可^皮包装成一个命 令。命令可具有相关功能，例如是下面将要详细记述的"撤消"功能。这 些功能可分配给用来创建对象所使用的若干个基类。命令子系统105的关键组件是命令调用器(Commandlnvoker,即命 令启动单元)1051,命令调用器1051可操作以有选择性地提供并执行命 令。虽然图ll (b)中仅示出了一个命令调用器，但也可使用一个以上 的命令调用器并可同时执行一个以上的命令。命令调用器1051维护执行 命令所需的功能和类。在操作中，要执行的命令1052被置于队列1053 中。命令调用器创建连续执行的命令线程。如果在命令调用器中没有正 在执行的命令，则由命令调用器1051执行待执行的命令1052。如果命令 调用器正在执行命令，则新的命令被置于命令队列1053的末尾。不过， 对于各命令调用器1051而言， 一次仅执行一个命令。如果指定的命令执 行失败，则命令调用器1051将执行异常处理。可由命令调用器(Commandlnvoker ) 1051执行的命令的类型包括但 不卩艮于可撤消命令(UndoableCommand)1054 、 异步命令 (AsynchronousCommand)1055以及词汇连接命令(VCCommand)1056。可 撤消命令1054是那些如果用户希望就能够撤销其结果的命令。可撤消命令的示例为剪切、复制、插入文本等。在操作中，当用户选择文档的 一部分并对该部分应用剪切命令时，如果需要，通过使用可撤消命令， 可使被剪切的部分恢复至其未被剪切的状态。词汇连接命令1056被载入词汇连接描述符(Vocabulary Connection Descriptor: 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) IIO提供在多个窗格(Pane)之间共享 文档的一种方法。如后述的那样，窗格显示DOM树，并处理屏幕的物理 布局。例如，物理屏幕包括在屏幕内的多个描述信息的片断的窗格。实 际上，由用户在屏幕上看到的文档可在一个或多个窗格中显示。此外， 两个不同的文档可以出现在屏幕上的两个不同窗^f各中。如图ll(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以及快照(Snap Shot)实用程序1088。剪 贴板实用程序1087提供了保持用户决定增加至剪贴板的部分文档的方 法。例如，用户可能希望剪切文档的一部分，并将其保存到新的文档 上，用于稍后查看。在这种情况下，剪切的部分被增加至剪贴板。接着，也对快照实用程序1088进行说明。快照实用程序1088在应用 程序从一个状态变为另 一状态时，能够记住应用程序的当前状态。d)用户界面应用程序组件102的另 一组件是用户界面107，其为用户提供一种与 系统进行物理交互的方式。例如，用户界面用于用户上载、删除、编辑 和管理文档。用户界面包括框架(Frame) 1071、菜单栏(MenuBar) 1072、状态栏(StatusBar) 1073以及URL栏(URLBar) 1074。如通常公知的那样，框架1071被视为物理屏幕的活动区域。菜单栏 1072是包含有为用户提供选项菜单的屏幕区域。状态栏1073是显示应用 程序的执行状态的屏幕区域。URL栏1074提供输入用于在互联网上定位 的URLi也址的区i或。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的一部分，但_ 它也可使用一个以上的"命名空间"。如本领域中7>知的那样，命名空间 是名称的汇集或集合，这些名称在该命名空间中是唯一的。换言之，一 个命名空间中不存在相同的名称。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呈现在屏幕 上。与区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 (数学标记语言)或其他的标记语言。换句话说，标记语言可 以^L为和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.连4姿器(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)。在这种情况 下，由于不能够为源直接创建视图，因此，不创建源的画布。在这种情 况下，^使用连接器树来创建词汇连"l妻画布。这种词汇连接画布^U又处理 事件转换，而并不会有助于将文档呈现在屏幕上。3. 目的区(DestinationZone)、窗格(Pane)以及画布(Canvas) 如上所述，词汇连接子系统的目的在于同时创建并维护对同一文档的两种表述。第二表述也是DOM树形式，先前作为目的DOM树已被说 明。为了浏览第二种表述的文档，需要目的区、画布和窗格。在创建词汇连4妄画布后，将创建相应的目的窗格 (DestinationPane ) 307。此夕卜，相关的目的画布(DestinationCanvas ) 308和相应的盒树(BoxTree)309被创建。同样，词汇连4妄画布310还与源 文档的窗格211和区209关联。目的画布308提供了文档的第二种表述方式的逻辑布局。具体地， 目的画布308提供了用户界面功能，例如光标和选4奪，用于以目的表述 的方式呈现文档。在目的画布308中发生的事件被提供到连接器。目的 画布308向连接器304通知鼠标事件、键盘事件、拖动和放置事件、以及 通知文档的目的(第二种)表述的词汇的特有事件。4. 词汇连接命令子系统作为词汇连接(VC)子系统300的一部分是词汇连接(VC)命令子 系统313。词汇连接命令子系统313创建词汇连接命令(VCCommand) 315,词汇连接命令315用来执行与词汇连接子系统300相关的指令。可 通过内建的命令模板(CommandTemplate) 318来创建词汇连接命令，和 /或可通过在脚本子系统314中使用脚本语言从无到有地创建命令而创建 词汇连接命令。命令模板中包括，例如"If，命令模板、"When"命令模板、"Insert fmgment"命令模板等。这些模板被用来创建词汇连接命令。5. XPath子系统XPath子系统316是文档处理系统的一个重要组件，它有助于实现词 汇连接。连接器304通常包括XPath信息。如上所述，词汇连接的任务之 一是将源DOM树的变化反映到目的DOM树中。XPath信息包括一个或多 个XPath表述，用来确定对改变/修改加以监视的源DOM树的子集。6. 源DOM树、目的DOM树和连接器树(ConnectorTree )的概述 源DOM树是对转换为另 一种词汇之前的词汇表述的文档进行表述的DOM树或区。在源DOM树中的节点4皮称为源节点。另一方面，如已在前面结合词汇连接描述的，目的DOM树是通过映 射转换后以不同词汇表述的文档的DOM树或区。目的DOM树中的节点 被称为目的节点。连接器树是基于用来表述源节点和目的节点之间的对应关系的连接 器的分级表述。连接器监视源节点和对源文档进行的修改，修改目的 DOM树。连接器是被允许修改目的DOM树的唯一对象。E.文档处理系统中的事件流为了能够使用，程序必需对来自用户的命令进行响应。事件是一种 描述和执行用户对程序实施的动作的方法。许多高级语言例如Java (注 册商标)依靠描述用户动作的事件。在现有技术中，程序需要主动收集 信息以理解用户操作和由程序自己执行用户的操作。这意味着，例如，在对程序自身初始化后，为了在用户对屏幕、键盘和鼠标等执行了任何 操作时进行适当的处理，进入反复确认用户操作的循环。然而，这种处 理难以操控。此外，这种处理在等候用户作某些事情时，还需要执行循环的程序，从而消耗了CPU周期。许多语言通过包含不同的范例来解决这些问题。其中的 一 个范例即 事件驱动程序构成了所有现代的视图系统的基础。在这种范例中，所有 的用户动作属于被称为"事件"的抽象现象的集合。事件足够详细地描述 了特定的用户动作。程序不是主动地收集用户创建的事件，而是在要监 视的事件发生时，由系统通知程序。以这种方式处理用户交互的程序被 称为"事件驱动"。在多数场合，使用"事件(Event)"类来进行处理，其中事件类获取 所有用户创建事件的基本特性。文档处理系统定义和使用其自身的事件以及处理这些事件的方式。 有几种类型的事件被使用。例如，鼠标事件是由用户的鼠标操作引起的 事件。与鼠标有关的用户操作由画布210传递到鼠标事件。因此，画布 可以被认为是用户与系统交互的最前沿。如果需要，作为最前沿的画布 将把其与事件有关的内容传递到其下(子)级。另一方面，按键事件从画布210产生。按键事件具有瞬时的焦点。 即，按键事件总是涉及操作。输入到画布210的按键事件接着被传递到 其上级(父)。键盘输入通过能够处理字符串插入的不同事件而被处 理。处理字符串插入的事件将在使用键盘插入字符时发生。其他的"事 件"例如包括以与拖动事件、放置事件和鼠标事件相似的方式处理的其他 事件。1. 在词汇连接之外的事件处理使用事件线程对事件进行传递。在接收到事件后，画布210改变其 状态。如果需要，画布210将命令(Command) 1052记入到命令队列 (CommandQueue ) 1053。2. 在词汇连接之内的事件处理通过^f吏用词汇连"^妄插件301,作为目的画布一例的XHTML画布 (XHTMLCanvas) 1106接收现有的事件，例如鼠标事件、键盘事件、拖 动和放置事件、以及词汇中的特有事件。这些事件接着被通知到连接器 304。更具体地说，如图21 (b)所示，词汇连接插件301内的事件流经 过源窗格(SourcePane) 1103、词汇画布1104、目的窗格1105、作为目 的画布的实施例的目的画布1106、目的DOM树和连接器树。F.程序调用器(Programlnvoker )及其与其他组件之间的关系 在图14 (a)中更加详细地显示了程序调用器103及其与其他组件之 间的关系。程序调用器103是在执行环境中被执行以启动文档处理系统 的基本程序。如图11 ( b )及图11 ( c )所示，用户应用程序 (UserApplication ) 106、服务代理(ServiceBroker)1041 、命令调用器 (Commandlnvoker) 1051和资源(Resource) 109都被联接到程序调用器103 。 如前所述，应用程序102是在执行环境中运行的组件。同样，服务代理 1041管理向系统增加各种功能的插件。另一方面，命令调用器1051执行 用户提供的指令，维护用来执行命令的类和函数。1.插件和服务下面将参照图14 (b)详细描述服务代理1041。如上所述，服务代 理1041管理向系统增加各种功能的插件(及相关服务)。服务1042在最 底层，其能够将特征增加到文档处理系统中或者改变文档处理系统的特 征。"服务"由两部分构成服务种类(ServiceCategory)401和服务提供器 (ServiceProvider)402。如图14(c)所示，单个服务种类401可具有多个 相关的服务提供器402。每个服务提供器都可操作以执行所有或部分的 特定服务种类。另一方面，服务种类401则定义了服务的类型。服务可分为三种类型l)"特征服务"，向文档处理系统提供特定特 征；2)"应用程序服务"，是由文档处理系统运行的应用程序；3)"环 境服务"，提供在整个文档处理系统中需要的特征。图14 ( d )中示出了服务的例子。根据应用程序服务的种类 (Category),系统实用程序是相应服务提供器的示例。同样，Editlet206是一个种类，HTML Editlet和SVG Editlet是相应的服务提供器。区工 厂205是服务的另一种，并具有相应的服务提供器(未示出)。已经描述的向文档处理系统增加功能的插件，可以看作是由几个服 务提供器402和与其相关的类构成的单元。各个插件都具有在定义文件 中记载的从属关系和服务种类401。2.程序调用器(Programlnvoker )和应用程序之间的关系 图14 (e)详细显示了程序调用器103和用户应用程序106之间的关 系。所需的文档、数据等从存储器中载入。所有需要的插件载入到服务 代理1041。服务代理1041维护并管理所有的插件。可将插件物理地增加 到系统，或者可从存储器中载入其功能。在载入插件的内容后，服务代 理1041定义相应的插件。4姿着，相应的用户应用程序106^皮创建，并#皮 载入执行环境101并联接到程序调用器103 。G. 应用程序服务和环境之间的关系图15 (a)更详细地示出了载入程序调用器103中的应用程序服务的 结构。作为命令子系统105组件的命令调用器1051调用或执行程序调用 器103内的命令1052。命令1052则是用来在文档处理系统中处理XML等 文档和编辑相应的XML DOM树的指令。命令调用器1051维护执行命令 1052所需的类和功能。服务调用器1041也在程序调用器103中执行。用户应用程序106连接 到用户界面107和核心组件110。核心组件11 O提供了 一种在所有的窗格中 共享文档的方式。核心组件1 IO还提供字体并作为用于窗格的工具包。图15 (b)显示了框架(frame)1071、菜单栏(MenuBar)1072和状态栏 (StatusBar)1073之间的关系。H. 应用程序核心图16 (a)进一步解释了应用程序核心108,其保持所有文档以及作 为文档一部分及属于文档的数据。核心组件1 IO联接到管理文档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以及如何在文档管理器 中组织并保存文档。如图ll (b)所示，文档管理器1081管理文档 1082。在图17 (a)显示的实施例中，多个文档中的一个为根文档 (RootDocument) 701，其4也的文档为子文档(SubDocument) 702。文 档管理器1081连接到根文档701 ，根文档701则连接到所有的子文档 702。如图12和17 (a)所示，文档管理器1081耦合到文档容器203，文档 容器203是管理所有文档1082的对象。形成包括DOM服务 (DOMService)703和10管理器(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:可招t消编辑接受单元)709可利用 的撤消对象。撤消管理器706和撤消封装器707连接到可撤消编辑接收器709和可 撤消编辑源(UndoableEditResource ) 708。本领域技术人员应该理解， 文档705可以是可撤消编辑源708 ，也可以是可撤消编辑对象的源。J.撤消命令和撤消框架图18 (a)和18 (b)进一步详细地显示了撤消框架和撤消命令。如 图18 ( a )所示，撤消命令(UndoCommand ) 801 、 重做命令 (RedoCommand ) 802和可撤消编辑命令(UndoableEditCommand ) 803 是能够排列在如图ll (b)所示的命令调用器1051中的命令，并且被顺 序执行。可撤消编辑命令803还进一步联:接到可撤消编辑源708和可撤消 编辑接受器709。 "foo"编辑命令804和"bar"编辑命令805就是可撤消编辑 命令的例子。1.可撤消编辑命令的执行图18 (b)显示了可撤消编辑命令的执行。首先，假设用户使用编 辑命令来编辑文档705。在第一步骤S1，可撤消编辑接受器709被联接到 可〗敬消编辑源708，而可撤消编辑源708为文档705的DOM树。在第二步 骤S2，基于由用户发出的命令，4吏用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。在步骤l,将顶节点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。顶节点用阴影圆圏表示。非顶节点用非阴影圓圏表示。用来编辑节P / z_ " 二 f " m 一 A it/ 士 一 " ^丄tU丄A呎,1 I" 一 / z_ P L -r_ 二 ET二 丄,3、日V —刀囬—用二用7^衣tf , ^T^反取4史:^J，日乂旦日M下，3、 。
W 丁人々3升^]人个 阅gfr l" i'ir +AA r oa/r;b+ ^3. iir yt-ittvtt朝AK;vy^部合丁折节占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区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的组件的;3 、、广乂> A ,、広r^八iv *乂2BS丄A 、、広X4r 1 1 rv， A 1 ;丄、L 上A 、、広t^八tv >r4^ 二i"j /t"《i丈。
11 yv《'丁、 uv^丄vi 口v '/'丁、頃cii'^ ^^《^ 口v《't、 j^vy丄viTAj 。 《接器树通过连接器工厂创建，创建还起到目的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。如上所述，连接 器监^L源DOM中的节点，并修改目的DOM中的节点，以维护两种表述 之间的一致性。模板(Template) 317表述用于一些节点的转换规则。词汇连接描述 符(VCD)文件是表示一些规则的模板列表，这些规则用于将满足某种 路径或规则的元素或元素集合转换为其他的元素。模板317和命令模板 318都联接到词汇连接管理器302。词汇连接管理器是管理VCD文件中所 有部分的对象。对一个VCD文件创建一个词汇连接管理器对象。图22 (c)提供了有关连接器的进一步的细节。连接器工厂303从源\，.，.!_人.，一l Li ac 1JV tM — i—■ , a ,"、rt 、》— C 士 1>*" l乂 iT、之丄； d3L孑S T W楚迁4安^S"。迕4安奋丄乂 JU:5与W/U、 ^旲5f反7F7U^^旲取取橫，开 厶2,1力'i t、3 、:厂；生ii突 卩、,Annk，，io",r<A 。^+Af 、 i兹46 ;主哭(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"文件的^f吏用 词汇连接管理器及连接器工厂树(ConnectorFactoryTree)的VCD脚本的实施例。在图中显示了脚本文件内的词汇部分、模板部分以及在词汇连接管 理器中的相应组件。在标签"vcd:vocabulary"下提供了属性"match"为 "sample:root" , " label"为"MySampleXML"， 以及"call-template"为 "sampleTemplate"。在该实施例中，在"MySampleXML"的词汇连接管理器中，词汇包括 顶点元素"sample:root"。相应的UI标注为"MySampleXML"。在模板部 分，才示签为"vcd:template"，名一尔为"sample template"。0.将文件载入系统的方法的详细实施例图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和盒初t1410。在步骤3，如图24 (c)所示，在发现XHTML区所不理解的标签 "sample:root"后，从XHTML画布上的区域创建子窗格。图25显示了步骤4，在步骤4中，子窗格获取能够处理"sample:root" 标签并可创建适当的区的区工厂。这种区工厂在能够执行区工厂的词汇 中。区工厂包括"MySampleXML"中的词汇部分(Vocabulary Section )的内容。图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及其之后的图主 要详细描述显示模式。理装置获取要编辑的XML文档文件(以下称作"源文件")、和用来定 义源文件的元素结构的模式文件。这里所说的模式文件是指根据XML-Schema 、 DTD (Document Type Definition,文档类型定义)等规范描示布局信息的目标文件。目标文件可以说是前提技术中描述的文件化的 目标树。当有模式文件时，数据处理装置从模式文件生成绑定文件(Binding File)。绑定文件用于编辑目标文件中的显示布局。如果没有模式文 件，数据处理装置则从源文件本身抽出元素及其结构来生成绑定文件。 这种情况下，数据处理装置以树遍历的方式，从源文件的根元素抽出子 元素，从而抽出元素及其构造。此外，可由绑定文件重定义与源文件元 素相关的规则。例如，在从源文件生成绑定文件的情况中，源文件中的 元素A具有四个子元素B。此时，绑定文件中记载了表示元素A可具有的 子元素B的个数是4个的规则。用户通过绑定文件提供的方法，可重定义 该元素A和子元素B相关的规则，例如，元素A可具有的子元素B的个数 也可以定义为1 10。即使在从模式文件生成绑定文件的情况下，在模式 文件中定义的规则范围内，也可以重定义这种与元素相关的规则。由 此，绑定文件还提供与元素相关的规则、和用于定义规则的功能。在下文中，以从模式文件获取表示源文件元素结构的模式信息进行说明。用户可使用数据处理装置编辑绑定文件。通过GUI (Graphical User Interface,图形用户界面)，用户可在绑定文件中设定目标文件的基本 显示布局。由此，通过将绑定文件定义的显示布局信息应用到模式信息 的各元素创建布局文件。布局文件是表示模式文件中包括的各元素的具 体显示布局的HTML文件。此外，布局文件并非局限于由标记限定结构 的结构化文档文件类型，只要是包括布局信息的文件即可，例如表计算 应用程序、用于呈现的应用程序。用户通过编辑布局文件，可进一步精 致地编辑显示布局。在本示例性的实施方式中，使用绑定文件进行目标 文件显示布局的基本设定，而使用布局文件对目标文件显示布局进行详 细设定。根据绑定文件所示的元素和布局文件显示区域之间的对应关系生成 XSLT文件，以决定源文件和目标文件之间的数据变换形式。最后，根据 该XSLT文件生成定义文件，该定义文件表示与绑定文件对应的源文件、 和与布局文件对应的目标文件之间的对应关系。下面以用户界面为中心 说明它们的处理流程。图31示出了该实施方式的模式文件。该图中所示的模式文件描述了 后述的图32所示源文件应遵循的与元素结构相关的规则。另外，该模式 文件是按照XML-Schema描述的。在图31中，例如在/人上第3行中对名为 "customerList，，的元素定义其凄t据型是"CustomerListType"。在下4亍 中，"custmerListType，，数据型在各自的名称空间"sfa"中被定义为包 括"listID" 、 "totalEstimate，， 、 "totalNumber，， 、 "customer"四个子 元素。并且， "customer"元素的凄t才居型是"customerType"， 还定义了 其内容。另外，"customer"元素的个数定义为O个以上。源文件必须4安 照模式文件所示规则描述。由于模式文件是用于规定源文件中包括的各 元素数据型和结构的文件，因此相比于源文件本身，更容易理解与元素 间结构相关的规则。图32示出了与图31的模式文件对应的源文件。在该源文件中，作为 "customerList ，， 的子元素定义了 " listID ，， 、" totalNumber ，，、 "totalEstimate，，以及"customer"。另外，这些元素中包括值。包括三个"customer"元素。图33示出了根据图31的模式文件和图32的源文件生成的定义文件。 图33显示了定义文件的一部分。在该图所示的定义文件中，描述了用于 将源文件中的各元素(例如，"sfa:customerList/sfa:listlD ，， 和 "sfa:customerList/sfa:totalNumber，，)变换为XHTML形式的目标文件的 规则。该实施方式的数据处理装置可在直观的用户界面中简易生成该定 义文件。图34示出了绑定文件的编辑屏幕。数据处理装置使从模式文件生成 的绑定文件以图31所示的规定形式进行图像显示。在图34下部区域(下 面称作"属性区域")中，模式文件中的各元素被以树形结构的方式显 示，并且例如其数据型也可编辑地显示。在属性区域中，通过选中接近 于元素名的复选框能够展开显示其子元素。根据这种方式，即使当模式 文件中定义了庞大数量的元素时，也可以仅显示要编辑的元素。数据处理装置对各元素设定独特的ID。例如，"listID"元素的ID设 定为"L1" 。 ID是通过结合元素名的第一个文字"L"和序列号"1"来 决定。另外，数据处理装置对各元素设定独特的样本值。"listID"元素 的样本值被设定为"2005-G30182"。图34的中央上部设置了用于定义 这些元素显示形式的区域(以下称作"布局区域")。用户在布局区域 中通过配列各元素的ID,可反映在布局文件中。对布局区域和布局文件 的关系将参照图43或其后的图在下文中详述。此外，在图33的属性区域 的中间行中，指定了显示形式使得以表的形式显示元素"customer"。 该指定反映在下面的图35所示的布局文件中。图3 5示出了根据图3 4中的绑定文件得到的编辑结果形成的用于布局 文件的编辑屏幕。才艮据图34中的指定，元素"customer"的子元素以表 形式显示。例^口 ，才莫式文4牛的元素 "customerList/customer/name ，， 与布 局文件中所示表的最左显示区域对应。另外，图34的布局区域中的设定 以显示形式^皮反映出来。用户可在该编辑屏幕中以所谓WYSIWYG (What You See Is What You Get,所见即所得)的方式编辑布局文件。据处理装置根据这种模式文件的元素和布局文件的元素之间的对应关系生成XSLT文件，并且生成前提技术中说明的定义文件。用户可在布局文件的编辑屏幕中通过拖拉操作改变元素的显示位 置。如果在已经生成定义文件后进行编辑，则数据处理装置必须在定义 文件中反映模式文件的元素和布局文件的显示位置的对应关系变化。数 据处理装置监视布局文件中的样本值和模式文件的元素之间的对应关 系。因此，即使改变布局文件中的元素位置，也可根据样本值的位置更 新定义文件。在此，布局文件中包括的各显示元素由样本值确定。为 此，当生成XSLT文件时将布局文件中的样本值作为键值使用，从而重定 义对应关系。图3 6是显示根据图3 5中的编辑结果的目标文件时的屏幕图。所示出 的目标文件是根据定义文件从源文件生成的。图35是显示该目标文件的 屏幕。由于源文件的元素"customer" 具有三个，因此根据图35的表形 式显示三个"customer"元素。用户可通过图36的屏幕编辑源文件的数 据。该方式在前提技术中作为词汇连接进行了说明。图37示出了绑定文件编辑屏幕的另一实施例。在图37的属性区域的 中段中与图34不同的是，元素"customer"被指定为以列表形式显示。图38示出了根据图37的绑定文件的编辑结果形成的布局文件的编辑 屏幕。根据图37中指定的显示形式，元素"customer"的子元素以列表 形式显示。由此，布局文件根据绑定文件中指定的显示形式发生了变 化。在图3 7中，才莫式文件的元素"customerList/customer/name ，，与布局 文件中所示的各列表的最先的元素对应。数据处理装置从这种模式文件 的元素和布局文件的元素的对应关系生成前提技术中说明的定义文件。图3 9是根据图3 8中的编辑结果显示目标文件时的屏幕图。由于源文 件的元素"customer"有三个，因此根据图37的列表形式，以列表的形 式显示了三个元素"customer"的内容。用户可通过图39的屏幕编辑源 文件。图40示出了绑定文件编辑屏幕的另一实施例。在图40中，作为用于 计算元素"totalNumber"值的计算式，由来自用户的编辑操作设定 "count(Nl)"。由于"Nl"即是元素"name ，，的ID ,因此元素 "totalNumber"值是源文件中的元素" name" 的#t 。 另夕卜，4乍为用于"H"算元素"totalEstimate"值的计算式，设定了 "sum(El)"。由于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 (注册商 标)对象。以上根据实施方式对本发明进行了说明。所述的实施方式仅是示例些变形例也落入本发明的保护范围，这对于本领域的技术人员来说都将 是可以理解的。根据本发明，可提高对由标记语言构造的数据进行处理时的用户方便性。
权利要求
1.数据处理装置，包括模式信息获取单元，获取显示结构化文档文件的元素结构的模式信息，所述结构化文档文件以预定的标签集描述；以及定义数据生成单元，根据所述模式信息生成定义数据，以显示用于编辑所述结构化文档文件的用户界面屏幕。
2. 根据权利要求l所述的数据处理装置，其中，所述模式信息获取 单元从模式文件获取所述模式信息，在所述模式文件中规定了与所述结 构化文档文件的元素结构相关的规则。
3. 根据权利要求l所述的数据处理装置，其中，所述模式信息获取台
4.根据权利要求1至3的任意一项所述的数据处理装置，还包括 布局文件生成单元，生成表示所述模式信息中所示各元素的显示布 局的布局文件，
5. 根据权利要求4所述的数据处理装置，其中，还包括 编辑处理单元，显示用于编辑在所述模式信息中所示元素的显示布局的编辑屏幕，所述布局文件生成单元根据用户对所述编辑屏幕的编辑操作生成所 述布局文件。
6. 根据权利要求5所述的数据处理装置，其中，所述编辑处理单元进一步在屏幕上显示所述布局文件，以及根据用户对所述布局文件的编 辑操作更新所述布局文件。
7. 根据权利要求5或6所述的数据处理装置，其中，所述编辑处理 单元在所述编辑屏幕中初始化并显示所述模式信息中包括的各元素的显 示布局。
8. 根据权利要求7所述的数据处理装置，其中，所述编辑处理单元 根据所述模式信息中所示的元素结构初始化各元素的显示布局。
9. 根据权利要求5至8的任意一项所述的数据处理装置，其中，所 述编辑处理单元在所述编辑屏幕上显示用于选择所述布局文件的显示形 式的输入界面，
全文摘要
简易地设计用于编辑结构化文档文件的用户界面屏幕。从定义源文件元素结构的模式文件生成绑定文件。通过绑定文件设计用于编辑源文件的显示布局，其结果作为布局文件保存。用户还可以编辑布局文件。从布局文件和绑定文件生成XSLT文件，生成定义文件以从XSLT文件生成用于编辑源文件的用户界面屏幕。
文档编号G06F17/21GK101268438SQ20068003414
公开日2008年9月17日 申请日期2006年9月15日 优先权日2005年9月16日
发明者松本宪幸 申请人:佳思腾软件公司