用于可变模式的XML文档的XML查询方法和系统.pdf

用于可变模式的XML文档的XML查询方法和系统
技术领域
本发明涉及一种XML查询方法和系统，尤其涉及可变模式XML文档的XML查询方法和系统。
背景技术
XML(eXtensible Markup Language，可扩展标记语言)在很多领域被广泛使用以存储及交换数据。对于某些领域，例如临床文档架构(Clinical Document Architecture，CDA)或可扩展商业报告语言(eXtensible Business Reporting Language，XBRL)，有一个共同特征使得用户难于使用XML文档中的数据：模式是可变的(Variable Schema)。为了在基于多个不同模式的XML文档中构建正确的XQuery/XPath(XML查询/XML路径)，用户必须完全理解每个模式中的元素如何与其它元素相关，即XML树内部节点元素之间的结构关系以及不同XML树之间结构关系。对于用户而言，这需要耗费太多精力，在某些极端情况(例如，存在过多的模式)下甚至是不可能的。
下面具体解释现有技术处理上述问题的固有缺陷，即可变模式所引起的问题。该问题的根本原因在于在多个领域(例如临床文档架构、可扩展商业报告语言)，为了使用统一的语法对复杂数据进行灵活的表示和交换，广泛采取了模型驱动(Model-Driven-Approach，MDA)数据建模方法。在这样的方法下，通过将语法语义、词汇、数据结构、数据分别在元模型、模型、实例层进行描述和建模，可以不同的用户根据其应用需要而扩展/衍生基本模式，从而适应不同环境下的数据表示和交换要求。
参见图1，显示了采用模型驱动方案的XML语言体系架构1000。架构的最上层是元模型(Meta Model)1010，它包括语法(Syntax)和语义(Semantics)定义。在元模型之下定义了模型(Model)层1020，包括词汇库(Terminology)模型1021和模式(Schema)模型1022。词汇库定义了词库(Vocabulary)术语(Term)，模式模型定义了数据结构(data structure)。在模型之下可以定义数据(Data)1030，即实例层(Instance layer)。
进一步参见图2，以可扩展商业报告语言(XBRL)为例说明了图1所示的XML语言体系架构。如图2所示，XBRL的国际组织定义了XBRL规范，其中定义了元模型，包括报告建模所使用的语法。例如，商业报告中的每个报告元素substitutionGroup属性应被标记为“item”或者“tuple”。基于上述元模型，行业规范者(例如，美国证券交易委员会SEC和财务会计协会)定义了一些基本模式和术语，如报告项的词库等。例如，SEC定义了在财务报告中可以使用报告词汇“Revenue”(收益)以及”Revenue”元素可以出现在收益表中。各个上市公司自己又可以扩展这些基本模式，以得到定制化的报告模板。例如，A公司定义了Income-Revenue，即在A公司收益表中，Revenue出现在Income节点下；B公司定义了AccruedIncome-Revenue，即在B公司的收益表中Revenue出现在AccruedIncome节点下。基于上述扩展模式，各个公司可以生成具体的数据实例，例如所定义的报告项的具体数值。A报告的Revenue的数值为100万美元，B公司报告的Revenue的数值为$150万美元。
进一步参见图3，以临床文档架构(CDA)为例说明了图1所示的XML语言体系架构。如图3所示，CDA的国际组织定义了临床文档所使用的语法。例如定义一个临床医疗文档中可以包含Entity(实体)、Observation(观察)、Symptom(症状)和Body Struture(身体结构)等结构和概念。基于上述语法，标准化组织SNOMED(SystematizedNomenclature of Medicine)进一步定义了一些通用术语，即临床数据的词库。例如，SNOMED定义了Shadow(阴影)和Chest(胸部)等术语。基于语法和词库，医院、设备制造商等可以进行扩展，以得到各自的CDA文档模式。例如，Entity-observation-body-symptom(实体-观察-身体-症状)，以及Entity-body structure-symptom(实体-身体结构-症状)。基于上述模式，医院可以生成临床记录的数据实例，例如Tom-SNOMED CT-Chest-Shadow，即对Tom(汤姆)使用SNOMED CT观察到的Chest(胸部)的shadow(阴影)，其对应于上述模式Entity-observation-body-symptom；以及Lee-Chest-Shadow，即Lee(李)的Chest(胸部)的shadow(阴影)，对应于上述模式Entity-bodystructure-symptom。
自然地，用户可能会对上述XML文档进行查询。如图2所示，报告使用者(例如投资者、银行)需要利用XML数据而做出决定时，他们可能会进行如下查询：A和B公司过去三年的Revenue(收益)的平均增长率是什么？同样，如图3所示，临床文档使用者(例如医生、制药者)需要利用XML数据而做出决定时，他们会查询例如：胸部有阴影的病人清单。
但在现有技术中，执行上述常见查询是有困难且有缺陷的。因为尽管各个文档实例共享公共的语法和术语模型，但各个文档实例可以基于不同模式和数据结构。现有技术中，当构建对元素的XML查询时，用户需要知道每个文档的具体模式。也就是说，即使有公共的词库，数据使用者必须理解每个扩展模式才能正确地构建XQuery/XPath，而这些负担对于数据使用者是太大了。XQuery/XPath是现有技术已知的语言标准，在此不再详细叙述，可以参见例如http://www.w3.org/TR/xpath上定义的XPath(XML Path Language)，它是一种从XML文档选择节点的语言；以及参见例如http://www.w3.org/TR/xquery/上定义的XQuery，它是被设计用于查询XML数据集合的查询语言(带有一些编程语义的特征)。具体而言，参见图2，尽管A和B公司共享XBRL的语法和词库(例如Revenue)，但是它们各自定义了自己的扩展模式，因此具有不同的模式。当查询A和B公司的Revenue时，需要分别知道它们的具体模式结构，即在A定义的扩展模式中Revenue位于Income节点之下；而在B定义的扩展模式中Revenue在AccruedIncome节点之下。用户必须知道上述信息才能写出正确的XML路径或查询(XQuery/XPath)。进一步以图3为例，尽管共享CDA定义的语法和SNOMED定义的词库，医院仍可以扩展基本模式以得到各自不同的模式：Entity-observation-body-symptom，Entity-body structure-symptom。当用户查询胸部有阴影的病人时，需要知道不同模式的具体结构，即对于Tom而言，shadow在Tom节点下的observation(观察)节点下的Chest(胸部)节点下；对于Lee而言，shadow在Lee节点下的Chest(胸部)节点下。
因此，当存在多个不同的扩展模式时，即使这些模式都共享相同的语法和词库(即，基本模式)，用户仍需要知道每个扩展模式的特定结构才能进行查询，这对用户而言是极大的不必要的负担，甚至是不可能的。
对于扩展模式，可参见图4和5来说明现有技术中进一步的问题。图4显示了共享词库，包括元素1到元素5。元素1到元素5被图5a和5b模式共享，但是它们在图5a和5b模式中的结构关系不同。图5(a)和5(b)示出了两种不同模式，对比图5(a)和5(b)可知，即使查询相同元素也需要具有不同的查询路径。因此如果要对不同模式的XML文档进行查询，例如查询元素3，元素4，元素5，现有技术采用的一种方式是首先在XML文档中定位被查询对象在XML文档中的路径，然后根据路径查询对象。如上所述，这种方式的缺陷在于用户需要知道每个特定模式的具体结构。现有技术中的另一种方式是无模式的通配符查询。但是，通配符查询会失去查询对象之间的关系，因此它有很大的局限性，即仅适用于对单个对象的查询；当涉及多个元素、并且需要考虑元素之间的关系时，通配符查询不能返回所期望的结果。
图6例示了通配符查询的缺陷。
图6的最上方定义了一个简单的XML模式，元素a(根节点)之下具有元素1(子节点)和元素2(子节点)。
随后图6定义了一个XML实例为：
<elementa>
      <element1>1-1</element1>
      <element2>1-2</element2>
</elementa>
<elementa>
      <element1>2-1</element1>
      <element2>2-2</element2>
</elementa>
以上XML实例包括两个元素(elmenta)，其各自又具有2个元素1-1、1-2以及元素2-1、2-2。
假设用户查询为：选择所有的元素1和元素2。
采用通配符查询(即无模式的查询)时，依次输入\\element1和\\element2，得到的查询结果如图6的底部所示。尽管返回了元素1-1、元素1-2以及元素2-1、元素2-2，但是丢失了元素1-1、元素1-2之间的关系，也丢失了元素2-1、元素2-2之间的关系。实际上，用户所希望的查询结果是图6中间所示表格，其中元素1-1、元素1-2之间被关联起来，元素2-1、元素2-2之间被关联起来。
因此现有技术的一个技术问题是：如何在用户不知道XML文档的具体模式的情况下，帮助用户在模式可变的XML文档中查询元素，而且返回的查询结果中能够保持元素之间的关系。
发明内容
本发明提出了一种用于具有可变模式的XML文档的XML查询的方法和系统。在优选情况下，本发明的方法和系统能够为给定查询对象自动产生正确的XQuery/XPath查询。
本发明的一方面提供了一种处理对一个或多个XML文档的XML查询的系统，所述XML查询包含XML文档中的一个或多个元素，所述系统包括：树结构产生装置，用于生成所述XML查询包含的元素在所述一个或多个XML文档的每个文档中所属的树结构；查询重写装置，用于基于所述树结构和配置约束规则写出所述一个或多个XML文档中每个文档的XQuery/XPath。
此外，所述树结构产生装置包括：提取装置，用于提取所述一个或多个XML文档中的至少包含上述一个或多个元素的元素之间的嵌套关系；推理装置，基于提取装置提取的元素之间的嵌套关系，推理所述XML查询包含的元素在所述一个或多个XML文档的每个文档中所属的树结构。
此外，当所述一个或多个XML文档基于至少一个XML模式而定义时，所述提取装置从所述至少一个XML模式中的每个XML模式中提取所述元素之间的嵌套关系。
此外，当所述一个或多个XML文档是无模式的XML文档时，所述提取装置从每一个XML文档中提取所述元素之间的嵌套关系。
此外，所述提取装置还从所述一个或多个XML文档中提取元素所属的锚点以及锚点之间的嵌套关系。所述系统还包括约束配置装置，用于配置约束规则，所述约束规则可以是如下至少之一：约束规则1：搜索包含被查询元素的最小树；约束规则2：约束规则1以及被查询的元素所属的锚点被限制为属于同一棵树的锚点；约束规则3：约束规则1以及被查询的元素所属的锚点被限制为同一个锚点；约束规则4：约束规则2以及至少有一个锚点是锚点树的叶节点；约束规则5：约束规则1以及被查询的元素所属锚点被限制为属于同一棵锚点树，且均为叶节点。
此外，所述系统还包括：查询评价装置，根据所述约束配置装置设置的约束规则以及所述提取装置所提取的元素所属的锚点以及锚点之间嵌套关系，来对所述XML查询进行约束。
本发明另一方面提供了一种处理对一个或多个XML文档的XML查询的方法，所述XML查询包含XML文档中的一个或多个元素，所述方法包括步骤：查询接收步骤，用于接收所述XML查询；树结构产生步骤，用于生成所述XML查询包含的元素在所述一个或多个XML文档的每个文档中所属的树结构；以及查询重写步骤，基于所述树结构和配置约束规则写出所述一个或多个XML文档中每个文档的XQuery/XPath。
此外，所述树结构生成步骤还包括：提取步骤，用于提取所述一个或多个XML文档中的至少所述一个或多个元素之间的嵌套关系；推理步骤，基于提取步骤提取的元素之间的嵌套关系，推理所述XML查询包含的元素在所述一个或多个XML文档的每个文档中所属的树结构。
此外，当所述一个或多个XML文档基于至少一个XML模式而定义时，所述提取步骤从所述至少一个XML模式中的每个XML模式中提取所述元素之间的嵌套关系。
此外，当所述一个或多个XML文档是无模式的XML文档时，所述提取步骤从每一个XML文档中提取所述元素之间的嵌套关系。
此外，所述提取步骤还从所述一个或多个XML文档中提取元素所属的锚点以及锚点之间的嵌套关系。所述方法还包括约束配置步骤，用于配置约束规则，所述约束规则可以是如下至少之一：约束规则1：搜索包含被查询元素的最小树；约束规则2：约束规则1以及被查询的元素所属的锚点被限制为属于同一棵树的锚点；约束规则3：约束规则1以及被查询的元素所属的锚点被限制为同一个锚点；约束规则4：约束规则2以及至少有一个锚点是锚点树的叶节点；约束规则5：约束规则1以及被查询的元素所属锚点被限制为属于同一棵锚点树，且均为叶节点。
此外，所述方法还包括：查询评价步骤，根据所述约束配置步骤设置的约束规则以及所述提取步骤所提取的元素所属的锚点以及锚点之间嵌套关系，来对所述XML查询进行约束。
本发明具有下述优点中的至少之一：
(1)为给定的查询对象自动产生XQuery/XPath，其可以是一组已知XML元素/复合元素；
(2)自动产生对锚引用的约束检查；
(3)所返回的XQuery/XPath可直接用于查询，或用于构建路径特定索引。
通过上述方法和系统，返回的查询结果包含了数据的内在关系。此外，极大地为数据使用者减轻负担，数据使用者无需知道多个文档的各自不同的模式。此外，用户可以预先配置约束规则，或者在输入查询的同时选择相应的约束规则，从而提供了更丰富的查询手段。
附图说明
图1显示了基于模型驱动方案(MDA)的XML语言的体系结构。
图2显示了符合图1所示体系结构的XBRL语言的例子。
图3显示了符合图1所示体系结构的CDA语言的例子。
图4-5显示了拥有共享词库的不同的可变模式的例子。
图6显示了采用现有技术对XML文档进行无模式查询的例子。
图7显示了解析一个CDA文档实例而得到的树结构图。
图8显示了解析一个XBRL文档实例而得到的树结构图。
图9显示了解析一个XML模式文件A而得到的树结构图。
图10显示了解析一个XML模式文件B而得到的树结构图。
图11显示了解析基于模式文档A的数据文档1而得到的树结构图。
图12显示了解析基于模式文档B的数据文档2而得到的树结构图。
图13(a)显示了基于模式A从被查询元素倒推得到的树结构图。
图13(b)显示了基于模式B从被查询元素倒推得到的树结构图。
图14显示了根据本发明一个实施例的方法流程图。
图15显示了根据本发明另一个实施例的方法流程图。
图16显示了根据本发明另一个实施例的系统结构图。
图17显示了根据本发明另一个实施例的系统结构图。
现在参照附图描述优选方法和系统，其中，在附图中相同的附图标号用来指相同的部件。在下面的描述中，为了解释的目的，阐述大量特定的细节，以便帮助完全了解系统及方法等。在其它的例子中，为了简化描述，以框图的形式示出常用的结构和装置。对于本领域技术人员来说，可以想到很多修改和其它实施例，同时拥有在说明书和附图中所教导的益处。因此，应该理解，本发明不局限于所公开的特定实施例，另外可选的实施例应当包含在本发明的范围和范例发明构思内。虽然本文采用了一些特定术语，但是仅仅为了一般的描述意义而非限制目的使用它们。
具体实施方式
在解释本发明的技术方案之前，先分别引入一个CDA领域的XML文档和一个XBRL领域的文档，作为后续讨论的基础。
XML实例经常把概念的数值(实例)分成XML子树内的若干段，并通过锚点(Anchor，也可称为属性引用)来链接所述数值的上下文、约束、限定等。为了说明所述子树之间的引用关系，参看图7-8并具体地结合CDA文档和XBRL文档来进行说明。
CDA元模型已经定义了CDA文档中的一些主要元素(属性)为：
header(meta data)
    Patient(病人)
    Document(文档)
    Author(作者)
    Authenticator(认证者)
    Encounter(遭遇)
    ...and more....
body(clinical data)
    Observations(观察)
    Procedures(过程)
    Medications(医疗)
    ...and more...
如下是一个符合CDA语法规范的CDA文档：
<text>
    <caption>Complications</caption>
    <content>
        <content ID＝″a1″>Thrombocytes were taken on the
                           <content ID＝″a2″>second day post-bmt</content>
                           and the count of Thrombocytes was
                           <content ID＝″a3″>not less than 25k</content>
                           during the transplantation
        </content>
        ...    
    </content>
</text>
<Observation>
    <moodCode V＝″EVN″/>
    <originalText><reference url＝″#a1″/></originalText>
<code displayName＝″Thrombocytes″System＝″SNOMED″/>
<value low＝“25”lowClosed＝“true”unit＝“k”>
      <originalText><reference url＝″#a3″/></originalText>
</value>
<effectiveTime value＝“second day post-bmt”>
      <originalText><reference url＝″#a2″/></originalText>
</effectiveTime>
</Observation>
上述文档的<text>...</text>之间的文档部分定义了‘text’包括元素content，以及元素content还包括content a1，content a1还包括contenta2，content a3。
<Observation>...</Observation>之间的文档部分定义了‘observation’，其包括：moodCode，其引用content a1；code，不引用任何content；value，其引用content a3；effective time，其引用content a2。
解析上述文档可以得到相对应的树结构图，如图7所示。图7显示了根节点root下的两棵子树，某一子树内的元素引用(用虚线表示)另一子树的元素。
再结合一个XBRL文档来进行说明。XBRL文档中的一些主要元素为：
context(meta data)
    entity(实体)
    period(时间)
    segment(段)
    scenario(场景)
    unit(单元)
    ...and more....
body(financial data)
    Balance sheet(资产负债表)
    Cash flow statement(现金流声明)
    Income statemet(收入声明)
    ...and more...
基于上述模式和词库，定义如下XBRL文档：
<context contextid＝“context1”>
      <entity>a</entity>
      <period>2005</period>
</context>
<pte:asset contextRef＝“context1”>1000</pte:asset>
<pte:cashnotes>
      <pte:cash contextref＝“context1”>1002</pte:cash>
      <pte:notes contextref＝“context1”>acquire</pte:notes>
</pte:cashnotes>
由上述文档可知，<context>...</context>之间的文档部分定义了context1，其包括entitya和period 2005。
文档部分<pte:asset contextRef＝“context1”>1000</pte:asset>定义了元素asset引用context1。
<pte:cashnotes>...</pte:cashnotes>之间的文档部分定义了cashnote及其子节点cash和notes，它们都引用context1。
解析上述文档可以得到相对应的树结构图，如图8所示。图8显示了根节点root下的两棵子树，某一子树内的元素引用(用虚线表示)另一子树的元素。
以上分别介绍了一个CDA领域的XML文档和一个XBRL领域的文档。对于所述文档而言，常见的查询是：需要将被锚点所链接的两个或更多树之间的元素连接起来。例如，对上述CDA文档的一个查询例子是：{Thrombocyte，second day post-bmt}，即{血小板，骨髓移植后的第二天}。‘Thrombocyte’对应于元素‘code’，‘second day post-bmt’对应于元素‘content a2’，两者位于不同的子树中。
参看图14，本发明提出了一种处理对基于公共语义模型的XML文档的XML查询的方法。图14显示了本发明的一个优选实施例所采用的方法流程1400，包括如下步骤：
步骤1401：处理XML模式，以提取模式中的元素之间的嵌套关系。
步骤1402：处理XML文档实例，提取元素与锚点之间的引用关系以及锚点之间的嵌套关系。如果锚点之间有嵌套关系，则合并锚点。
可替换地，根据本发明的另一方面，对于无模式的文档实例能够从文档实例提取元素之间的嵌套关系。
XML模式和XML文档实例都可以来自XML库1410，XML库1410包括语法定义、概念模型、文档实例等。
步骤1403：配置约束规则
步骤1404：接收查询
步骤1405：根据约束规则来约束查询。具体而言，基于元素与锚点之间的引用关系以及锚点之间的嵌套关系，把约束规则施加到查询。
步骤1406：推理及重写查询。针对输入的被查询元素，利用步骤1401产生的元素之间的嵌套关系，推理得到被查询元素的树结构。然后，利用树结构，把查询重写为XQuery/XPath。
步骤1407：得到各文档的相应XQuery/XPath之后，使用XQuery/XPath处理相应文档，输出期望结果。
以下结合XBRL的一个具体例子来解释本发明的上述处理过程1400。
步骤1401：处理模式，以提取模式的元素之间的嵌套关系
首先，预定义了XBRL的模式A和模式B(schema1.xsd和schema2.xsd)。
schema1：
<element id＝“guarantee”substitutionGroup＝“tuple”>
    <sequence>
        <element ref＝“guaranteeAmount”/>
        <element ref＝“debtor”/>
    </sequence>
</element>
<element id＝“debtor”substitutionGroup＝“tuple”>
    <sequence>
        <element ref＝“debtorName”/>
        <element ref＝“contact”/>
    </sequence>
</element>
<element id＝“contact”substitutionGroup＝“tuple”>
    <sequence>
        <element ref＝“tel”/>
        <element ref＝“email”/>
    </sequence>
</element>
<element id＝“guaranteeAmount”substitutionGroup＝“item”>
<element id＝“debtorName”substitutionGroup＝“item”>
<element id＝“email”substitutionGroup＝“item”>
<element id＝“tel”substitutionGroup＝“item”>
图9显示了从模式A(schema1)解析得到的树结构图。
从上述模式schema1抽取各个元素之间的嵌套关系，则得到如下的表格1。

  模式ID  Element(元素)  Element-Part(元素包含的子元素)  Schema1.xsd  guarantee  guaranteeAmount  Schema1.xsd  guaranteeAmount  Schema1.xsd  guarantee  Debtor  Schema1.xsd  debtor  Contact  Schema1.xsd  debtor  debtorName  Schema1.xsd  debtorName  Schema1.xsd  contact  Tel  Schema1.xsd  tel  Schema1.xsd  contact  Email  Schema1.xsd  email
表格1
表格1的第1栏SchemaID表示了其来源于模式schema1.xsd。第2栏列出schema1.xsd定义的所有元素。第3栏表示各元素的下一级元素。如表格1所示，元素guarantee具有两个子元素：guaranteeAmount和debtor。元素debtor具有两个子元素：contact和debtorName。contact具有两个子元素：tel和email。元素guaranteeAmount，debtorName，tel，email都没有子元素，是叶节点(leaf-node)。表格1实际上是把图9显示的二维树图的表格表示，表格1和图9一一对应。
模式B(schema2.xsd)定义如下：
 <element id＝“offbalance-item”substitutionGroup＝“tuple”>
     <sequence>
         <element ref＝“guaranteeAmount”/>
         <element ref＝“debtorName”/>
         <element ref＝“tel”/>
         <element ref＝“email”/>
     </sequence>
</element>
<element id＝“guaranteeAmount”substitutionGroup＝“item”>
<element id＝“debtorName”substitutionGroup＝“item”>
<element id＝“email”substitutionGroup＝“item”>
<element id＝“tel”substitutionGroup＝“item”>
图10显示了从模式B(schema2.xsd)解析得到的树结构图。
从上述模式B(schema2.xsd)抽取各元素之间的嵌套关系，则得到如下表格2。
  SchemaID  Element(元素)  Element-Part(元素包含的部分)  Schema2.xsd  offbalance-item  guaranteeAmount  Schema2.xsd  offbalance-item  debtorName  Schema2.xsd  offbalance-item  Tel  Schema2.xsd  offbalance-item  Email  Schema2.xsd  guaranteeAmount  Schema2.xsd  debtorName  Schema2.xsd  tel  Schema2.xsd  Email
表格2
表格2的第1栏SchemaID表示了其来源于模式B(schema2.xsd)。第2栏列出schema2.xsd定义的所有元素。第3栏表示各元素的下一级元素。如表格2所示，元素offbalance-item具有4个子元素：guaranteeAmount，debtorName，tel，Email。元素guaranteeAmount，debtorName，tel，emall没有子元素，是叶节点(leaf-node)。表格2实际上是把图10的二维树图的表格表示，表格2和图10一一对应。如本领域技术人员所熟知的，本发明不局限于树结构图或表格，也可以采用其它公知数据结构来表示上述关系。
在本实施例中，步骤1401生成上述表格1和2。
步骤1402：处理XML文档实例中的元素
具体而言，步骤1402可以包括如下操作至少之一：(1)从文档实例产生元素的锚点；(2)提取锚点之间的引用关系；(3)合并锚点。
基于模式A(schema1.xsd)和B(schema2.xsd)的文档实例a(Document1.xml)和b(Document2.xml)被定义为：
Document1.xml
<link:schemaRef xlink:type＝″simple″xlink:href＝“schema1.xsd″/>
<xbrl>
<context id＝“c1”>
          <entity>
                     <identifier>a</identifier>
                     <segmentation>GCG</segmentation>
          <entity>
</context>
<context id＝“c2”>
          <entity><identifier>a</identifier></entity>
</context>
<guarantee>
        <guaranteeAmount contextRef＝“c1”>100</GuaranteeAmount>
        <debtor>
            <debtorName contextRef＝“c1”>iack</debtorName>
            <contact>
                <tel contextRef＝“c1”>82899123</tel>
                <email contextRef＝“c1”>jack@163.com</email>
            </contact>
            <contact>
                <tel contextRef＝“c1”>82899789</tel>
                <email contextRef＝“c1”>jack@sohu.com</email>
            </contact>
        </debtor>
</guarantee>
<guarantee>
        <guaranteeAmount contextRef＝“c2”>200</guaranteeAmount>
        <debtor>
           <debtorName contextRef＝“c2”>tom</debtorName>
           <contact>
               <tel contextRef＝“c2”>82899456</tel>
               <email contextRef＝“c2”>tom@sohu.com</email>
           </contact>
       </debtor>
</guarantee>
</xbrl>
文档Document1.xml的第1行声明其链接到模式A：schema1.xsd。随后定义了两个上下文context c1以及context c2。Context c1具有子元素entity，entity具有子元素Identifier a以及segmenatation GCG。Context c2具有子元素entity，entity具有子元素Identifier a。文档Document1.xml还定义了2个guarantee，分别涉及jack和tom。
图11的上方显示了解析文档Document1.xml得到的两个上下文context 1，context c2，图11的下方显示了两个guarantee的树结构，图11还显示了树之间的元素嵌套(元素引用)关系。图11左侧的子树guarantee的所有元素都引用一个锚点，context c1，图11右侧的子树guarantee的所有元素引用另一锚点，context c2。
从图11的树结构可以得到每一个元素与其锚点(即，上下文contextc1、context c2)之间的关系，还可得到各个锚点(上下文context c1、contextc2)之间的嵌套关系(如果存在的话)。
根据Document1.xml关于context c1和context c2的定义，contextc2的树结构包含context c1的树结构，可以将context c1视为context c2的子节点。表格3显示了上下文c2和c1之间的关系。
  文档ID  Anchor(锚点)  Anchor-Part(锚点的部分)  Document1.xml  c2  c1
表格3
可以对context c1和context c2进行合并(consolidation)处理。作为示例的而非限制的，可以通过如下操作来进行锚点的合并处理：
Input c1，c2
      -if c1.identifier＝c2.identifier then
               If(c1.segmentation＝c2.segmentation)
                      -Then output(c1equals c2)return
               If(c1.segmentation！＝null)and(c2.sementation＝＝null)
                      -Then output(c1is part of c2)return
               If(c1.segmentation＝＝null)and(c2.segmentation！＝null)
                      -Then output(c2is part of c1)return
上述操作中，首先对c1和c2的identifier(标识符)进行比较，如果两者的identifier相同，则比较segmentation(分区)。如果segmentation也相同，则c1与c2是等价关系。如果某个的segmentation为Null(空)，另一个的segmentation不为Null，则两者是嵌套关系。
表格4显示了每个元素所引用的锚点。
  文档ID    Element(元素)    Element-Anchor(元素的锚点)  Document1.xml    tel    c1，c2  Document1.xml    email    c1，c2  Document1.xml    debtorName    c1，c2  Document1.xml    guarranteeAmount    c1，c2
表格4
Guarantee包括tel，email，debtorName和guaranteeAmount。由图11可知，这些元素在一个实例中引用context c1，在另一个实例中引用context c2，因此每个元素都引用c1和c2。
以下给出基于模式B(schema2.xsd)的文档实例b(document2.xml)。
Document2.xml
<link:schemaRef xlink:type＝″simple″xlink:href＝“schema2.xsd″/>
<xbrl>
<context id＝“c1”>
       <entity>
               <identifier>a</identifier>
               <segmentation>GCG</segmentation>
       <entity>
</context>
<context id＝“c2”>
       <entity><identifier>a</identifier></entity>
</context>
<offbalance-item>
        <guaranteeAmount contextRef＝“c1”>700</GuarranteeAmount>
        <debtorName contextRef＝“c1”>john</debtorName>
        <tel contextRef＝“c1”>55588123</tel>
        <email contextRef＝“c1”>john@163.com</email>
</offbalance-item>
<offbalance-item>
        <guarranteeAmount contextRef＝“c2”>600</guarranteeAmount>
        <debtorName contextRef＝“c2”>marry</debtorName>
        <tel contextRef＝“c1”>55588456</tel>
        <email contextRef＝“c1”>marry@sohu.com</email>
</offbalance-item>
</xbrl>
文档Document2.xml的第1行声明其链接到模式B：schema2.xsd。
然后定义了两个上下文context c1以及context c2。Context c1具有entity，entity具有Identifiera以及segmenatation GCG。Context c2具有entity，entity具有Identifiera。随后文档Document2.xml定义了offbalance-item的2个实例，分别涉及john和marry。
图12显示了解析文档实例Document2.xml得到的两个上下文context c1，context c2以及两个guarantee的树结构，还显示了树之间的关系。图12左侧的一个offbalance-item的所有元素都引用一个锚点，context c1；图12右侧的另一个offbalance-item的一部分元素引用锚点context c1，另一部分元素引用锚点context c2。
从图12的树结构可以得到每个元素与其锚点之间的关系，还可以得到各个锚点之间的嵌套关系(如果存在的话)。
根据Document2.xml对context c1和context c2的定义，context c2的树结构包含context c1的树结构，可以将context c1视为context c2的子节点。表格5显示了上下文c2和c1之间的关系。
  文档ID  Anchor(锚点)  Anchor-Part(锚点的部分)  Document2.xml  c2  c1
表格5
上述处理实际上是对context c1和context c2的合并(consolidation)处理。
表格6显示了offbalance-item中每个元素所引用的锚点。
  文档ID  Element(元素)  Element-Anchor(元素的锚点)  Document2.xml  tel  c1  Document2.xml  email  c1  Document2.xml  debtorName  c1，c2  Document2.xml  guaranteeAmount  c1，c2
表格6
Offbalance-item包括tel，email，debtorName和guaranteeAmount。由图12可知，元素tel，email在每个实例中都引用context c1；而元素debtorName和guaranteeAmount在一个实例(图12左侧的)中引用context c1，在另一个实例(图12右侧的)中引用context c2，因此元素debtorName和guaranteeAmount引用c1和c2。
以上Document1.xml和Document2.xml是基于模式A和B(schema1.xsd和schema2.xsd)。但是对于无模式文档，则可以从文档实例直接产生元素之间的关系。换句话说，可以直接解析文档Document1.xml和Document2.xml，也能够得到如表格1和表格2所示的元素之间的嵌套关系。
上述步骤1402提取各元素的锚点(如表格4和6)以及锚点之间的关系(如表格3和5)。
步骤1403：配置约束规则
根据本发明的一方面，用户可以预定义的查询约束包括如下几种。
假设输入的查询对象是X，Y。
-约束规则1：搜索XML树中包含X，Y...的最小树。
实际上约束规则1并没有对X，Y所引用的锚点施加任何约束。
-约束规则2：约束规则1；以及X，Y...所属的锚点被限制为CDA中属于同一棵树的锚点。
参看图11，上下文c1和c2之间具有父-子关系，因此属于同一棵树。因此，能够在图11所示的全部树结构中进行搜索。同样，参看图12，上下文c1和c2之间具有父-子关系，因此属于同一棵树。因此能够在图12所示的全部树结构中进行搜索。为了确定X，Y...所属的上下文是否属于同一棵树，可进行如下判断：
·X is a CDA element
·Y is a CDA element
·X and Y have same ancestor
·M is a CDA anchor
·N is a CDA anchor
·M and N have same ancestor
·X refer To M
·Y refer To N
-约束规则3：约束规则1；以及X，Y...所属的锚点被限制为XBRL中的同一个锚点。
如果采用约束3，则文档实例b中定义的第2个Offbalance-item可能被该约束所过滤。因为第2个Offbalance-item中的元素tel，email引用context c1，而元素debtorName，guaranteeAmount引用context c2，context c1和context c2不是同一个上下文。假设X是tel，Y是debtorName，则X引用context c1，Y引用context c2。X，Y所属的上下文不是同一个上下文。因此，约束规则3能够过滤对第2个Offbalance-item的搜索。
此外，本领域技术人员能够理解，可以根据用户需要来定义其它类型的约束规则，并对其进行任意组合。例如，约束配置的其他例子还包括：
约束规则4：约束规则2以及c1，c2中至少有一个锚点是锚点树的叶节点。
约束规则5：约束规则1以及X，Y所属锚点被限制为属于同一棵锚点树，且均为叶节点。
基于上述预定义的约束规则，可以对用户的查询输入进行评价。
步骤1404：接收查询
在本实施例中，所接收的查询为对XBRL文档的一个查询例：{guaranteeAmount，debtorName，tel}。即同时查询三个元素。以下描述如何评价及约束查询{guaranteeAmount，debtorName，tel}。
根据本发明的一个优选实施例，可以基于步骤1403定义的约束规则对查询进行评价。
显而易见的，本发明的替换实施例也可以不施加任何约束规则。本领域的技术人员能够理解如何实施，例如跳过步骤1403以及后续步骤1405。
步骤1405：评价及约束查询
步骤1405基于预定义的约束规则来评价查询，约束规则可以由用户配置。步骤1405是可选择的，旨在规范查询的语义约束。由于缺乏统一模式，查询所面对的文档可能基于很多不同的模式甚至是五花八门的，而用户可能只需要满足特定条件的文档，为了向用户提供进一步选择而执行该约束步骤。
首先，基于文档实例a和b(document1.xml和document2.xml)，获得查询对象(X，Y)所引用的锚点。
参见图11，文档实例a定义了两个子树，一个子树完全引用contextc1，另一个子树完全引用context c2。每个子树都包括元素guaranteeAmount，debtorName，tel.在文档实例a中，所查询的元素guaranteeAmount，debtorName，tel既引用context c1也引用context c2，它们与context c1和context c2之间的引用关系表示为：
a_1：(guaranteeAmount，c1)，(debtorName，c1)，(tel，c1)
a_2：(guaranteeAmount，c2)，(debtorName，c2)，(tel，c2)
由此得到guaranteeAmount，debtorName，tel所引用的上下文为c1，c2。可以表示为：
a：(guaranteeAmount，c1，c2)，(debtorName，c1，c2)，(tel，c1，c2)
参见图12，文档实例b定义了两个子树，一个子树完全引用contextc1，另一个子树既引用context c1也引用context c2。所查询的元素guaranteeAmount，debtorName，tel在一个子树中引用context c1，在另一个子树中既引用context c1也引用context c2。元素guaranteeAmount，debtorName，tel与context c1和context c2之间的引用关系表示为：
b_1：(guaranteeAmount，c1)，(debtorName，c1)，(tel，c1)
b_2：(guaranteeAmount，c2)，(debtorName，c2)，(tel，c1)
由此得到guaranteeAmount，debtorName，tel引用的上下文为c1，c2。可以表示为：
b：(guaranteeAmount c1，c2)，(debtorName，c1，c2)，(tel，c1)
然后，根据步骤1403所配置的约束规则对查询进行约束。
根据本发明的一方面，采用步骤1403配置的约束规则2，即元素guaranteeAmount，debtorName，tel所属的上下文被限制为CDA中的属于同一棵树的上下文。由于文档实例a和b(document1.xml和document2.xml)中的context c1和context c2都属于同一棵树(参见表格3和5)，元素guaranteeAmount，debtorName，tel所属的上下文contextc1和context c2属于同一棵树。因此，没有任何上下文被约束规则2所过滤。
对文档实例a施加约束规则2，得到：
a：(guaranteeAmount，c1，c2)，(debtorName，c1，c2)，(tel，c1，c2)
对文档实例b施加约束规则2，得到：
b：(guaranteeAmount c1，c2)，(debtorName，c1，c2)，(tel，c1)
可见，对文档实例a施加约束规则2时，与未施加约束规则2的结果相同。
根据本发明的另一方面，采用约束规则3，即元素guaranteeAmount，debtorName，tel所属的上下文被限制为XBRL中的同一个上下文。这样，由于文档实例b中定义的第2个Offbalance-item中的元素tel引用contextc1，元素debtorName，guaranteeAmount引用context c2，context c1和context c2不是同一个上下文。所以第2个Offbalance-item的搜索被约束规则3所过滤，如下所示：
对文档实例a施加约束规则3，得到
a：(guaranteeAmount，c1，c2)，(debtorName，c1，c2)，(tel，c1，c2)
对上述文档实例b施加约束规则3，得到
b：(guaranteeAmount，c1)，(debtorName，c1)，(tel，c1)
可见，施加约束规则3时，文档b所引用的上下文被限制为c1。
如上所述，步骤1405所得到的结果为：
施加约束规则2所产生的锚点约束为空，如下所示：
a：(guaranteeAmount ())，(debtorName，())，(tel，())
b：(guaranteeAmount ())，(debtorName，())，(tel，())
施加约束规则3所产生的锚点约束不为空，如下所示：
a：(guaranteeAmount ())，(debtorName，())，(tel，())
b：(guaranteeAmount c1)，(debtorName，())，(tel ())
步骤1406：推理及重写查询
首先，基于关系库1420对查询元素进行推理，以产生相应的树结构。基于预先基于模式1和模式2生成的表格1和2，从底部向顶部推理被查询元素guaranteeAmount，debtorName，tel之间的关系，还原元素guaranteeAmount，debtorName，tel之间的树结构，如图13所示。
对于模式A，检索表格1可知guarantee是根节点。对元素guaranteeAmount，检索表格1可知其父节点是根节点guarantee。对于元素debtorName，其父节点是debtor，debtor的父节点是根节点guarantee。对于元素tel，其父节点是contact，contact的父节点是debtor，debtor的父节点是根节点guarantee。由此推理得到图13(a)所示的树结构。不查询元素没有被显示，例如节点email。图13(a)所示的树结构中，所有叶节点都是用户的查询对象。
图13(a)的树结构还可以表示为：
a：(guarantee，(guaranteeAmount()，debtor(debtorName()，contact(tel()))))
对于模式B，检索表格2可知offbalance-item是根节点。对元素guaranteeAmount，通过检索表格2可知其父节点是根节点offbalance-item。对于元素debtorName，其父节点是根节点offbalance-item。对于元素tel，其父节点是根节点offbalance-item。由此推理得到图13(b)所示的树结构。图13(b)所示的树结构中，所有叶节点都是用户的查询对象。
图13(b)的树结构还可以表示为：
b：(guarantee，(guaratneeAmount()，debtorName()，tel()))
然后，基于推理得到被查询元素guaratneeAmount，debtorName，tel之间的树结构，重写查询。应当注意，如图13(a)和13(b)所示，树结构的全部叶节点就是所查询的元素guaratneeAmount，debtorName，tel。
应当注意，图14给出了利用步骤1401(处理XML模式以提取模式中的元素之间的嵌套关系)和步骤1402(处理XML文档实例中的元素)，来提取被查询元素的树结构的方式。但是这仅是示范性的、而非限制性的。本领域技术人员可以基于本说明书的教导采用其它方式来提取上述树结构关系。例如，使用Simple API for XML(SAX，XML简单编程接口)，Extensible Stylesheet Language Transformations(XSLT，可扩展样式单语言转换)，Document Object Model(DOM，文档对象模型)等现有的XML文档解析工具包、库来从XML文档中通过提取树根节点，然后逐一提取树的子结点来逐步提取树结构，这些具体提取方法是XML软件开发人员所熟知的。
因此，本领域的技术人员基于本说明书的教导还可以把图14的方法流程进行各种变化，例如实施为：
查询接收步骤，用于接收所述XML查询；
树结构产生步骤，用于生成所述XML查询包含的元素在所述一个或多个XML文档的每个文档中所属的树结构；以及
查询重写步骤，基于所述树结构和配置约束规则写出所述一个或多个XML文档中每个文档的XQuery/XPath。
以下解释如何对用户输入的查询{guaratneeAmount，debtorName，tel}进行重写。根据本发明的一个实施例，重写过程把用户查询{guaratneeAmount，debtorName，tel}转换为对图13(a)和13(b)的所有叶节点的输出。本发明的优选实施方式使用递归方法来进行重写过程，下面的例子采用了宽度优先搜索。但是本领域的技术人员应当理解，完全可以采用本领域的其它算法/方式来实现相同的目的，即采用其它遍历树结构的算法。所述重写过程包括如下步骤：
1.0)初始化一个金局叶节点列表，以及以根结点作为输入而调用重写过程。
2.0)重写过程：
2.1)如果输入节点是根结点，输出XQuery以定位该节点
2.2)测试输入节点的所有子节点
2.2.1)初始化一个本地的容器节点(非叶节点)列表
2.2.2)如果子节点是叶节点，输出XQuery以定义变量，把它与约束相关联，以及把该变量添加到全局叶节点列表中
2.2.3)如果子节点是容器节点，输出XQuery以定位该节点；把该变量添加到容器节点列表
2.3)如果容器列表是空，输出XQuery以根据全局叶节点列表选择所有变量
2.4)否则，为容器列表中的每个节点x，以节点x作为输入调用重写过程。
对应于上述重写过程的代码语言部分可以表示为：
Rewrite query(top-down based on notes tree)
 -0.Initiate a global leaf nodes list，call rewrite process with root node as input
 -1.rewrite process(breadth first search)
     ·1.1 If input node is root node，1 output XQuery headers，2 output XQuery
       to locate to the node
     ·1.2 Initiate a local container nodes list
     ·1.3 Test all child nodes of the input node
          -1.3.1 if a child is a leaf node，1 output a XQuery to define a
                 variable capture it’s value with anchor constraint，2 add the variable
                 into leaf nodes list
          -1.3.2 If a child is a container node，1 output a XQuery foreach
                 statement to locate to the node，2 add the nodes into container list
     ·1.4 If container list is null，1 output XQuery to select all variables according
           to leaf nodes list
Else for x each node in container list，call rewrite process with node x as input
     ·1.5 If input node is root node，output XQuery footers
通过上述重写过程，把用户输入的查询{guaratneeAmount，debtorName，tel}转换输出为相应的XQuery/XPath。
应用约束规则2时产生的锚点约束为空，即：
a：(guaranteeAmount ())，(debtorName，())，(tel，())
b：(guaranteeAmount ())，(debtorName，())，(tel，())。
重写查询后输出的XQuery/XPath为：
For documentl.xml
<xsl:stylesheet version＝′1.0′xmlns:xsl＝′http://www.w3.org/1999/XSL/Transform′>
<xsl:template match＝″/″>
<xsl:for-each select＝″\xbrl\guarantee″>
<xsl:variable name＝″gamount″><xsl:value-of select＝″guaranteeAmount″/></xsl:variable>
  <xsl:for-each select＝″debtor″>
    <xsl:variable name＝″dname″><xsl:value-of select＝″debtorName″/></xsl:variable>
      <xsl:for-each select＝″contact″>
           <guaranteeAmount><xsl:value-of select＝″$gamount″/></guaranteeAmount>
           <debtorName><xsl:value-of select＝″$dname″/></debtorName>
           <tel><xsl:value-of select＝″tel″></tel>
      </xsl:for-each>
    </xsl:for-each>
</xsl:for-each>
</xsl:template></xsl:stylesheet>
For docment2.xml
<xsl:stylesheet version＝′1.0′xmlns:xsl＝′http://www.w3.org/1999/XSL/Transform′>
<xsl:template match＝″/″>
<xsl:for-each select＝″\xbrl\offbalance-item″>
    <guaranteeAmount><xsl:value-of select＝″guaranteeAmount″/></guaranteeAmount>
    <debtorName><xsl:value-of select＝″debtorName“/></debtorName>
    <tel><xsl:value-of select＝″tel″/><tel>
</xsl:for-each>
</xsl:template></xsl:stylesheet>
应用上述约束规则3时，对于文档实例b所产生的锚点约束不为空，即：
a：(guaranteeAmount ())，(debtorName，())，(tel，())
b：(guaranteeAmount c1)，(debtorName，())，(tel ())
因此，对于文档实例b，重写查询后输出的XQuery/XPath体现了上述约束规则3，如下所示：
For docment2.xml
<xsl:stylesheet version＝′1.0′xmlns:xsl＝′http://www.w3.org/1999/XSL/Transform′>
<xsl:template match＝″/″>
<xsl:for-each select＝″\xbrl\offbalance-item″>
     <guaranteeAmount><xsl:value-of select＝″guaranteeAmount”where contextRef＝
      “context1”/></guaranteeAmount>
     <debtorName><xsl:value-of select＝″debtorName“/></debtorName>
     <tel><xsl:value-of select＝″tel″/><tel>
</xsl:for-each>
</xsl:template></xsl:stylesheet>
在步骤1407，使用步骤1406产生的XQuery/XPath对文档实例a和b进行查询，得到所期望的查询结果。
应用约束规则2时，得到的查询结果为：
Document1.xml
100 jack  82899123
100 jack  82899789
200 tom   82899456
Document2.xml
700 john  55588123
600 marry 55588456
应用约束规则3时，得到的查询结果为：
Document1.xml
100 jack  82899123
100 jack  82899789
200 tom  82899456
Document2.xml
700 john  55588123
由于约束规则3限制被查询元素{guaratneeAmount，debtorName，tel}所引用的锚点必须是相同锚点，因此过滤了文档实例2中涉及marry的数据。
显然，查询结果的每一行输出都属于同一个子树，体现了被查询元素{guaratneeAmount，debtorName，tel}之间的内在关联。
另一方面，如果基于现有技术的通配符查询文档实例a和b(Document1.xml和Document2.xml)，则所输出的结果为：
Document1.xml
100    jack 82899123
100    jack 82899456
100    jack 82899789
200    jack 82899123
200    jack 82899456
200    jack 82899789
100    tom  82899123
100    tom  82899456
100    tom  82899789
200    tom  82899123
200    tom  82899456
200    tom  82899789
Document2.xml
700    john  55588123
700    john  55588456
600    john  55588123
600    john  55588456
700    marry 55588123
700    marry 55588456
600    marry 55588123
600    marry 55588456
显然，上述结果丢失了各个元素之间的内在关系，并不是用户所期望的。
以上结合XBRL作为例子说明了本发明的方法流程，如图14所示。其中包括如下具体步骤：
1401：处理XML模式A和B，以提取模式A和B中的元素之间的嵌套关系(例如，表格1-2)。
1402：处理XML文档实例a和b，提取元素与其锚点之间的引用关系(例如，表格4、6)以及锚点之间的嵌套关系(例如，表格3、5)。此外，因为锚点c1和c2之间有嵌套关系，则可以合并锚点c1和c2。
步骤1401以及1402所提取的关系被存储在关系库1420中。
1403：配置约束规则1、约束规则2、约束规则3。
上述步骤1401-1403也可以作为预处理步骤而执行，并把相关的信息预先存储，例如存储在关系库1420或其它数据库中。这样，本发明的方法流程可以直接接收用户输入，即从下述步骤1404开始。
1404：接收查询{guaratneeAmount，debtorName，tel}。
1405：评价查询。具体而言，基于元素{guaratneeAmount，debtorName，tel}与锚点c1、c2之间的引用关系(例如，表格4、6)以及锚点c1、c2之间的嵌套关系(例如表格3、5)，把约束规则施加到查询。
1406：推理及重写查询。针对输入的被查询元素{guaratneeAmount，debtorName，tel}，利用步骤1401产生的元素之间的嵌套关系(表格1-2)，推理得到被查询元素在模式A和B中的树结构(如图13a和13b所示)。然后，利用树结构，把查询重写为文档a和b的XQuery/XPath。
在得到用于文档a和b的XQuery/XPath之后，使用XQuery/XPath处理文档a和b，输出期望结果。
上述处理过程中，文档a和b是基于模式A和B。然而，本发明还可以处理无模式文档。仍然以文档实例a和b为例，不提供模式A和B的情况下，对文档实例a和b的查询进行处理包括如下步骤：
1401步骤被省略；
1402：处理XML文档实例a和b，提取元素之间的嵌套关系(例如表格1-2)、元素引用的锚点(例如，表格4、6)以及锚点之间的嵌套关系(例如，表格3、5)。1402所提取的关系被存储在关系库1420中。
1403：配置约束规则1、2、3。
1404：接收查询{guaratneeAmount，debtorName，tel}。
1405：评价查询。具体而言，基于元素{guaratneeAmount，debtorName，tel}与锚点c1、c2之间的引用关系(例如，表格4、6)以及锚点c1、c2之间的嵌套关系(例如表格3、5)，把约束规则施加到查询。
1406：推理及重写查询。具体而言，针对输入的被查询元素，利用步骤1402产生的元素之间的嵌套关系(表格1-2)，推理得到被查询元素的树结构。然后，利用树结构把查询重写为文档a和b的XQuery/XPath。
步骤1407：在得到用于文档a和b的XQuery/XPath之后，使用XQuery/XPath处理文档a和b，输出期望结果。至于使用XQuery/XPath处理文档a和b的细节是现有技术已知的，可以采用现有的XML查询技术来实现，因此本文不再进一步讨论其细节。
此外，根据本发明的一个优选实施例，图14的步骤1403也可以与步骤1404/1405同步进行，从而为用户提供对约束规则的随时配置，用户能够在输入查询的同时输入/选择约束规则。
图15显示了根据本发明另一实施例提出方法流程图。与图14的处理步骤不同，图15的处理步骤中省略了评价查询以及对查询施加约束规则的步骤。具体而言，图15的方法包括如下步骤(对相似处理步骤的描述被省略)：
1501：处理XML模式，提取模式中的元素之间的嵌套关系(表格1-2)。
1502：处理XML文档实例a和b，提取元素与锚点之间的引用关系(例如，表格4、6)以及锚点之间的嵌套关系(例如，表格3、5)。此外，因为锚点c1和c2之间有嵌套关系，则可以合并锚点c1和c2。
XML模式和XML文档实例都可以来自XML库1510，XML库1510包括语法定义、概念模型、文档实例等。
1503：接收查询{guaratneeAmount，debtorName，tel}。
1504：推理及重写查询。具体而言，基于输入的查询，利用步骤1501产生的元素之间的嵌套关系(表格1-2)，推理被查询元素的树结构。利用树结构，把查询重写为XQuery/XPath。使用XQuery/XPath处理文档，输出期望结果。
以上介绍的实施例中，发明是基于具有两个模式(A、B)的两个文档实例(a、b)，其中文档a符合模式A，文档b符合模式B。但是显而易见的，本发明不限于此。本发明完全可以应用在具有一个或多个模式(A、B...)的一组XML文档实例(a、b...)，其中可以有任意数量的文档实例对应于任一个模式。
图16显示了根据本发明一个实施例所提出的处理XML查询的系统1600。系统1600的输入为：XML库1610，包括语法定义、概念模型、文档实例等；查询输入1640。系统1600的输出为XQuery/XPath 1650，其能用于回答查询或建立路径特定索引；以及关系库1620，其中包括所提取的元素、子树、子图形等。
根据本发明的一个优选实施例，系统1600包括：
模式提取装置1601，用于处理模式(如模式A、B、C...)以提取模式中元素之间的嵌套关系，元素嵌套关系可以表示为树结构图，也可以用一维表格(例如表格1-2)来表示；
文档提取装置1602，用于处理文档实例(例如文档a、b...)以提取文档中元素的锚点以及锚点之间的嵌套关系。元素及其锚点之间的关系可以表示为多个树结构图之间的关联，也可以用一维表格(例如表格3-6)。
根据本发明的优选实施例，模式提取装置1601和文档提取装置1602可以预先生成上述信息(表格1-6)并将其保存在关系库1620中，以供后续操作使用。
此外，在图16所述的系统中，模式提取装置1601和文档提取装置1602是分离的装置模块。但是可替换地，模式提取装置1601和文档提取装置1602也可以被集成为单个装置，即由一个装置来处理模式及文档以提取所需信息。
约束配置装置1630，用于配置约束规则。作为示例而非限制，约束规则可以是如下至少之一：
-约束规则1：搜索XML树中包含X，Y...的最小树。实际上约束规则1并没有对X，Y...所引用的上下文施加任何约束。
-约束规则2：约束规则1；以及X，Y...所属的上下文被限制为CDA中属于同一棵树的上下文。
-约束规则3：约束规则1；以及X，Y...所属的上下文被限制为XBRL中的同一个上下文。
此外，本领域技术人员能够理解，可以根据用户需要来定义其它类型的约束规则，并对其进行任意组合。
查询评价装置1603，用于对用户输入的查询{X，Y，...}进行评价，以及基于约束配置装置1630配置的约束规则来对查询进行约束；
查询重写装置1604，首先基于模式提取装置1601提取的元素之间的嵌套关系，推理出不同模式A、B、...中的被查询元素{X，Y，...}之间的树结构，然后基于查询评价装置1603生成的约束，对用户输入的查询{X，Y，...}进行重写，以得到元素在不同模式A、B、...中的XQuery/XPath。
将得到的XQuery/XPath运行在文档实例a、b...上，可得到期望的查询结果。至于使用XQuery/XPath处理文档a和b的细节是现有技术已知的，可以采用现有的XML查询技术来实现，因此本文不再进一步讨论其细节。
此外，应当注意，以上给出利用模式提取装置1601和文档提取装置1602等来提取数据关系，从而推理被查询元素的树结构。但是，上述示例仅是示范性的、而非限制性的。本领域技术人员可以基于本说明书的教导而采用其它方式来提取上述树结构关系。例如，使用Simple API forXML(SAX，XML简单编程接口)，Extensible Stylesheet LanguageTransformations(XSLT，可扩展样式单语言转换)，Document ObjectModel(DOM，文档对象模型)等现有的XML文档解析工具包、库来从XML文档中通过提取树根节点，然后逐一提取树的子结点来逐步提取树结构，这些具体提取方法是XML软件开发人员所熟知的。
因此，本领域的技术人员基于本说明书的教导还可以对图16的系统实施各种变化，例如图17显示了根据本发明另一个实施例的系统框图，其中进一步给出了如何实施本发明的各种变体的教导。图17的系统1700与图16的系统1600相同的部分不再赘述。
所述系统1700包含树结构产生装置1701，用于生成XML查询包含的元素在所述一个或多个XML文档的每个文档中所属的树结构。如本领域技术人员所能理解的，可以基于各种技术来提取所述树结构关系。
例如，采用诸如SAX、XSLT、DOM等现有XML文档解析工具，所述树结构产生装置可以进一步包括关系提取装置，用于提取所述一个或多个XML文档中的各元素之间的关系；以及推理装置，基于提取装置提取的各元素之间的关系，推理所述XML查询包含的元素在各个文档中所属的树结构。
所述系统1700还包括查询重写装置1704，用于基于所述树结构和配置约束规则写出所述一个或多个XML文档中每个文档的XQuery/XPath。所述配置约束规则可以由诸如约束配置装置1730提供。
上述系统1600以及1700返回的查询结果包含了数据的内在关系。尤其是，数据使用者在查询时无需知道多个文档的各自不同的模式，系统执行的操作对于用户是透明的，因此减轻了使用者的负担。此外，数据使用者可以预先配置约束规则，或者在输入查询时选择相应的约束规则，从而提供了更丰富的查询手段。
应该认识到，本文所用的“关系库”是指可以存储数据的物理实体和/或逻辑实体、例如，关系库可以是下述中的一个或者多个：列表、表格、文件、数据存储、关系数据库、数据表格、队列、堆阵等。数据库可以驻留在一个逻辑和/或物理实体中，并且/或者可以分布在两个或者更多个逻辑和/或物理实体之间。术语数据库可以理解包括数据库管理系统，用于控制容纳在数据库中的数据的组织、存储和检索。
应该认识到，本文所述的“元素”应当作广义的而非限制性的解释，例如包括XML相关标准定义的“element”、“attribute”等(在XML领域，element和attribute实际上是可以互换定义的)，只要不妨碍本方面的实施即可。
应该认识到，本文所述的“嵌套关系”、“引用关系”也应当作广义的而非限制性的解释，例如包括树结构的元素之间的从属、引用、关联等关系。
应该认识到，尽管上述实施例中结合CDA和XBRL领域来进行说明，但是本发明不仅限于上述领域。任何基于可变XML模式的XML文档都可以应用本发明。
应该认识到，系统的过程和方法中的一些或者全部涉及电子和/或软件应用，所述应用可以是动态的、灵活的过程，从而，它们可以以与本文所述的那些不同的其它顺序执行、或者省略某些步骤而简化执行。例如，图14的步骤1401-1402是在步骤1403之前进行，作为处理查询之前的预处理过程；但是可替换地，步骤1401-1402也可以在步骤1403之后进行，即在接收查询之后进行处理；可替换地，步骤1401和1402也可以交换顺序。此外，图14的步骤1403可以与步骤1404/1405同步进行，从而为用户提供对约束规则的即时配置。在某些情况下，步骤1403、1405甚至可以被省略。
本领域的技术人员也应该认识认识到，使用诸如机器语言、程序的、面向对象的和/或人工智能技术之类的各种编程方法，可以实施体现为软件的元件。
尽管是参考典型的具体实施方式对本发明进行的描述，但应该理解本发明并不限于所披露的典型具体实施方式。下述权利要求的范围符合最宽泛的解释，以至于包括所有修改、等价结构和功能。