带有正向和反向轴的流式xpath处理的方法

专利名称：带有正向和反向轴的流式xpath处理的方法
技术领域：
本发明广泛地涉及信息处理系统的领域，具体来说涉及搜索数据结构的领域。
背景技术：
术语的定义XML-可扩展的标记语言(XML)描述一类叫做XML文档的数据对象，并部分地描述了处理它们的计算机程序的行为。XML文档由叫做实体的存储单位组成，实体包含已分析的或未分析的数据。每一个XML文档都包含一个或多个元素，元素之间的边界由开始标记和结束标记分隔，或者对于空的元素，由空元素标记分隔。来自www.XML.com网站。
XPath-XML PATH语言。XPath 1.0作为一种解决XML文档的一部分的语言，是诸如可扩展的样式表语言转换(XSLT)和XQuery之类的进行XML处理的语言的整体组成部分。AlanFreedman，Computer Desktop Encyclopedia，9thEdition，Osborne/McGraw-Hill(2001)(下文将简称为“Freedman”)。
XSLT-可扩展的样式表语言转换。一种将XML文档转换为其他XML文档的语言(来自http//www.w3.org/TR/xslt)。
Xalan-Xalan是XSLT的Apache版本(请参阅http//xml.apache.org)。
DOM-文档对象模型。文档对象模型是一种不依赖于平台和语言的接口，它允许程序和脚本动态地访问和更新XML文档的内容、结构和样式。文档可以被进一步地处理，该处理的结果可以重新放回呈现的页中(来自http//www.w3c.org/DOM)。
SAX-XML的简单API。一种在XML分析器和XML应用程序之间的基于事件的编程接口(API)。基于对象的接口是由DOM提供的。Freedman。
XML的流式处理-XML文档的流式处理是给予一种对XML文档进行处理的类型的名称，在这种处理方式中，文档不必存储在内存中，文档中的每一个节点至多被访问一次。流式是一个一般概念。流式XPath处理是指在XML文档中“流过”时对XPath表达式进行计算的过程。
相关技术的描述基于事件的分析基于事件的分析器，例如，SAX分析器，对XML文档进行扫描，并在它识别到文档的元素标记以及其他组件时产生事件。每一个事件都传达对应元素的名称和级别。事件的产生相当于对文档树的深度优先、预先顺序的遍历，其中，对于每一个元素，生成开始元素事件，然后，以深度优先的顺序处理其子树，最后，生成结束元素事件。基于事件的分析器不会构建树，它们只是中继开始/结束标记(事件)是什么。这些事件由基于事件的分析器的客户端接收。客户端具有以它选择的任何方式处理这些事件的灵活性，包括存储一些事件，以及丢弃其它的事件。
XPath如上所述，XPath是一种解决XML文档的一部分的语言，是诸如XSLT和XQuery之类的语言的整体组成部分。这些语言的版本的性能取决于基础XPath引擎的效率。XPath表达式也有被用作访问XML文档的组成部分的通用机制，例如，在文档对象模型(DOM)3中提供了基于XPath的应用程序编程接口(API)，用于遍历DOM树。XPath表达式也已经在出版-预订系统中作为指定基于内容的预订的机制得到应用。
最新的XPath引擎，例如，随Xalan一起提供的一个，要求整个文档必须在内存中才能对XPath表达式进行计算。对于较大的文档，此方法可能导致开销无法接受。此外，Xalan中的XPath引擎以自然的方式对XPath表达式进行计算，并可能对输入文档执行不必要的遍历。例如，假定有选择文档中的x元素的所有y祖先的诸如/descendant∷x/ancestorty之类的表达式。Xalan XPath引擎是这样对此表达式进行计算的，对整个文档进行一次遍历以定位所有x元素，然后对于每一个x元素，访问其每一个祖先以定位相应的y元素。结果，文档中的一些元素被访问好几次。假设一个人希望定位名为“John”的具有名为“Fred”的所有人(节点)。Xalan引擎将遍历整个文档以访问每一个“John”节点。对于每一个这样的“John”节点，它将遍历其每一个祖先节点以确定他们中是否有人名为“Fred”。然后它将返回所有这样的“Fred”节点。显而易见，“John”节点的每一个祖先都至少被访问两次，一次在遍历以便找出 “John”节点期间，一次在从“John”节点遍历以找出“Fred”节点期间。
流式XPath处理在许多环境中，处理XML文档的自然方式是在文档中流动，即，在对输入文档进行分析时在输入文档上计算查询，只存储与查询的结果有关的文档的那些部分。
流式XPath的前提是，在许多情况下，可以在对XML文档进行的一次深度优先、文档顺序的遍历中计算XPath表达式。流式XPath的主要优点是它通过在内存中只存储与XPath的计算有关的文档的那一部分，而不是存储整个文档来优化内存利用效率；它加快了执行时间，因为算法刚好访问文档中的每一个节点一次，从而避免了不必要的遍历。
已知的处理流式XPath的方法所存在的局限性是，它只能在只包含正向轴的表达式上进行。如果表达式包含反向轴(如父母或祖先)，则无法对这样的表达式使用已知的流式XPath处理算法。
图1-XML文档的树状表示树是一个由节点组成的数据结构。其中一个节点特别地表示为根节点。树中的除了根节点之外的所有节点在树中都刚好具有一个父节点。XML文档可以表示为一个树，其节点表示文档元素、文本属性、注释和处理指令的结构组件。树中的父子边缘表示子组件包含在其父元素中，其中元素的范围由其开始和结束标记限定。对应于XML文档的树的根在一个包含文档元素的虚拟元素Root中。自此以后我们将就树状表示来讨论XML文档。一个人可以在树的节点上定义任意的顺序。一个这样的顺序可以基于对树的从左到右深度第一的遍历，对于XML文档的树状表示，这种遍历对应于文档顺序。
给定树上的一个顺序，我们可以在树上定义一个正向和反向关系的概念。关系R是一个正向关系，如果两个节点x和y之间存在关系R，必须是在树的顺序上x在y前面。同样，关系是一个反向关系，如果每当x与y有关时，那么必须是在树的顺序上x在y后面。例如，假设XML文档的树状表示的文档顺序，子关系和子代关系两者都是正向关系，而父关系和祖先关系两者都是反向关系。
图1说明了XML文档的树状表示。为简单起见，我们将专门讲述元素并忽略诸如属性和文本节点之类的项目。因此，树100由文档的虚拟根101和元素构成。为避免XML文档树100和XPath(稍后描述)的树状表示之间产生混淆，我们使用元素来指XML树100的节点。在XML树100中，方框中的标记表示对应的XML文档中的元素标记，标记旁边的括号中的数字表示基于事件的分析器访问节点的顺序。例如，节点102X(1)表示带有标记<X>的元素，是基于事件的分析器访问的第一个节点。对于此顺序，显然，每当一个元素(例如，102)是另一个元素(例如，101)的子元素时，那么，子元素就按此顺序位于父元素的后面。
图2-流式XPath流式XPath引擎是如图2所示的结构。XPath表达式211经过分析并被表示为自动机203。XPath引擎201使用分析器205产生的事件(例如，SAX事件)，对于每一个事件，自动机203可以进行状态转移，如有必要，还存储元素。在处理完文档207之后，XPath引擎返回元素209的列表，元素209是对XPath表达式211进行计算的结果。
若没有流式处理，当接收到XML文档时，对它进行处理，并构建树状表示。该整个树状表示必须保留在内存中才能从该树对表达式进行XPath处理。而有了流式处理，则不必构建整个树；而在生成事件时对它们进行处理。这就是为什么流式处理对于无限文档非常关键的原因。对于无限文档，无法构建一个树，因为数据是动态地生成的，因此，树的大小不是有限的。无限文档的一个例子是证券报价文档，其中的数据(股票价格)是动态地生成的。当前对XML文档进行流式处理的方法的缺点是，只能处理正向轴。给定XPath在XML堆栈中扮演的中心角色，用于改进计算包含反向轴的XPath表达式的性能的算法是必需的。

发明内容
根据本发明，用于以流式方式计算同时包含反向(如父母和祖先)和正向(如子和子代)轴的XPath表达式的方法包括许多步骤，下面将对这些步骤进行阐述。已知的XPath处理器只能处理正向轴。在对文档进行处理期间的任何时候，此方法都只保留对文档进行处理所需的最小元素集。


图1显示了根据现有技术的一个XML文档的树状表示。
图2是根据现有技术的流式XPath处理器的结构的方框图。
图3A显示了一个XPath表达式。
图3B显示了根据本发明的一个实施例的图3A的XPath表达式的树状表示。
图3C显示了根据本发明的一个实施例的图3B的XTree的非循环有向图表示。
图4显示了一个XML文档的树状表示。
图5显示了本发明的一个实施例的高级别流程图。
图6显示了本发明的一个实施例的详细的流程图。
图7A显示了一个XPath表达式。
图7B显示了根据本发明的一个实施例的图7A的XPath表达式的XTree表示。
图8显示了根据本发明的一个实施例的图7B中的XTree的XDAG表示。
图9是根据本发明的一个实施例的对图1的XML文档100上的图7A的XPath表达式进行处理结束时匹配结构的方框图表示。
图10是被配置为根据本发明的一个实施例进行操作的信息处理系统的简化方框图。
具体实施例方式
图3A、3B和3C-XPath表达式、树状表示和DAGXML文档的表示假设我们有一个树，在该树中，每一个节点都带有标记(其中，相同的标记可以出现在多个节点上)。假设有一个这样的问题定位树中的标有C的所有节点，并且这些节点同时具有标有A的祖先和标有B的祖先。这对应于如图3A所示的标有301的XPath表达式/descendant∷Aldescendant∷C[ancestor∷B]。图3B中提供了此表达式的树状表示，图3C中提供了非循环有向图(DAG)版本，带有标有302、304、306和308的节点。
图4-XML文档的树状表示例如，请看如图4所示的树。假设404和406两个节点，这两者都标有C。节点404具有标有B的祖先403，但没有标有A的祖先。因而，节点404不满足要求。而在另一方面，节点406同时具有标有B的祖先403和标有A的祖先405，因此，满足该要求。
我们的要求可以以一组约束来表达，其中每个约束呈现S1→S2的形式，其中S1和S2是标记集。图3B中的树和图3C中的DAG两者都是这些约束的等效的图形表示。它们用于将输入XPath表达式转换成一组约束。例如，上述XPath表达式可以用下面的约束集来表示1{Root}→(A，B}2{A，B}→{C}3{C}→{}图5-高级流程图请参看图5，有一个流程图，显示了根据本发明的一个实施例的算法如何处理图4的树，计算满足上述约束的标有C的节点406的集的一组约束。该流程图含蓄地假设使用下面的从根开始的步骤对树进行遍历(由基于事件的分析器进行)I.发出“开始”节点事件；2.以从左到右的顺序递归地访问子节点；以及3.发出“结束”节点事件。
我们从一组活动条件502开始。在此例子中，当我们开始时唯一的活动条件是{Root}。对于在504中处理的每一个节点，我们将在步骤506中检查该节点是否匹配某些活动条件。如果匹配，那么算法将在步骤508中检查对应于任何约束的左侧的条件集是否完全满足。如果满足，那么在步骤510中我们将检查约束的右侧的条件集是否为空的。如果不是空的，我们在步骤512中将此条件集添加到活动条件集。如果该条件集是空的，我们将在步骤514中检查是否满足所有约束。如果满足，那么我们已经找到一个解答。否则，我们继续处理下一个节点。在图6的流程图中描述了比较详细的过程的一步步的说明。算法按如下方式继续进行
图6-详细的流程图1.当我们在610中看到标有“Root”的节点401的开始事件时，我们将检查该事件是开始事件还是结束事件。由于这是一个开始事件，接下来我们将在步骤612中检查节点是否匹配任何活动条件。在这种情况下，我们发现了一个匹配。接下来，我们判断是否需要添加任何新的条件。为此，我们在步骤614中判断已经满足的条件是否完全满足任何约束的左侧。在这种情况下，我们判断约束{Root}→{A，B}的左侧已得到完全满足。对于所有这样的约束，我们将右侧的条件添加到活动条件集。在这种情况下，在步骤618中，条件A和B被添加到活动条件集。处理过程返回到步骤602以检查是否更多的事件。由于有另一个事件要处理，如在判断步骤602中所判断的，在步骤606中读取该事件。
2.接下来我们进入步骤606以处理另一个树事件，并看到标有D的节点402的开始事件。在判断步骤612中，我们看到此事件不匹配任何活动条件之后，因此在步骤613中被丢弃或者被过滤。
3.接下来，我们看到标有D的节点402的结束事件。由于当我们看到节点402的开始时没有添加任何条件，因此在608中没有条件需要从活动集中除去，从而将我们带回到步骤602以处理另一个事件。
4.接下来，我们看到标有B的节点403的开始事件。在步骤612中判断此节点匹配一个活动条件。然而，没有新条件可以由于此事件而添加，因为没有满足约束的左侧的完整的条件集。
5.接下来，我们看到标有C的节点404的开始事件。在步骤612中判断此节点也不匹配任何活动条件，因此在步骤613中被丢弃。
6.接下来，我们看标有C的节点404的也没有产生变化的结束事件。
7.接下来，我们在步骤610中看到标有A的节点405的开始事件。如在判断步骤612中所判断的，此节点匹配一个活动条件。此外，现在在步骤614中完全匹配约束{A，B}→{C}的左侧，从而导致在步骤618中条件C被添加活动集。
8.接下来，我们在步骤610中看到标有C的节点406的开始事件。在步骤612中判断此事件匹配一个活动条件之后，则在步骤614中判断此事件进一步完全满足约束{C}→{}的左侧。在步骤616中检查约束的右侧是空的之后，我们在步骤620中传播匹配信息。此时，我们将在步骤622中检查是否满足所有约束，在这种情况下，答案是肯定的。因而，我们在步骤624中输出节点406作为一个解答节点。
9.接下来，我们看到节点406的没有影响的结束事件。
10.接下来，我们看到节点405的结束事件，该事件导致C在步骤608中从活动条件集中除去。
11.接下来，我们看到节点403的没有影响的结束事件。
12.最后，我们看到节点401(根节点)的结束事件，该事件导致A和B在步骤608中从活动集除去，在步骤602中判断没有更多事件要处理之后，算法在604结束。
图7A和7B-分别是XPath表达式和其XTree表示此算法在XPath表达式的叫做XTree和XDAG的两个表示上操作。请参看图7B，您将看到表示图7A的XPath表达式的XTree 700。对应于W 706的圆圈的边比较粗，表示这样的事实它是输出节点。
我们用有标记的顶点(V)和边(E)来将XPath表达式表示为有根的树，叫做XTree(T)，以使T＝(Vt，Et)，其中根节点701被标记为Root。我们将使用术语“有限制的XPath”或Rxp，来指图7A中的输入XPath表达式。我们使用术语x节点来指XTree的顶点。图7B中的x节点显示为编号为701、702、704、706、708和710的圆圈。图7A中的XPath表达式包括许多x∷y形式的步骤。例如，出现在XPath表达式中的一个步骤是descendanu:w。对于任何步骤x∷y，我们称x为步骤的轴，称y为NodeTest。例如，在步骤descendant∷w中，轴是“descendant”，NodeTest是“w”。如果该文档中的一个元素的标记与NodeTest相同，则该元素匹配NodeTest。对于表达式中的每一个NodeTest，在标有NodeTest的XTree中都有一个x节点。每一个x节点(Root 701除外)有一个独特的进入边，该边标有在NodeTest之前指定的Axis。其中一个x节点被指定为输出x节点。在这种情况下，它是节点706。有返回分别与x节点和边关联的标记的函数labelVτ→String，and axisEτ→{ancestor，parent，child，descendant}。附录A中提供了从Rxp构建XTree的规则。
图8-图7A的XPath表达式的XDAG表示。
XDAG是此方法中的关键结构，因为它将诸如父之类的反向约束转换为正向约束，因此，使得对于包含反向轴的表达式进行流式处理成为可能。XDAG是从XPath表达式创建的内部数据结构的图形表示。它表示XPath表达式以及其所有约束。
将反向约束转换为正向约束是通过修改约束而不修改查询的含义来完成的。为进行说明，前面我们使用了定位带有名为“Fred”的祖先节点的所有“John”节点的示例。利用XDAG表示，我们将修改约束以定位所有“Fred”节点，然后定位这些“Fred”节点的所有名为“John”的后代节点，而不是“定位带有祖先′Fred′的′John′节点”的原始约束。图8显示了显示为XTree 700的XPath表达式的XDAG表示。XDAG 800是通过将树中的祖先和父约束重新表述为为后代和子约束来从XTree 700获取的。可以通过查看图7B和图8来看到将反向(祖先)约束更改为正向(后代)约束的图形示例。在图8中，您看到从x节点(顶点，或v)W 806(表示为v1)到Z 808(表示为v2)的线条(边，或e)。该边(e＝v1，v2)被标记为“后代”，而在图7中，从W 706到Z708的边(e＝v1，v2)被标记为“祖先”。
XDAG 800可以进一步被描述为Rxp的有向非循环图表示。更准确地，它是有向的标记图(G)，由边和顶点围住，以便G＝(Vg，Eg)，带有与XTree 700(T)相同的顶点集，边按下列方式定义1.T 700中的标记为“子”或“后代”的边也是G 800的边。如果您查看图7B，它显示了标记为“子”或“后代”的四个边。图8也显示了这些边。
2.对于T 700中的标记为“父”的每一个边，在G 800中有一个连接相同节点但带有颠倒的方向和更改为“子”的标记的边。同样，T 700中的“祖先”边被颠倒，并在G 800中被重新标记为“后代”边。图7B显示了从W 706到Z 708被标记为“祖先”的边，而图8显示了从Z 808到W 806被标记为“后代”的边。
3.对于任何没有进入边的非根x节点v∈G，一个“后代”边被从Root 801添加到v。由于T 700中的从W 706到Z708的边被重新标记为“后代”，Z 708现在没有进入边，因此，在图8中，一个边从Root 801添加到Z 808，现在使Z 808成为Root 801的后代。
值得注意的是，XDAG 800是一个有向非循环图。对于使用反向轴的XPath表达式，上述方法将始终生成有向非循环图，而不是树。
我们使用基于匹配的概念在XTree上定义的XPath表达式的交替语义。此语义相当于XPath 1.0规范中提供的语义。匹配结构的构建，匹配的紧密表示是该算法的主要目标。我们在本节描述了这些概念。
图9-匹配结构此方法通过对输入表达式211的XTree和XDAG视图进行操作来在基于事件的分析器生成事件时处理事件。我们在这里将输入XPath表达式211称为“有限制的XPath”或Rxp。在对文档处理结束时，Rxp表达式的结果以M编码。为提高效率，此方法过滤掉不对任何匹配起作用的事件。只处理相关的事件以生成匹配-结构。我们将在本节描述这些步骤。附录B中提供了图7A的Rxp和图1的文档100的算法的过程。
假设v1和v2是由边e连接的XTree T中的两个x节点，假设d1和d2是文档D中的两个元素。如果d1和d2满足关系axis(e)，我们说(v1，d1)与(v2，d2)一致(相对于XTree T和文档D)。例如，如果v1和v2由标记为“祖先”的边连接，那么d2必须是D中的d1的祖先。匹配mVT→VD是从XTree T的x节点到文档D的元素的部分映射，以便下列条件成立1.对于所有x节点v∈domain(m)，label(v)＝tag(m(v))，即，所有映射的顶点都满足NodeTest。
2.对于所有由T中的一个边连接的x节点v1和v2，以便v1，v2∈domain(m)，(v1m(v1)与(v2，，n(v2))一致。
一个匹配位于x节点v，当且仅当其域包含在根在v的子树中。如果其域包含根在v的子树的所有顶点，则在v的匹配是总匹配。不难证明，当且仅当在r的XTree T的根处有一个总匹配，其中T的输出x节点映射到n，文档元素n位于Rvp r的结果中。此方法用这样的方式准确地计算由Rxp定义的结果。它找到了从VT到VD的所有匹配，并发送对应于输出x节点的文档元素。
该算法构建了一个叫做匹配-结构的数据结构，该结构是相对于输入文档207的Rxp的根处的所有总匹配。一个匹配-结构Mv，e与x节点v关联，并表示v处的匹配集，其中v映射到文档元素e。匹配-结构Mv，e另外还包含XTree中的v的每个子的子匹配。v的子w的子匹配是w处的匹配结构集(可能是空的)。对于w处的Mv，e的子匹配中的任何匹配-结构Mv，e，我们要求(v，e)与(w，e′)一致。如果v是XTree T中的w的父，并且(v，e)与(w，e′)一致，则就可以说匹配-结构Mv，e是匹配-结构Mw，e的父匹配。如果Mw，e是Mv，e的父匹配，那么我们还说，Mw，e是Mv，e的子-匹配。图9显示了在图1中的文档100上的图7A的XPath处理结束时的匹配结构，以及根801处的四个总匹配。图9中的方框表示匹配结构。对于匹配-结构Mv，e，方框的顶部显示了(v，id(e))。方框的下半区中的每个插槽都对应于一个子匹配，该子匹配表示为指向子匹配的指针的列表。进行W投影所获得的结果，即{W6，4，W7，5}Total Matchinas at Root[Root→0，Z→3，Y→2，U→8，V→4，W→6][Root→0，Z→3，Y→2，U→8，V→4，W→7][Root→0，Z→3，Y→2，U→8，V→5，W→6][Root→0，Z→3，Y→2，U→8，V→5，W→7]Solution{W6，4，.W7，5}过滤事件在执行过程中的任一点，算法都处理输入文档207的前缀。无限数量的XML文档共享同一个前缀，因此，无法预测将由分析器生成的未来的事件序列。如果有一些文档完成，其中e参与匹配，则元素e是相关的。所有相关的元素都必须得到处理。随着对元素进行处理，可能会看见新的相关元素，或者，早先被认为是相关的元素可能不再相关。使用Rxp的XDAG表示来判断元素是否相关。
与任何x节点都不匹配的元素是不相关的，因为它不能参与任何匹配。这些元素将被丢弃。假设open元素是我们看作开始元素事件，而不是结束元素事件的那些元素。由于生成事件的方式是深度优先方式，在匹配x节点v的开始元素事件，open元素是文档中的e的祖先。如果对于XDAG中的v的v′的一些父，没有open相关元素e′，以便(v，e)和(v′，e′)是一致的，那么，e无法相关。没有分析器可以生成的其中该约束将成真的事件序列，因此，e不对任何匹配起作用。对于图8中的XDAG，没有匹配W的元素将是相关的，除非有匹配Y和Z的open相关元素。
在每一步骤，我们维护了一个定位集L，该集可使我们评估与下一个开始元素事件关联的元素是否相关。L的成员是(v∈Vp，，level)对，其中level可能是整数或*。当且仅当有(v，level)∈L，label(v)＝tag(e)，并且(level＝level(e)or level＝*)时，与开始元素事件关联的元素e才是关联的。整数级别用于强制约束，如果(v，e)和(，v′e′)是一致的并且如果axis(v，v′)＝child，那么level(v′)＝1+level(v)。
我们从现在开始假设，对应于不相关的元素的所有事件都已经被丢弃。当此算法处理匹配x节点v的元素e的开始元素事件时，它创建一个匹配-结构Mv，e来表示该匹配。请注意，e可能匹配XTree 700中的一个以上的x节点；并为每个这样的匹配创建一个匹配-结构。这些匹配-结构的子匹配最初是空的。算法将这些匹配-结构缝合在一起，以便当看见文档的结尾时，MRoot，Root对文档中的根处的所有总匹配进行编码。
此过程中的关键步骤是传播。在匹配x节点v的元素e的结束元素事件，我们试图判断Mv，e是否表示v处的总匹配。如果有总匹配，我们将Mv，e插入到其父-匹配的相应的子匹配。此传播可能是乐观的，因为随着处理更多的事件，一个人可能必须撤消传播。然而，让我们首先假设一个当XTree 700不包含标记为“祖先”或“父”时没有必要清除传播的比较简单的情况。这对应于只使用子和后代轴的Rxps，即，没有任何反向轴。
当XTree 700只包含child和descendant约束时，v处的任何总匹配m，其中m(v)＝e将v的子树中的所有x节点映射到位于e的文档子树中的元素。由于总匹配包含在e的子树内，等到看见e的结束元素事件时，我们可以确定地判断Mv，e是否表示v处的总匹配。这自然导致生成匹配的一个归纳法。对于结束元素事件e，其中Mv，e是匹配-结构1.如果v是XTree 700中的叶，我们通过定义(v没有子树)表示v处的总匹配。我们将Mv，e传播到相应的父匹配。
2.如果v不是叶，则当且仅当所有子匹配是非空时，Mv，e表示v处的总匹配。否则，没有总匹配存在。如果我们找到XTree中的v的每个子的相应的总匹配，则等到处理e的结束元素事件时它们将被传播到Mv，e。如上，如果Mv，e表示总匹配，则我们将它传播到所有相应的父-匹配。
如果在处理文档207结束时(当我们接收到根的结束元素时)，算法发现Mroot，root的所有子匹配都是非空，则我们在根处具有总匹配。
XTree 700中的祖先和父边的存在使此处理复杂化，因为一个人不能确定地判断到元素e结束之时是否存在Mv，e的总匹配。例如在图7B中，一个人可能在看到匹配W的元素的结束事件之前找不到根在Z的子树的总匹配。传播过程保持一样，只是具有标记为祖先或父的进入或外出边不同。修改的步骤如下所示1.如果有标记为祖先或父的外出边(v，v′)，并且v′的子匹配是空的，我们不能断言，在v处没有总匹配。我们乐观地将每个子-匹配Mv′，e′传播到Mv，e的相应的子匹配。然后如以前一样进行。如果满足所有子匹配，则Mv，e传播到其父-匹配。
2.如果有标记为祖先或父的进入边(v′，v)，那么，Mv，e可能被乐观地传播到其父-匹配。如果我们可以确定地判断，Mv，e不能表示v处的总匹配，我们撤消Mv，e的传播。从父-匹配Mv′，e′的子匹配删除Mv，e可能导致子匹配变空-Mv′，e′不再是v′处的总匹配。然后我们递归地从其父-匹配撤消Mv′，e′的传播。
在处理文档207结束时，如果MRoot，Root的子匹配都是非空的，我们在根处至少有一个总匹配。当我们访问Mv，e时，其中v是Rxp的输出x节点，通过遍历图9所示的匹配结构900，并发送元素e来发送输出。例如，在图9中，当我们首先访问Mw，6时，我们输出W6，4，当我们首先访问Mw，7时，输出Mw，7。
我们就存储所有匹配，随后，遍历匹配结构以发出元素来描述了此算法。然而，我们不必为XTree中的许多x节点生成匹配结构。例如，如果XTree包含不包含输出节点的子树，那么，就不必为该子树中的节点存储匹配结构。存储关于在该子树中是否存在总匹配的布尔值就足够了。此外，常常也不必等到文档的结尾才发送输出。元素可以更渴望地发出。
XPath表达式的应用于数据库的一个扩展是，在一个XPath中允许有一个以上输出节点。如果我们使用“$”来标记输出节点，扩展的XPath表达式，//$a/$b返回一个输入文档中的所有(a，b)对，以便a是b的父。我们的匹配结构容易产生这些字节组-只有更改位于输出遍历中。
或者可以通过将XPath表达式转换为“析取范式”的等效表达式来对表达式进行处理。算法可以在最高级别的每个操作数上运行，或者独立地运行。虽然此处理可能是XPath表达式的大小的指数，但是我们不认为这是问题，因为XPath表达式一般来说是比较小的。
图10-信息处理系统图10是被配置为根据本发明的一个实施例进行操作的信息处理系统1000的简化方框图。系统1000包括输入/输出(I/O)接口1060，用于接收包括搜索条件的查询。条件包括一组指定节点之间的正向和反向关系的约束。I/O接口1060进一步用于接收至少一部分文档，如XML文档207(例如，通过包括XML阅读器)。系统1000进一步包括用于通过将指定反向关系的约束重新表述为指定正向关系的约束来修改搜索条件的逻辑；用于创建内部数据结构的逻辑；和用于定位满足搜索条件的一个或多个节点的逻辑。此逻辑可以作为存储在大容量存储设备1030或诸如磁盘1040或CD ROM1050之类的介质中的程序指令来实现，以便由系统处理器1010从从存储器1020进行处理。系统1000只是根据本发明的执行方法和算法的一个可能实施方式。那些精通数据处理技术的人将理解，在不脱离本发明的精神的情况下，其他实施方式也是可以的。
结束语和范围此方法是以流式XPath处理正向和反向轴的新颖的算法。此处理流式XPath表达式的方法的优点是它只须存储文档的相关部分，因此，它节省了存储器空间；它还节省了定位表达式的时间，因为文档的部分只遍历一次；以及，它还节省金钱，因为由于如前所述的好处处理速度更快。
因此，虽然描述了目前被视为优选实施例的情况，那些精通本技术的人将理解，在不脱离本发明的精神的情况下，可以进行其他修改。
附录A生成XTree的规则我们用带标记的顶点和边T＝(VT，ET)来将Rxp表达式表示为有根的树，叫做XTree，其中根被标记为Root。对于表达式中的每一个NodeTest，在标有NodeTest的XTree中都有一个x节点。每一个x节点(Root除外)有一个独特的进入边，该边标有在NodeTest之前指定的Axis。其中一个x节点被指定为输出x节点。有返回分别与x节点和边关联的标记的函数labelVT→String，and axisET→{ancestor，parent，child，descendant}。还为RelLocationPath定义了类似于XTree的结构。我们将此结构叫做x林，因为它由两个有根树构成，一个树的根位于Root，另一个树的根位于标记为context的特殊x节点，它类似于Root，没有进入边。对应于PredicateExpr的结构可以是XTree或x林，但没有一个x节点被指定为输出x节点。
可以归纳地(基于Rxp的结构)使用下列规则来从Rxp生成XTree。
Step∷＝Axis∷NodeTest Step的x林包含三个标记为Root、context和NodeTest(指定为输出节点)的x节点，从context到NodeTest的边被标记为Axis。
Step∷＝Step1′[′PredicateExp′]′让T1来评估从Step1产生的x林，T2引用从PredicateExpr产生的x林或XTree。Step的x林是通过将T1的输出x节点与T2(如果有的话)的context x节点合并以及将T1和T2的Root x节点合并获得的。T1的输出x节点被指定为结果x林的输出x节点。
RelLocationPath∷＝Step′[′RelLocationPath′]′让T1和T2分别引用从Step和RelLocationPath获得的x林。RelLocationPath的x林是通过将T1的输出x节点与T2的context x节点合并，并将T1和T2的Root x节点合并，并将T2的输出x节点指定为结果x林的输出x节点来获得的。
PredicateExp∷＝RelLocationPath and PredicateExpr，让T1引用从RelLocationPath获得的x林，T2引用从PredicateExpr1获得的XTree或x林。PredicateExpr的x林是通过将T1的context与T2(如果有的话)的context合并以及将T1和T2的Root合并获得的。没有一个x节点被指定为输出顶点。
PredicateExpr∷＝AbsLocationPath and PredicateExpr1，；类似于前面的情况。
AbsLocationPath∷＝′[′RelLocationPath′]′XTree是通过将从RelLocationPath获得的x林的Root和context x节点获得的。
附录B





权利要求
1.一种用于处理文档的方法，其特征在于，文档包括树结构，树结构又包括许多分支，分支又包括许多节点，该方法包括下列步骤接收包括搜索条件的查询，其中，该条件包括一组约束，这些约束指定节点之间的关系，其中，任何两个节点之间的关系可以是正向关系，也可以是反向关系，以便在约束集中指定的关系可以是正向关系、反向关系或者两者都是；接收至少一部分文档；修改搜索条件，以便指定反向关系的约束可以重新表述为指定正向关系的约束，或者指定正向关系的约束可以重新表述为指定反向关系的约束；使用修改的条件处理文档；以及定位满足搜索条件的一个或多个节点。
2.根据权利要求1所述的方法，其特征在于，文档是一个XML文档。
3.根据权利要求1所述的方法，其特征在于，修改搜索条件的步骤包括生成新条件。
4.根据权利要求1所述的方法，其特征在于，处理步骤包括创建查询的图形表示。
5.根据权利要求1所述的方法，其特征在于，处理步骤包括创建至少一部分文档的树状表示。
6.根据权利要求1所述的方法，进一步包括生成只包括那些与搜索条件有关的节点的匹配结构。
7.根据权利要求6所述的方法，进一步包括生成匹配结构，以便结构从根节点开始。
8.根据权利要求5所述的方法，进一步包括过滤文档以排除与搜索条件不匹配的任何节点。
9.根据权利要求1所述的方法，其特征在于，所处理的至少一部分文档包括的内容小于整个文档。
10.根据权利要求2所述的方法，其特征在于，查询包括至少一个XPath表达式。
11.根据权利要求1所述的方法，其特征在于，文档是一个无限的文档。
12.根据权利要求1所述的方法，其特征在于，定位满足搜索条件的节点的步骤进一步包括将该节点作为输出发送。
13.根据权利要求1所述的方法，其特征在于，约束指定节点之间的关系，关系包括父子关系。
14.根据权利要求1所述的方法，其特征在于，约束指定节点之间的关系，关系包括祖先和后代关系。
15.一种用于处理文档的系统，其特征在于，文档包括树结构，树结构又包括许多分支，分支又包括许多节点，该系统包括一个用于接收包括搜索条件的查询的输入端，其中，该条件包括一组约束，这些约束指定节点之间的关系，其中，任何两个节点之间的关系可以是正向关系，也可以是反向关系，以便在约束集中指定的关系可以是正向关系、反向关系或者两者都是；一个用于接收至少一部分文档的输入端；用于修改搜索条件的逻辑，以便指定反向关系的约束可以重新表述为指定正向关系的约束，或者指定正向关系的约束可以重新表述为指定反向关系的约束；用于使用修改的条件处理文档的处理器；以及用于定位满足搜索条件的一个或多个节点的逻辑。
16.根据权利要求15所述的系统，其特征在于，文档是一个XML文档。
17.根据权利要求15所述的系统，其特征在于，用于修改搜索条件的逻辑进一步包括生成新条件。
18.根据权利要求15所述的系统，其特征在于，用于处理文档的处理器进一步包括用于创建查询的图形表示的逻辑。
19.根据权利要求15所述的系统，其特征在于，用于处理的逻辑包括创建至少一部分文档的树状表示。
20.一种包括用于处理文档的程序指令的计算机可使用的介质，其特征在于，文档包括树结构，树结构又包括许多分支，分支又包括许多节点，介质包括用于执行下列步骤的指令接收包括搜索条件的查询，其中，该条件包括一组约束，这些约束指定节点之间的关系，其中，任何两个节点之间的关系可以是正向关系，也可以是反向关系，以便在约束集中指定的关系可以是正向关系、反向关系或者两者都是；接收至少一部分文档；修改搜索条件，以便指定反向关系的约束可以重新表述为指定正向关系的约束，或者指定正向关系的约束可以重新表述为指定反向关系的约束；使用修改的条件处理文档；以及定位满足搜索条件的一个或多个节点。
全文摘要
一种用于处理诸如XML文档的文档的系统和方法，其特征在于，该方法包括下列步骤接收包括搜索条件的查询；接收至少一部分文档；修改搜索条件，以便指定反向关系的约束可以重新表述为指定正向关系的约束；使用修改的条件处理文档；以及定位满足搜索条件的一个或多个节点；以及作为输出发送所选节点。
文档编号G06F7/00GK1497474SQ0315984
公开日2004年5月19日 申请日期2003年9月26日 优先权日2002年10月3日
发明者查尔斯·巴顿, 查尔斯 巴顿, 查尔斯, 飞利浦·查尔斯, 格瑶, 蒂帕克·格瑶, 瑞格哈瓦查瑞, 穆康德·瑞格哈瓦查瑞 申请人:国际商业机器公司