术语的定义
XML-可扩展的标记语言(XML)描述一类叫做XML文档的 数据对象，并部分地描述了处理它们的计算机程序的行为。XML文 档由叫做实体的存储单位组成，实体包含已分析的或未分析的数据。 每一个XML文档都包含一个或多个元素，元素之间的边界由开始 标记和结束标记分隔，或者对于空的元素，由空元素标记分隔。来自 www.XML.com网站。
XPath-XML PATH语言。XPath 1.0作为一种解决XML文 档的一部分的语言，是诸如可扩展的样式表语言转换(XSLT)和 XQuery之类的进行XML处理的语言的整体组成部分。Alan Freedman，Computer Desktop Encyclopedia，9th Edition， 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文档中的元素标记，标记旁边的括号中的数字表示基于 事件的分析器访问节点的顺序。例如，节点102 X(1)表示带有标记 的元素，是基于事件的分析器访问的第一个节点。对于此顺 序，显然，每当一个元素(例如，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表达式、树状表示和DAG
XML文档的表示
假设我们有一个树，在该树中，每一个节点都带有标记(其 中，相同的标记可以出现在多个节点上)。假设有一个这样的问题： 定位树中的标有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。对应于W706的圆圈的边比较粗，表示这样的事实： 它是输出节点。
我们用有标记的顶点(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::，我们称x为步骤的轴，称y为 NodeTest。例如，在步骤descendant::w中，轴是“descendant”， NodeTest是“w”。如果该文档中的一个元素的标记与NodeTest 相同，则该元素匹配NodeTest。对于表达式中的每一个NodeTest， 在标有NodeTest的XTree中都有一个x节点.每一个x节点 (Root 701除外)有一个独特的进入边，该边标有在NodeTest之 前指定的Axis。其中一个x节点被指定为输出x节点。在这种情 况下，它是节点706。有返回分别与x节点和边关联的标记的函 数：label:Vτ→String，and axis:Eτ→{ancestor，parent，child， descendant}。附录A中提供了从Rxp构建XTree的规则。
图8-图7A的XPath表达式的XDAG表示。
XDAG是此方法中的关键结构，因为它将诸如父之类的反向约 束转换为正向约束，因此，使得对于包含反向轴的表达式进行流式处 理成为可能。XDAG是从XPath表达式创建的内部数据结构的图形 表示。它表示XPath表达式以及其所有约束。
将反向约束转换为正向约束是通过修改约束而不修改查询的含 义来完成的。为进行说明，前面我们使用了定位带有名为“Fred” 的祖先节点的所有“John”节点的示例。利用XDAG表示，我们 将修改约束以定位所有“Fred”节点，然后定位这些“Fred”节点 的所有名为“John”的后代节点，而不是“定位带有祖先′Fred′的′ John′节点”的原始约束。图8显示了显示为XTree700的 XPath表达式的XDAG表示。XDAG 800是通过将树中的祖先和 父约束重新表述为为后代和子约束来从XTree 700获取的。可以通 过查看图7B和图8来看到将反向(祖先)约束更改为正向(后 代)约束的图形示例。在图8中，您看到从x节点(顶点，或v) W 806(表示为v1)到Z 808(表示为v2)的线条(边，或e). 该边(e＝v1，v2)被标记为“后代”，而在图7中，从W 706到Z 708的边(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节点vG，一个“后 代”边被从Root 801添加到v。由于T 700中的从W 706到Z 708的边被重新标记为“后代”，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的祖先。匹配m:VT→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 ROM 1050之类的介质中的程序指令来实现，以便由系统处理器1010从 从存储器1020进行处理。系统1000只是根据本发明的执行方法和 算法的一个可能实施方式。那些精通数据处理技术的人将理解，在不 脱离本发明的精神的情况下，其他实施方式也是可以的。
结束语和范围
此方法是以流式XPath处理正向和反向轴的新颖的算法。此处 理流式XPath表达式的方法的优点是：它只须存储文档的相关部 分，因此，它节省了存储器空间；它还节省了定位表达式的时间，因 为文档的部分只遍历一次；以及，它还节省金钱，因为由于如前所述 的好处处理速度更快。
因此，虽然描述了目前被视为优选实施例的情况，那些精通本 技术的人将理解，在不脱离本发明的精神的情况下，可以进行其他修 改。
附录A
生成XTree的规则
我们用带标记的顶点和边T＝(VT，ET)来将Rxp表达式表示 为有根的树，叫做XTree，其中根被标记为Root。对于表达式中的 每一个NodeTest，在标有NodeTest的XTree中都有一个x节 点.每一个x节点(Root除外)有一个独特的进入边，该边标有在 NodeTest之前指定的Axis。其中一个x节点被指定为输出x节 点。有返回分别与x节点和边关联的标记的函数:label:VT→ String，and axis:ET→{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 S：Root0，0 (Root，0) 将(Y，＊)和 (Z，＊)加到 L，因为Root 匹配x-dag中 的它们的祖 先。 {(Y，＊)，(Z，＊)} 2 S：X1，1 放弃. {(Y，＊)，(Z，＊)} 3 S：Y2，2 (Y，＊) 将(U，3)加到 L，因为U通 过x-dag中的 子边连接到 Y，并且Y在 级别2匹配。 不要将W加 到L，因为没 有匹配x-dag 中的其Z父 的元素.继续 定位(Y，＊)， 因为此元素中 的子树中的带 有标记Y的 任何元素将是 匹配Y的候 选。 {(Y，＊)，(Z，＊)， (U，3)} 4 S：W3，3 放弃。此W {(Y，＊)，(Z，＊)}
  不相关，因为 它在L中没 有匹配。 5 E：W3，3 放弃。 {(Y，＊)，(Z，＊)} 6 S：Z4，3 (Z，＊) 开始定位 (V，4)，因为在 x-dag中有相 关的元素匹配 Z和Root。 在级别4定位 它，因为 (Z，V)是带有 标记的子。 {(Y，＊)，(Z，＊)， (W，＊)，(V，4)} 7 S：V5，4 (V，4) 停止定位 (V，4)，因为直 到此文档的结 尾，level>4。 {(Y，＊)，(Z，＊)，(W ，＊)} 8 E：V5，4 (V，4) 在V，Mv，5处 有总匹配。此 匹配-结构被 传播到Mz，4 (Mv，5的唯一 的父匹配)的 相应的子匹配 {(Y，＊)，(Z， ＊)，(W，＊)} 9 S：V6，4 (V，4) {(Y，＊)，(Z， ＊)，(W，＊)} 10 E：V6，4 (V，4) 再次将Mv，5 添加到Mz，4 的相应的子匹 {(Y，＊)，(Z， ＊)，(W，＊)，(V，4)}
  配。 11 S：W7，4 (W，＊) {(Y，＊)，(Z， ＊)，(W，＊)} 12 S：W8，5 (W，＊) {(Y，＊)，(Z， ＊)，(W，＊)} 13 E：W8，5 (W，＊) x-dag中的W 具有外出的 “祖先”边。 Mw，8的所有子 匹配，在此情 况下，Mz，4被 传播到Mw，8 的相应的子匹 配.Mw，7的所 有子匹配为非 空.Mw，8被传 播到My，2 {(Y，＊)，(Z， ＊)，(W，＊)} 14 E：W7，4 (W，＊) 如上，Mw，7被 传播到My，2。 {(Y，＊)，(Z， ＊)，(W，＊)，(V，4)} 15 E：Z4，3 (Z，＊) Z具有标记为 “祖先”的进 入边.由于满 足Mz，4，因此 没有必要清 除。 {(Y，＊)，(Z， ＊)，(U，3)} 16 S：U9，3 (U，3) {(Y，＊)，(Z，＊)} 17 E：U9，3 (U，3) {(Y，＊)，(Z， ＊)，(U，3)} 18 E：Y2，2 (Y，＊) My，2被满足， {(Y，＊)，(Z，＊)}
  因为对应于U 和W的两个 子匹配是非 空.传播 My，2，在根处 有总匹配 19 S：Y10，2 (Z，＊) {(Y，＊)，(Z， ＊)，(U，3)} 20 S：Z11，3 (Z，＊) {(Y，＊)，(Z， ＊)，(V，4)，(W，＊)} 21 S：W12，4 (W，＊) {(Y，＊)，(Z， ＊)，(W，＊)} 22 E：W12，4 (W，＊) 由于W没有 标记为“祖 先”的外出 边，将Mz，11 乐观地添加到 Mw，12的相应 的子匹配。由 于现在满足此 匹配，它被传 播到My，10 {(Y，＊)，(Z， ＊)，(W，＊)，(V，4)} 23 E：Z11，3 (Z，＊) Mz，11不满足- V的子匹配是 空的。撤消 Mz，11到Mw，12 的传播.由于 Mw，12现在不 再被满足，撤 {(Y，＊)，(Z， ＊)，(U，3)}
  消从Mw，12到 My，10的传播。 24 S：U13，3 (U，3) {(Y，＊)，(Z，＊)} 25 E：U13，3 (U，3) 总匹配，将 Mu，13传播到 My，10。 {(Y，＊)，(Z，＊)} 26 E：Y9，2 (Y，＊) 不满足My，10。 W的子匹配是 空的。不传播 任何东西。 {(Y，，＊)，(Z，＊)} 27 E：X1，1 放弃 {(Y，＊)，(Z，＊)} 28 E：Root0，0 (Root，0) 在对应于Y 的子匹配中没 有一项，满足 My，2.Mroot，0。 {(Root，0)}