CN101971176A - 用于建立可扩展业务应用的类型系统 - Google Patents

Abstract

用于开发可扩展业务应用的平台(在此处被称为可扩展应用平台或XAP)。在一组实施例中，XAP可包括基于可扩展标记语言(XML)的应用模型，该模型被设计为支持高度的应用扩展性。例如，XAP应用模型可支持应用语义的声明性定义、应用数据和元数据的分离、以及允许数据对象实例(例如，XML文档)的约束和计算(例如，XQuery约束和计算)随时间改变的灵活的类型系统。在某些实施例中，可经由被配置成与类似电子表格的客户机侧用户接口互操作的服务器侧的数据库/应用引擎来实现该XAP应用模型。使用类似电子表格的UI，非编程人员可如传统业务应用一样建立、定制并运行在共享的数据库上工作的应用工作流。

Description

用于建立可扩展业务应用的类型系统

相关申请的交叉引用

本申请根据美国法典第35法案第119(e)款要求于2009年5月20日提交的、题为“EXTENSIBLE APPLICATION PLATFORM”(代理人卷号No.021756-086901US)的美国临时专利申请No.61/180,079的权益和优先权，在此为了所有的目的通过引用将该申请的全部内容并入本申请。

技术领域

本发明一般地涉及计算机软件，更具体地说，涉及用于建立可扩展业务应用的平台。

背景技术

现今的许多企业具有用于管理电子信息的两个共生系统(ecosystem)：数据库共生系统，其中通过使用专用的、通常复杂的软件应用(此处被称作传统业务应用)，信息被捕获并保存在共享数据库中；以及电子表格(spreadsheet)共生系统，其中信息使用电子表格在个体之间交换，通常以ad-hoc方式。

数据库共生系统特别适合于共享的企业环境，因为信息被集中存储，因此可由多个用户访问以用于查看、修改、分析、审核、报告和其它功能。此外，用作数据条目的前端的传统业务应用通常被设计为支持业务背景中有用的特征(例如，安全性、工作流等)。然而，该共生系统的显著缺点是，传统业务应用通常不能由非编程人员(例如，终端用户)建立或定制。其结果是，这样的用户被约束于输入和管理这些应用最初被编程为支持的特定种类的数据。

在电子表格共生系统中，用户具有输入和保持跟踪适合于他们的特定需要的任何类型数据的灵活性。例如，利用诸如微软Excel的传统电子表格应用，用户可容易地输入、修改和重新安排任何单元或由单元构成的组中的数据。此外，因为电子表格本质上是以数据为中心，而不是以代码为中心的，所以没有任何编程专长的用户也可建立和定制电子表格来执行各种任务。这使得电子表格对于广大用户而言是有吸引力并且易掌握的数据管理工具。然而，电子表格不支持从共享数据库存储/检索数据或其它面向业务的特征，从而约束了它们在多用户企业设置中的有用性。

因此，希望具有用于建立新种类的应用的技术，能结合电子表格和传统的数据库驱动的业务应用这两方面。

发明内容

本发明的实施例提供了一种用于开发可扩展业务应用的平台(此处被称为可扩展应用平台，Extensible Application Platform，或XAP)。在一组实施例中，XAP可包括基于可扩展标记语言(XML)的应用模型，该模型被设计为支持高度的应用可扩展性。例如，XAP应用模型可支持应用语义的声明式定义、应用数据和元数据的分离、以及允许数据对象实例(例如，XML文档)的约束和计算(例如，XQuery约束和计算)随时间改变的灵活的类型系统。在某些实施例中，可经由被配置成与类似电子表格的客户机侧用户界面互操作的服务器侧的数据库/应用引擎来实现XAP应用模型。使用类似电子表格的UI，非编程人员可建立、定制并运行在如传统业务应用的共享数据库上工作的应用工作流。

根据本发明的一个实施例，提供了一种用于验证数据对象实例，诸如XML文档实例的方法。该方法包括由计算机系统存储XML文档的一组XQuery状态，并由计算机系统在第一时间点确定该组XQuery状态的第一子集。然后，在该第一时间点关于该第一子集来验证XML文档的实例，而无需关于不在第一子集中的XQuery状态验证该实例。

在一个实施例中，该方法进一步包括在第二时间点确定该组XQuery状态的第二子集，其中所述第二子集与第一子集不同。然后在第二时间点关于该第二子集验证该实例，而无需关于不在第二子集中的XQuery状态验证该实例。

在一个实施例中，该方法进一步包括存储XML文档的类型，并自动地在第一时间点和第二时间点两个时间点关于该类型验证该实例。

在一个实施例中，该组XQuery状态中的每个状态被存储为单独的XML文档。

在一个实施例中，该组状态中的每个XQuery状态限定一组XQuery约束，并且关于第一子集验证该实例包括：关于由第一子集限定的多组XQuery约束检查该实例。在进一步的实施例中，每个XQuery约束是无副作用的布尔表达式。

在一个实施例中，该组XQuery状态中的至少一个XQuery状态在层级上是另一个XQuery状态的子状态，并且由该至少一个XQuery状态限定的该组XQuery约束包括从该另一个XQuery状态继承的XQuery约束。

在一个实施例中，该组XQuery状态中的至少一个XQuery状态限定了一组XQuery计算，并且关于第一子集验证该实例包括：进行由第一子集限定的该组XQuery计算。在进一步的实施例中，该组XQuery计算的结果被存储在该实例的一个或多个域中。

在一个实施例中，如果在第一时间点成功地验证了该实例，则用指示该实例对于第一子集有效的信息标记该实例。

根据本发明的另一个实施例，提供了一种其上存储有可由计算机系统执行的程序代码的计算机可读存储介质。该程序代码包括使计算机系统存储XML文档的一组XQuery状态并在第一时间点确定该组XQuery状态的第一子集以用于验证XML文档的实例的代码。该程序代码进一步包括使该计算机系统在第一时间点关于第一子集验证该实例，而无需关于不在第一子集中的XQuery状态验证该实例的代码。

根据本发明的另一个实施例，提供了一种系统。该系统包括：处理组件，被配置成存储XML文档的一组XQuery状态并在第一时间点确定该组XQuery状态的第一子集以用于验证该XML文档的实例。该处理组件被进一步配置成在第一时间点关于该第一子集验证该实例，而无需关于不在第一子集中的XQuery状态验证该实例。

可参照说明书的剩余部分和附图来实现对此处公开的实施例的性质和优点的进一步的理解。

附图说明

图1是根据本发明的实施例的可使用的系统架构的简化框图。

图2是根据本发明的实施例的可使用的计算机系统的简化框图。

图3是根据本发明的实施例的用于验证XAP元素实例的过程的流程图。

图4是根据本发明的实施例的用于关于特定类型/状态验证XAP元素实例的过程的流程图。

图5是根据本发明的实施例的类型/状态层级的简化框图。

图6是根据本发明的实施例的XAP应用流程的简化框图。

具体实施方式

在下面的说明中，为了解释的目的，阐述了众多细节以提供对本发明实施例的理解。然而，对本领域普通技术人员显而易见的是，某些实施例在没有一些上述细节的情况下也能够实践。

本发明的实施例提供了用于开发可扩展业务应用的平台(此处被称为可扩展应用平台或XAP)。在一组实施例中，XAP可包括基于可扩展标记语言(XML)的应用模型，该模型被设计为支持高度的应用可扩展性。例如，XAP应用模型可支持应用语义的声明式定义、应用数据和元数据的分离、以及允许数据对象实例(例如，XML文档)的约束和计算(例如，XQuery约束和计算)随时间改变的灵活的类型系统。在某些实施例中，可经由被配置成与类似电子表格的客户机侧用户界面互操作的服务器侧的数据库/应用引擎来实现XAP应用模型。使用类似电子表格的UI，非编程人员可建立、定制并运行在如传统业务应用的共享数据库上工作的应用工作流。

1.XAP系统架构

图1是根据本发明的实施例可使用的系统架构100的简化框图。如图所示，系统架构100可包括一个或多个客户机102、104，一个或多个服务器106、108，以及经由网络112通信地耦合的一个或多个数据库110。尽管图1绘出了两个客户机、两个服务器和一个数据库，但可支持任何数量的客户机、服务器和数据库。

客户机102、104被配置成呈现类似电子表格的客户机侧UI(此处被称为XAP UI)，用于建立和运行XAP应用。在一组实施例中，可使用诸如AJAX或Adobe Flex的基于Web的技术来编程XAP UI；在这些情况下，客户机102、104可在传统Web浏览器应用中呈现XAP UI。在其它实施例中，可在专有客户机应用中呈现XAP UI。客户机102、104可以是通用计算机，诸如运行微软Windows、苹果OSX或其它消费者操作系统的台式或膝上型计算机。客户机102、104还可以是能够通过网络进行通信并与服务器106、108交互的任何其它类型的电子设备(例如，智能电话、PDA、书写板、上网本等)。

服务器106、108被配置成执行服务器侧的XAP应用/数据库引擎，并向客户机102、104提供各种计算和数据存储服务。在某些实施例中，服务器106、108可以是可缩放的服务器云(server cloud)的一部分。像客户机102、104一样，服务器106、108可以是运行任何各种消费者操作系统的通用计算机。服务器106、108还可以是专用的服务器计算机，诸如安装在机架上的服务器，其被配置成运行面向服务器的操作系统(例如，Solaris、FreeBSD、Linux等)。

服务器106、108能够接收和处理来自客户机102、104的多个不同类型的XAP服务请求。在一个实施例中，服务器106、108能够接收和处理用于生成由客户机102、104呈现的XAP UI的多个部分的请求。在另一个实施例中，服务器106、108能够接收和处理用于执行各种XAP应用语义的请求。例如，如下面要进一步详细说明的，用户可限定应用数据对象(例如XML文档)的类型和状态，其中每个类型或状态包括一组约束和/或计算(例如，XQuery约束/计算)。服务器106、108能够执行这些约束和计算(经由例如XQuery引擎)，并将结果提供给客户机102、104。

而在另一个实施例中，服务器106、108能够接收并处理用于从共享数据库110存储和/或检索信息的请求。一般来讲，数据库110用作所有XAP应用数据和元数据的中央数据存储。在特定实施例中，数据库110可以被实现为基于XML的数据库，并且所有XAP数据和元数据都可以被封装成XML文档。这实现了优于诸如基于SQL的存储等其它方案的许多优点。例如，基于XML的存储支持数据模式改变而不要求改变XML文档实例，并且允许XML文档的多个用户变形同时存在。基于XML文档的存储还支持非结构化的、半结构化的和高度结构化的数据。这些特征便利了在应用模型级别上的定制化，这是XAP的一个重要方面。

在图1的实施例中，数据库110，作为单个逻辑实例，驻留在一个或多个与服务器106、108分离的机器中。例如，数据库110可驻留在单独的甲骨文RDBMS服务器中。在该实施例中，服务器106、108能够经由RDBMS协议，诸如Oracle Callable Interface(OCI)与数据库110进行通信。在作为替代的实施例中，能够以分布方式实现数据库110，其中，数据库被分割为驻留在服务器106、108(和服务器云中的其它服务器)中的许多单独的(逻辑)实例。根据该设计，每个服务器能够负责存储和管理整个数据存储的一部分。

在其中XAP客户机侧和服务器侧之间的交互是基于Web的实现方式中，客户机102、104能够经由HTTP请求与服务器106、108通信。此外，可在诸如Apache的Web服务器模块内实现由服务器106、108执行的处理。在其中XAP客户机侧和服务器侧之间的交互是基于专有技术的实现方式中，客户机102、104和服务器106、108能够经由定制的协议进行通信。

网络112可以是任何类型的数据通信网络，诸如局域网(LAN)、广域网(WAN)、虚拟网络(例如，VPN)或因特网。在某些实施例中，系统架构110的各种组件能够通过不同类型的网络进行通信。例如，在一个实施例中，客户机102、104能够经由因特网与服务器106、108通信，服务器106、108能够经由安全的局域网(例如，企业内部网)与数据库110通信。

应理解，系统架构100是示例性的，并且不旨在限制本发明的实施方式。例如，在一个替代性的实施例中，服务器106、108的计算和数据存储功能可被分段到两个不同类型的服务器——计算服务器和存储服务器中。因此，能够经由分离的计算和存储云单独地缩放计算和存储管理资源。在另一个替代性的实施例中，由服务器106、108进行的处理的多个部分可由客户机102、104处理，并且客户机能够直接与数据库110交互。本领域技术人员将认识到其它变形、修改和替换。

图2是根据本发明的实施例使用的计算机系统200的简化框图。例如，计算机系统200可用于实现图1中说明的客户机或服务器102、104、106和108中的任何一个。如图2所示，计算机系统200可包括经由总线子系统204与多个外围设备进行通信的一个或多个处理器202。这些外围设备可包括存储子系统206(包括内存子系统208和文件存储子系统210)、用户接口输入设备212、用户接口输出设备214和网络接口子系统216。

总线子系统204能够提供用于使计算机系统200的各个组件和子系统按照意图彼此通信的机制。尽管总线子系统204被示意性地示为单个总线，但总线子系统的替代性实施例可利用多个总线。

网络接口子系统216可用作用于在计算机系统200和其它计算机系统或网络(例如，图1的网络112)之间传送数据的接口。网络接口子系统216的实施例可包括以太网卡、调制解调器(电话、卫星、电缆、ISDN等)、数字用户线(DSL)单元等。

用户接口输入设备212可包括键盘、指点设备(例如，鼠标、跟踪球、触摸板等)、扫描仪、条形码扫描仪、包括在显示器中的触摸屏、音频输入设备(例如，语音识别系统、扬声器等)和其它类型的输入设备。一般来讲，术语“输入设备”的使用旨在包括用于将信息输入到计算机系统200的所有可能类型的设备和机制。

用户接口输出设备214可包括显示器子系统、打印机、传真机或非可视显示器，诸如音频输出设备等。显示器子系统可以是阴极射线管(CRT)、诸如液晶显示器(LCD)的平板设备、或投影设备。一般来讲，术语“输出设备”的使用旨在包括用于从计算机系统200输出信息的所有可能类型的设备和机制。

存储子系统206可包括内存子系统208和文件/盘存储子系统210。子系统208和210代表可存储提供本发明的功能性的程序代码和/或数据的计算机可读存储介质。

内存子系统208可包括多个内存，包括用于在程序执行期间存储指令和数据的主随机存取存储器(RAM)218、和其中存储固定指令的只读存储器(ROM)220。文件存储子系统210可提供程序和数据文件的持久(即，非易失性)存储，并且可包括磁或固态硬盘驱动器、带有相关联的可移除介质的软盘驱动器、带有相关联的可移除介质(例如，CD-ROM、DVD、蓝光等)的光学驱动器、基于可移除闪存存储器的驱动器或卡、和/或现有技术中已知的其它类型的存储介质。

应理解，计算机系统200是示例性的，并且不旨在限制本发明的实施方式。具有比系统200更多或更少组件的许多其它配置是可能的。

2.XAP APPLICATION MODEL

下面的章节描述XAP应用模型的组件。该应用模型可包括：尤其是，数据结构构造(例如，元素、类型、状态)、组构造(例如，文档)和形成XAP应用的基础的其它应用级构造(例如，约束、计算、链接、活动)等。在一组实施例中，许多这些组件可经由类似电子表格的UI被声明式地定义，从而允许熟悉电子表格(但可能不具有编程专长)的用户建立并运行XAP应用。

在各个实施例中，XAP应用模型被设计成促进高度的定制化和最小化其中对应用数据结构的改变(例如，添加新数据对象、修改应用于现有数据对象的业务规则等)要求修改程序代码的实例。此外，应用模型被设计成促进在XAP应用之间共享和重复使用组件。这些设计原理反映在下面描述的模型的多个方面。

2.1元素

元素是将名称(从而语义)与一条数据相关联的XAP数据结构构造(construct)。如果两个元素实例共享相同的元素名称，则它们可被认为是可比较的。在一组实施例中，XAP元素可被表示为XML元素。例如，XAP元素名称可对应于XML元素名称，并且XAP元素实例内的数据可对应于XML元素的标签内包括的数据。此外，XAP元素(以及其它XAP模型实体)可使用传统的XML命名空间来命名。因此，XAP元素名称可由命名空间(例如，“http://xap.oracle.com/demo/store”或被简称为“store”)和命名空间内的本地名称(例如，“order”，是购买定购数据对象的简称)组成。

在一组实施例中，XAP元素可以是标量元素或结构元素。XAP标量元素是包含一条数据的元素。因此，标量元素可被视为原子数据对象。在特定的实施例中，标量元素可对应于XAP UI中的单个数据域。下面是存储美国邮政编码的值的标量元素实例(使用XML标签来定义)的例子：

<store:zipcode>90210</store:zipcode>

在某些实施例中，标量元素可与标量数据类型相关联。标量数据类型可用作对XAP应用/数据库引擎如何存储和索引该元素的实例的提示。如果标量元素的实例数据不能被转换成具体的标量数据类型，则该数据可被存储为串。由XAP支持的标量数据类型的例子包括：

◆空-空元素通过其是否存在来传递信息。这些也被称为标志元素。

◆布尔-布尔元素包含真/假值。对于比较(collation)的目的，真排在假之后。

◆整数-整数包含补码整数(two’s complement integer)，大小最高为例如64位(可使用约束将其限制到较小的大小)。

◆浮点-浮点包含浮点值。可以相同方式(数值地)比较浮点数和整数。

◆小数-小数包含具有无限精度的使用基数为10位表示的浮点值。数值比校。

◆串-串包含零或更多Unicode(UTF8)字符的阵列。串值按照值索引以UTF8二进制排序进行比较。

◆二进制-二进制包含零或更多8比特字节的阵列。二进制比较。

◆日期-日期包含格里历(Gregorian calendar)日期，由年、月和日构成。时间比较。

◆时间-时间包含时、分、秒、分数秒。时间比校。

◆链接-链接是提供对另一个(结构)元素实例的引用的XAP构造。

XAP结构元素是包含一个或多个其它标量或结构元素的元素。因此，结构元素可被视为层级数据对象。在特定实施例中，结构元素可对应于XAP UI中的一行数据(包括多个数据域)。下面是包括“线路”、“城市”和“邮政编码”标量元素的美国式地址的结构元素实例的例子：

<store:address>

      <store:line>ABC Avenue</store:line>

      <store:line>Apt.123</store:line>

      <store:city>Beverly Hills</store:city>

      <store:zipcode>90210</store:zipcode>

</store:address>

在一组实施例中，结构元素的每个实例可在共享XAP数据库(例如，图1的数据库110)中被表示和存储为单独的XAP文档(例如，XML文档)。下面将在“文档”的章节中更详细地讨论XAP文档。

此外，每个结构元素可与XAP类型和一个或多个XAP状态相关联。一般来讲，结构元素的XAP类型可定义不变的一组规则(即，约束)，该组规则用于在其生命期中验证该元素的实例，并且结构元素的XAP状态可定义仅用于在某些时间验证该元素实例的多组规则。下面将在“类型和状态”章节中更详细地讨论XAP类型和状态。

在一组实施例中，XAP元素在共享XAP数据库内可以是唯一的，因此在所有XAP应用的团体内可具有全局作用范围。这促进了应用之间的元素名称的共享和重复使用。例如，如果用户创建了在一个XAP应用中名为“xap:address”的元素，则该元素名称可以对创建其它XAP应用的其它用户可见(并且可用于重复使用)。此外，共享的元素在每个应用中可具有相同语义(例如，数据结构、类型、状态)。这有多个益处/特征，诸如应用之间公共的数据对象的一致行为/外观，以及基于元素名称的自动数据合并。

2.2.文档

XAP文档是用于组织XAP数据(例如，元素实例)和XAP元数据(例如，类型和状态定义)的分组构造。在一组实施例中，XAP文档可被表示为XML文档。XAP文档可被视为XAP系统中隔离和原子改变的单元。因此，当XAP应用正在操作/修改一个文档时，该应用可确保该文档内的所有信息是内部一致的。

在各个实施例中，所有XAP文档可存储在共享的XAP数据库中，并且可经由虚拟文件系统接口访问。在一个实施例中，可由XAP应用/数据库引擎为由用户创建的结构元素的每个实例创建和存储新文档。下面是封装“store:order”元素实例的数据的示例XML文档：

<？xml version＝″1.0″encoding＝″ISO-8859-1″>

<store:order xmlns:xap＝″http://xap.oracle.com″

              xmlns:xlink＝″http://www.w3.org/1999/xlink″

              xmlns:store＝″http://xap.oracle.com/demo/store″>

  <store:ordernumber>12345</store:ordernumber>

  <store:date>2008-08-08</store:date>

  <store:name>Herman Munster</store:name>

  <store:shipto xlink:href＝″/customers/munster.xml#_001″/>

  <store:orderline xap:id＝″_001″>

      <store:item xlink:href＝″/products/widget.xml″/>

      <store:price>10.00</store:price>

      <store:quantity>2</store:quantity>

     <store:total>20.00</store:total>

    </store:orderline>

    <store:orderline xap:id＝″_002″>

      <store:item xlink:href＝″/products/grommet.xml″/>

      <store:price>20.00</store:price>

      <store:quantity>1</store:quantity>

      <store:total>20.00</store:total>

   </store:orderline>

   <store:total>40.00</store:total>

</store:order>

还可以为由用户声明式地定义的XAP元数据定义(即，描述XAP数据或XAP应用流的语义的数据)创建和存储XAP文档。这种元数据定义的例子包括：类型、状态和活动。在一个实施例中，XAP元数据定义可被存储在与XAP元素实例分离的XML文档中。该途径使数据结构和数据之间的依赖性最小化，从而便利应用定制化。

在用户定义的数据和元数据以外，每个XAP文档可进一步包括驻留在单独的XML元素树上的系统元数据。该系统元数据可以包括例如文档的创建者、修改日期、访问许可(ACL)和大小(字节)。系统元数据还可以识别已关于该文档验证了的类型/状态的列表、以及被发现的错误列表。

在一组实施例中，可根据两个级别-主版本和次版本，来版本化XAP文档。只要XAP文档经由XAP UI“公布”，就创建主版本，并且该主版本对应于对其它用户可见的文档变化。如果当创建主版本时其它用户正在修改文档的过程中，则那些用户可能需要将它们的改变并入新的主版本。

文档的次版本可经由XAP UI客户机自动地或手动地创建，并且对应于编辑该文档的用户的个人保存点。在次版本中捕获的变化对于其它用户不可见，并且将使其不可见直到公布该变化并创建新的主版本。

在一组实施例中，共享的XAP数据库可维护文档的所有先前的主版本的拷贝。如下面的“约束”章节中描述的，当XAP应用存在于特定时间点时，这允许XAP应用参考XAP文档中的历史数据。

2.3.链接

链接是一种XAP标量元素，其引用存储在与包含该链接的文档/元素实例分离的XAP文档中的结构元素实例。链接可用于引用在多个元素实例中共享的数据，而无需一定要复制每个实例中的数据。在一组实施例中，XAP链接可以经由传统XML XLink来表示。

上面的“文档”章节中示出的“store:order”文档包括三个链接(在下面突出显示)：

  <store:order xmlns:xap＝″http://xap.oracle.com″

             xmlns:xlink＝″http://www.w3.org/1999/xlink″

             xmlns:store＝″http://xap.oracle.com/demo/store″>

    <store:ordernumber>12345</store:ordernumber>

    <store:date>2008-08-08</store:date>

    <store:name>Herman Munster</store:name>

    <store:shipto xlink:href＝″/customers/munster.xml#_001″/>

    <store:orderline xap:id＝″_001″>

     <store:item xlink:href＝″/products/widget.xml″/>

     <store:price>10.00</store:price>

     <store:quantity>2</store:quantity>

     <store:total>20.00</store:total>

   </store:orderline>

   <store:orderline xap:id＝″_002″>

    <store:item xlink:href＝″/products/grommet.xml″/>

    <store:price>20.00</store:price>

    <store:quantity>1</store:quantity>

    <store:total>20.00</store:total>

  </store:orderline>

  <store:total>40.00</store:total>

</store:order>

在该例子中，“store:order”元素实例包括到“customers/munster.xml#_0001”中存储的客户的送货地址的链接。此外，“store:order”元素实例包括到分别在“products/widget.xml”和“products/grommet.xml”中存储的两个分开的货物说明的链接。

在一组实施例中，XAP链接可指向(默认)最新的参考文档的主版本。该行为可通过约束链接指向特定的历史版本(由版本号识别)而改变。

使用传统的XLink来实现XAP链接的一个问题是XLink是不可逆的。为了解决这个问题，XAP可包括被称为xap:getInLinks()的内置函数，其提供了从特定目标元素的逆导航。在一组实施例中，xap:getInLinks()可将(1)目标元素，(2)要找到的链接的类型作为自变量。例如，可使用下述代码来找到被发送到特定地址的所有订单：

$x:＝xap:getInLinks($address，‘store:order/store:shipto’)

2.4.类型和状态

传统类型系统提供一类数据的名称、以及限制可以处于该类中的数据的种类的规则或约束的列表。类型系统在下面意义上有用：它们可将关于该程序代码想要构成的数据的假设代码化，从而使代码不那么复杂。然而，现有的类型系统具有多个缺陷使应用开发(并且，具体地讲，应用定制化)的多个方面很困难。

首先，现有的类型系统假设每个数据对象(例如，XML文档)具有单个类型，并且该类型是不可变的。因此，应用于数据对象的约束不能随时间修改。这在若干不同场景中是有问题的。例如，考虑流过购买订单工作流的“订单”对象。该订单对象可经历多个不同的工作流阶段，诸如“新”、“开帐单”、“送货”和“完毕”。从业务的角度，为了适当验证该订单对象，该订单对象会需要在不同阶段呈现不同的域和/或约束(例如，在送货阶段是跟踪号)。然而，通过单一的静态类型，不能支持此类动态修改约束。

另一个例子是，考虑这样一个应用，其最初被开发为存储“个人”对象的单个“SSN”(社会安全号)属性(假设每个人具有一个SSN)。在部署了该应用之后，具有身份证被盗的问题的人可被输入该应用，并且该人可具有分配给她的第二SSN。在该情况下，该应用需要被修改为支持“人”对象中的第二SSN属性。然而，通过单一的静态类型，此类的定制也不能被支持(在不重写应用代码的情况下)。

现有的类型系统的第二个问题是类型定义通常与程序代码和/或数据紧密结合。例如，在许多情况下，类型是以程序式(programmatically)定义的而不是以声明式(declaratively)定义的。这使得非编程人员难以进行类型修改，因为需要重写和重编译受影响的程序代码。在其它实例中，类型定义通常与它们所涉及的数据一起被存储。这通常允许当存储和访问该数据时进行一些优化，但当进行类型修改时，需要触及所有现有的数据实例。

XAP应用模型提供了克服这些和其它相似问题的灵活的类型系统。在一组实施例中，XAP类型系统可包括两个不同的分类构造：类型和状态。这两个构造可具有需要满足的名称和一组约束，以使得该类型/状态关于数据对象实例(即，元素实例/XML文档实例)有效。XAP类型与传统类型相似之处在于：XAP元素实例可仅与一个XAP类型相关联，并且该XAP类型在该实例的生命期内是“激活”的(即，强制使用该类型约束)。然而，XAP元素实例还可以与多个XAP状态相关联，并且一个或多个XAP状态可以在该实例的生命期中的各个点对于该实例是激活的或不激活的。利用该基于状态的范式，XAP应用可随时间向元素实例应用变化的多组约束。

在一组实施例中，XAP类型/状态中包括的约束可被表示为XQuery表达式。因此，此处，XAP类型/状态还被称为XQuery类型/状态。

在某些实施例中，可声明式地(而不是程序式地)定义XAP类型和状态，并将其存储在与它们涉及的元素数据分离的XAP文档(例如，XML文档)中。因此，XAP类型和状态中捕获的应用语义可由非编程人员定义/定制，而不要求重写程序代码或修改现有元素实例。在一个实施例中，一旦已由用户创建了类型或状态，该类型或状态可自动地(经由共享的XAP数据库)对XAP用户的全部团体可用，以在其它XAP应用中重复使用或定制。

图3是根据本发明的实施例用于验证XAP元素实例(例如，XML文档实例)的过程300的流程图。在一组实施例中，可通过在图1的服务器106或108上运行的XAP应用/数据库引擎来执行过程300。

在块302，可存储一个类型和一组状态，其中该类型和该组状态与XAP元素相关联。如上所述，该类型可定义永远关于该元素的实例被检查的一组约束，而状态可定义在特定时间点可能或可能不关于元素实例被检查的多组约束。在一组实施例中，该类型的名称与元素的名称相同，而状态的名称可以不同。例如，之前描述的“store:order”结构元素可具有命名为“store:order”的相关联的类型，以及例如分别命名为“store:neworder”、“store:paidorder”、“store:shippedorder”和“store:closedorder”的四个相关联的状态。

在块304，可在第一时间点确定该组状态的第一子集，以用于验证元素的实例。在一组实施例中，在将XAP元素实例/文档作为XAP活动(在下面的“活动”章节中进一步详细说明)的一部分提交的基础上可验证该XAP元素实例/文档。当提交该活动时，XAP活动的定义可指定(经由“输出状态”属性)哪个或哪些状态是激活的，从而应该被验证。因此，在块304的确定步骤可对应于在提交一个活动的点确定哪些状态被该活动指定为是激活的。

例如，假设上面描述的“store:order”元素实例已经经由“TakeOrder”活动被输入XAP应用，该活动指定“store:neworder”状态作为其输出状态。在该情况下，可确定第一子集包括“store:neworder”状态。一旦确定了第一子集，可在第一时间点关于类型和第一子集验证该元素实例(块306)。因此，在提交“Take Order”活动时，可关于“store:order”类型和“store:neworder”状态验证该“store:order”元素实例(而无需验证“store:paidorder”、“store:shippedorder”和“store:closedorder”状态)。

在块308，可在第二时间点确定该组状态的第二子集，以用于验证该实例，其中，该第二子集与第一子集不同。例如，假设“store:order”元素已经由“Bill Order”活动被支付，所述“Bill Order”活动指定“store:paidorder”状态作为其输出状态。在该情况下，可确定第二子集包括“store:paidorder”状态。一旦确定了第二子集，可在第二时间点关于该类型和第二子集验证该实例(块308)。因此，在提交“BillOrder”活动时，可关于“store:order”类型和“store:paidorder”状态验证该“store:order”元素实例(而无需验证“store:neworder”、“store:shippedorder”和“store:closedorder”状态)。

可对于修改“store:order”元素实例的其余的下游活动(例如，“Ship Order”、“Close Order”等)重复块304-308。因此，XAP可(经由不同的激活状态)在该实例的生命期内对“store:order”实例应用改变的一组约束。在某些实施例中，基本类型“xap:order”可以一直被验证，而不管哪些状态是激活的。

在一些实施例中，XAP类型系统可包括被称为“sticky state”的状态的变形。如关于步骤304和308所述的，确定元素实例的哪些状态是激活的可基于活动的输出状态；如果状态没有被列为输出状态，则将不被验证。当特定状态被标记为粘附状态(sticky state)时，每次修改元素实例/文档时都关于该元素实例/文档验证该状态。在一组实施例中，活动可将其自己的输出状态标记为粘附的，从而使得该状态对于所有下游活动是激活的，而不管是否是那些活动的输出状态。在另一组实施例中，活动可采用之前为元素实例/文档验证过的现有状态，并将其标记为粘附的。而在另一组实施例中，活动可去除之前粘附在元素实例/文档上的粘附状态。在某些实施例中，活动可具有两个输出状态(一个粘附，另一个不粘附)，并且这两个状态可以用AND连在一起。

应理解，过程300是示例性的，并且变形和修改是可能的。可并列地执行按顺序描述的步骤，可改变步骤的顺序，并且可修改、组合、添加或省略步骤。本领域技术人员将认识到其它变形、修改和替换。

图4是根据本发明的实施例的用于关于特定类型/状态验证元素实例(例如，XML文档实例)的过程400的流程图。在一组实施例中，过程400可被执行为图3的块306和310的一部分。

在块402中，可关于在类型/状态中定义的约束来检查元素实例中的数据。在一组实施例中，类型/状态可取决于约束为真或者约束为假。在特定实施例中，与类型/状态相关联的所有约束都必须被满足，以使该类型/状态有效。

作为验证过程的一部分，还可以执行类型/状态中包括的任何计算(块404)。XAP计算是可用于用计算值填充结构元素实例中的特定标量子元素的公式。例如，在“store:order”元素的情况下，可使用计算来确定将所有订单行的值加在一起的“order total”。下面在“计算”章节中更详细地讨论XAP计算。

如果在块402执行的检查成功，则可用实例相对于该类型/状态有效的指示来标记存储该元素实例的文档(块406、408)。如果在步骤404执行的检查不成功，则可生成错误消息(块406、410)。在一组实施例中，错误消息可具体识别未满足的约束或一组约束。

应理解过程400是示例性的，并且变形和修改是可能的。可并列地执行按顺序描述的步骤，可改变步骤的顺序，并且可修改、组合、添加或省略步骤。本领域技术人员将认识到其它变形、修改和替换。

在某些实施例中，XAP类型和状态可被组织成一个或多个类型/状态层级，使得类型/状态层级中的子类型/状态能够继承其父类型/状态的所有语义(例如，约束、计算等)。该特征允许用户重复使用和定制由其它用户定义的类型和状态。图5示出了实例层级500。在该实施例中，层级500支持多个继承，从而“客户产品服务订单”状态可从“客户服务订单”状态和“产品订单”状态继承语义。

2.5.约束

XAP可支持多个不同类型的预定的声明式约束，包括：

◆平面(facet)-对标量元素的值的限制；

◆基数(cardinality)-对子元素可在父元素中出现的次数的限制；

◆组分-用于在元素内或元素之间构成约束的规则；

◆引用-对引用其它元素或来自其它元素的引用的检查；

◆只读-对在之前的活动期间可改变什么数据的限制；以及

◆唯一-指定特定元素的值在文档内唯一；以及

◆编码-以XQuery编写的开放式(open-ended)约束。

在一组实施例中，XAP约束可以被表达为XQuery表达式，并且因此在此处被称为XQuery约束。

2.5.1.平面

平面约束的例子包括“宽度”、“范围”、“包含(in)”、“精度”和“模式”。宽度约束可用于对串和二进制数据类型的标量元素设置最小或最大尺寸。这可用于例如对XAP UI中的文本域，诸如地址行，设置最大尺寸。

范围约束可对任何标量元素，包括那些具有数值、日期/时间、串和二进制数据类型的标量元素，设置包含性和/或排除性的上界和/或下界。例如，排除性的下界范围约束可用于要求一个量大于零。

包含约束可定义值的列表，目标标量元素应该在其中。一般来讲，这些值应该与目标标量元素的底层数据类型相匹配。

精度约束可用于指定数值的有效位的总数、基数之后的位数、和/或最小舍入单位。例如，对于货币域的精度约束可指定基数之后的两位用于美元面额，并且可进一步要求舍入至最接近的硬币值。

模式约束可限制串值以匹配常规表达。例如，邮政编码域可被限制为匹配5位邮编或使用常规表达的邮编+4标准。

2.5.2.基数

基数约束的例子包括“出现”、“选择”、“联合”和“组”。出现约束可对父元素中子元素的出现次数设置具体的最小值(minoccurs)或最大值(maxoccurs)。该约束可用于例如需要子元素(minoccurs＝1)，不允许子元素(maxoccurs＝0)，或将子元素约束为单一值(maxoccurs＝1)。

选择约束可列出相互排斥的子元素的列表。当来自子元素列表的恰好一个元素必须出现时，该约束可有用处。例如，选择约束可以要求社会安全号(SSN)或雇主身份号(EIN)出现，但不是都出现。

联合约束可要求子元素的列表中的至少一个出现。例如，联合约束可要求电子邮件地址或电话号码。与选择约束不同，二者可都出现。

组约束可要求子元素列表中的所有元素集体出现。当元素的一个子集必须一起出现，或一起不出现时，该约束有用。例如，组约束可要求城市元素和州元素集体出现。

2.5.3.组分

组分约束的例子包括：“存在”、“子元素-状态”、“子元素-验证”和“组合”。存在约束可要求存在子代元素的至少一个实例。尽管其它组分约束仅应用于元素的直接子元素，但存在约束可指定向下到达嵌套的子元素的路径，并要求至少一个出现。在一组实施例中，存在约束可被标志为反向的，从而要求不存在与路径相匹配的出现。

子元素-状态约束可要求子元素处于(或者不处于)一个特定状态。在某些实施例中，该约束还可包含子元素的类型。这提供了一种手段，使得要求可沿XAP结构元素实例/文档向下贯彻，或跨另一个文档中的元素。

子元素-验证约束与子元素-状态约束相似，但可再验证嵌套的元素。

组合约束本身不提供任何验证，但可用于根据“先决”规则(下面描述)组合多个约束。

2.5.4.引用

引用约束应用于作为链接的子标量元素。引用约束的例子包括“作用域”、“非循环”和“历史”。作用域约束可要求链接与链接集合中的一个相匹配(或不匹配)。在一组实施例中，作用域约束可使用由相对于同一父元素的另一个子元素的路径定义的链接集合。例如，作用域约束可用于限制<store:billto>链接指向一个地址，该地址是在由<store:purchaser>链接所指向的客户下发现的地址中的一个。请注意，如果未出现该子元素，则可认为满足作用域约束；换句话说，仅当子元素存在并指向不在链接集合中的事物时，才算破坏作用域约束。在某些实施例中，作用域约束可被声明为反向的，也就是说，要求子元素不在链接集合中。在这些情况下，仅当子元素存在并在链接集合中时才算破坏该约束。

非循环约束可要求链接不沿特定路径指回父元素。

历史约束可要求链接指向固定(即，历史)版本的目标元素实例/文档。在各个实施例中，如果不使用历史约束来约束链接，则链接会指向目标的最新的版本。

2.5.5.只读

在一组实施例中，关于类型/状态验证元素实例/文档的行为出现在数据修改(例如，活动)的范围内。只读约束可用于标记没资格被改变的元素。如果将只读约束用于常规状态，则它仅能够防止使用该状态作为输出状态的活动修改所指示的元素(这可用于例如，使得域对于UI流中的仅一个屏幕可读)。如果将只读约束用于粘附状态中，则可“锁定”所指示的元素，使得它们不能被任何下游活动修改。

2.5.6.唯一

唯一约束可用于将子元素定义为在特定结构元素实例/文档的上下文内是唯一的。在一组实施例中，唯一性可作为连接唯一关键字(concatenated unique key)应用于单个子元素，或作为连接唯一关键字应用于多个子元素。例如，唯一约束可要求员工元素的姓、名和地址的连接是唯一的。

2.5.7.编码

编码约束是可被评估以产生真或假值的代码块(例如，XQuery表达式)。在一组实施例中，编码约束可被用于定义子元素之间的条件。例如，编码约束可要求在“store:order”元素中的送货量小于定购的量。在某些实施例中，编码约束可以是没有副作用的，并仅根据它们的输入来产生一致的结果。

2.5.8.组合约束

在一组实施例中，上面描述的XAP约束可以根据布尔逻辑条件被声明式地组合成多约束表达式。然后，这些多约束表达式可与类型/状态相关联。此外，可根据“先决”系统对约束排序，从而允许多约束表达式中的某些约束在其它约束之前被评估。

在先决系统中，XAP约束可列出零个或更多其它约束作为“先决”，从而声明它自己从属于这些约束。然后，XAP应用/数据库引擎可在评估从属约束之前检查先决约束。约束可使用两个关键字以启动该功能：

◆验证-在评估从属约束之前，要求先决为真。

◆拒绝-在验证从属约束之前，要求先决为假。

此外，存在确定如何组合先决检查的结果的两个关键字：

◆和-必须满足所有先决(按照需要，验证为真或验证为假)。

◆或-必须满足至少一个先决。

在一组实施例中，约束可以被标记为具有对其先决的“软”依赖性。这与如果先决不满足，则在没有评估约束的情况下，XAP将认为约束失败了的普通逻辑相反。而是，如果先决不满足，在没有评估约束的情况下，软约束可被认为成功了。

2.6.计算

XAP计算是可与XAP类型或状态相关联的计算构造。具体地讲，XAP计算在结构元素的上下文中指定被分配了评估表达式(右手侧或RHS)的结果的标量子元素(左手侧或LHS)。一旦对具体元素实例/文档运行了计算，则计算的结果可作为数据被存储在该实例/文档中。可使用计算来例如，在根据其它域中输入的数据自动填充/更新的XAP应用中提供“虚拟”域。在某些实施例中，XAP计算可被表示为XQuery表达式，并因此在此处也被称为XQuery计算。

下面是可为之前描述的“store:order”元素/类型定义的计算的例子：

●price:＝xap:deref(item)/price

通过从链接的物品实例中拷贝物品标价来计算物品价格

●total:＝price＊quantity

通过价格乘以数量来计算行总额

●total:＝sum(../total)

通过将所有的行总额相加来计算订单总额

在某些实施例中，永远相对于特定父元素来定义XAP计算，并且LHS(即，计算目标)永远是该父元素的直接子元素。例如，在上面的例子中，相对于“store:orderline”元素定义第一和第二计算，并且那些计算的LHS是“store:orderline”的直接子元素。相对于“store:order”元素定义第三计算，并且该计算的LHS侧是“store:order”的直接子元素。在另一组实施例中，LHS是父元素本地的(即，它不能是链接文档中的域)。计算的RHS(即，公式)可使用本地和链接的值(例如，经由上面第一计算中示出的xap:deref()操作符)。

在一组实施例中，XAP计算可定义迭代上下文以在其中评估公式。该上下文可以是识别对其运行计算的一组子元素的相对XPath(没有谓词(predicate))。这允许父元素定义沿结构层级比其直接子元素远的计算。例如，在上面的第三计算中，公式“sum(../total)”使用上下文“../”来将加和的范围缩小至“store:orderline”，而不是“store:order”的级别。在某些实施例中，由父元素(通过缩小范围)定义的计算可不考虑对子元素定义的计算。

默认地，XAP计算可以在每一次经由XAP UI修改RHS中的任何数据时运行/再运行。XAP计算也可具有允许用户控制他们运行的条件的下述预定标志：

◆仅运行一次-用于不应重复的计算，如存储文档上的时间戳，或向文档分配来自序列的ID。

◆仅当出现所有RHS元素时运行-用于如果需要的所有数据没出现时不应运行计算的实例。例如，如果计算基于邮政编码为地址生成城市和州，则当没有邮政编码时不应运行计算。

◆仅当提交了文档时运行-仅在活动的上下文中是可应用的。

◆仅当没有数据已经出现在LHS中时运行。

如关于图5的类型/状态层级在上面描述的，类型/状态可从它们的父元素继承计算。如果由于本地定义和继承的计算，对于特定LHS目标元素，类型/状态具有冲突的计算定义，则可按照类型/状态时间戳的顺序来运行计算(例如，较新的状态比较老的状态具有优先性，并且对元素的基本类型定义的计算可具有最低的优先性)。下面是可关于“store:order”的子类型存在的计算的例子，不管计算价格的普通方法是什么：

◆price:＝xap:deref(item)/price＊(1-xap:deref(../billto)/discount)

通过采用标价并应用客户折扣来计算物品价格。

2.7.活动

XAP活动是定义XAP应用的工作流的应用级构造。具体地讲，每个XAP活动可对应于业务流中的一个处理步骤，诸如“TakeOrder”、“Bill Order”、“Ship Order”等。通常来讲，XAP活动是终端用户能够对由XAP管理的元素实例/文档进行改变(例如，添加、编辑或删除数据)的手段。

在一组实施例中，每个XAP活动能够与XAP UI中的UI屏幕相关联。此外，每个活动可包括，尤其是，输入查询和输出状态。当首先呈现UI时，输入查询可用于查询具有特定XAP类型的XAP文档(例如，元素实例/XML文档实例)。此外，这些文档可根据一些过滤标准被过滤(例如，检索已经关于“store:paidorder”状态被验证了的类型为“store:order”的所有文档)。由输入查询返回的结果集合对应于当前活动的上下文中需要被操作的数据集合。

在一组实施例中，活动的输入查询可以是普通XQuery(例如，不具有脚本或更新的XQuery 1.0)或XAP声明性查询。XAP声明性查询被设计成有利于使用XAP UI的基本工作流和查询定义。在一些实施例中，用于定义XAP声明性查询的UI可自动地过滤出已经用当前活动的输出状态验证了的文档。此外，UI可指定状态的列表来检查已经被处理过的文档，并指定直接子元素、操作符和常量的列表，以创建简单的(field<operator>constant)查询标准，它们可以是用AND连接在一起的。

活动的输出状态可指定一旦该活动完成并且提交了任何修改的文档就将被检查的XAP状态。提交文档可使得文档关于基本类型和输出状态被验证，使得运行任何计算、公布改变(即，创建主版本)，从而它们对于其它XAP用户可见，并用输出状态已被验证的指示标记该文档。

图6是示出用于使用状态和活动的示例性XAP应用的工作流600的简化框图。如图所示，已经为该应用定义了的状态(由圆圈表示)是“新”、“已支付”、“已送货”和“完毕”，并且已经为该应用定义的活动(由正方形表示)是“下订单”、“收帐”、“送货订单”和“关闭订单”。假设被管理的信息的基本类型是“订单”。

在一组实施例中，“下订单”活动可具有空的输入查询，并可将其输出状态指定为“新”。因此，当呈现对应于“下订单”活动的表单时，可向用户呈现空表单以输入新订单数据。一旦用户已输入了订单数据并指示“下订单”活动完成，XAP引擎就可关于被定义为输出状态的“新”状态验证数据。例如，XAP引擎可检查每个新订单文档是否具有订单号。然后，XAP引擎可将文档标记为处于“新”状态，并将更新后的文档存储在共享的XAP数据库中以用于进一步处理。

“收帐”活动可具有输入查询，该查询检索已关于“新”状态被验证(但没有关于其它状态被验证)了的“订单”类型的所有文档，并且可将其输出状态指定为“已支付”。因此，当呈现对应于“收帐”活动的表单时，该表单可显示系统中已输入但还未开帐单的所有订单。一旦用户恰当地修改了订单数据，并指示“收帐”活动完成，则XAP引擎就可以关于被定义为输出状态的“已支付”状态验证修改后的数据。例如，XAP引擎可检查每个订单文档是否具有帐单信息。然后，XAP引擎可将文档标记成处于“已支付”状态，并将更新后的文档存储在共享的XAP数据库中以用于进一步处理。

“送货订单”活动可具有输入查询，该查询检索已关于“已支付”状态被验证了(但没有关于“已送货”状态被验证)的“订单”类型的所有文档，并且可将其输出状态指定为“已送货”。因此，当呈现对应于“送货订单”活动的表单时，该表单可显示系统中已支付但还未送货的所有订单。一旦用户恰当地修改了订单数据，并指示“送货订单”活动完成，XAP引擎就可以关于被定义为输出状态的“已送货”状态验证修改后的数据。例如，XAP引擎可检查每个订单文档是否具有送货跟踪号。然后，XAP引擎可将文档标记成处于“已送货”状态，并将更新后的文档存储在共享的XAP数据库中以用于进一步处理。

最后，“关闭订单”活动可具有输入查询，该查询检索已关于“已送货”状态被验证了(但没有关于“完毕”状态被验证)的“订单”类型的所有文档，并且可将其输出状态指定为“完毕”。因此，当呈现对应于“关闭订单”活动的表单时，该表单可显示系统中已送货但还未完毕的所有订单。一旦用户恰当地修改了订单数据，并指示“关闭订单”活动完成，XAP引擎就可以关于被定义为输出状态的“完毕”状态验证修改后的数据。例如，XAP引擎可检查每个订单文档包括已接收到订单的指示。然后，XAP引擎可将文档标记成处于“已关闭”状态，并将更新后的文档存储在共享的XAP数据库中。

在图6的例子中，所有活动可以是人类活动，因为需要人来经由XAP UI输入或修改由输入查询返回的数据。对于这些类型的活动，XAP UI可通过在数据被输入从属域时自动地填写UI中的LHS元素，连续运行由基本类型或状态定义的任何计算(就像常规电子表格一样)。此外，XAP UI可连续地检查由输出状态定义的约束，使得用户可以在键入的同时能够被提示验证错误(这与在提交文档之后才提供那些错误相反)。

XAP还能够支持计算机活动，即可经由程序代码(例如，XQuery脚本代码)使其自动化或半自动化的活动。在一组实施例中，计算机活动可修改共享的XAP数据库中的任何文档，和/或调用外部Web服务。如果，例如，计算机活动中的XQuery代码块调用xap:submit()扩展功能来处理文档提交，则XQuery代码可捕捉从输出状态验证出现的任何例外。如果XQuery代码不能修正通过输出状态验证所找到的所有例外，则标记该文档，使得它们可稍后由人类用户查询以解决错误。

尽管在上面描述了本发明的具体实施例，但各种修改、变更、替换构造和等同物也在本发明的范围内。例如，XAP不限于在企业环境中使用，并且可用于建立在共享数据库上层运行的任何类型的应用流。此外，尽管已关于某些流程图和步骤描述了本发明的实施例，但本领域技术人员应显而易见地得出本发明的范围不限于所描述的流程图和步骤。

此外，尽管本发明的实施例是使用硬件和软件的特定组合描述的，但应认为硬件和软件的其它组合也在本发明的范围内。

因此，说明书和附图应被视为是示例性的而不是限制性的。显然，在不偏离如下面的权利要求书中所述的本发明的较宽的精神和范围的情况下，可以对其进行添加、删减和其它修改。

Claims (16)

1.一种方法，包括：

由计算机系统存储XML文档的一组XQuery状态；

由所述计算机系统在第一时间点确定该组XQuery状态的第一子集；以及

由所述计算机系统在第一时间点关于所述第一子集验证XML文档的实例，而不关于不在第一子集中的XQuery状态验证该实例。

2.如权利要求1所述的方法，进一步包括：

在第二时间点确定该组XQuery状态的第二子集，所述第二子集与第一子集不同；以及

在第二时间点关于所述第二子集验证该实例，而不关于不在第二子集中的XQuery状态验证该实例。

3.如权利要求2所述的方法，进一步包括：

存储XML文档的类型；以及

自动地在第一时间点和第二时间点关于该类型验证该实例。

4.如权利要求1所述的方法，其中，该组XQuery状态中的每个XQuery状态被存储为单独的可扩展标记语言(XML)文档。

5.如权利要求1所述的方法，其中，该组XQuery状态中的每个XQuery状态定义一组XQuery约束。

6.如权利要求5所述的方法，其中，该组XQuery约束中的每个XQuery约束是无副作用的布尔表达式。

7.如权利要求5所述的方法，其中，该组XQuery状态中的至少一个XQuery状态是层级中另一个XQuery状态的子状态，并且其中，由所述至少一个XQuery状态定义的该组XQuery约束包括从所述另一个XQuery状态继承的XQuery约束。

8.如权利要求5所述的方法，其中，关于第一子集验证该实例包括：关于由该第一子集定义的多组XQuery约束检查该实例。

9.如权利要求5所述的方法，其中，该组XQuery状态中的至少一个XQuery状态进一步定义一组XQuery计算。

10.如权利要求9所述的方法，其中，关于所述第一子集验证该实例包括：进行由该第一子集定义的多组XQuery计算。

11.如权利要求10所述的方法，其中，所述多组XQuery计算的结果存储在该实例的一个或多个域中。

12.如权利要求1所述的方法，其中，如果在第一时间点成功地验证了该实例，则以指示该实例关于第一子集有效的信息来标记该实例。

13.一种计算机可读存储介质，其上存储有可由计算机系统执行的程序代码，所述程序代码包括：

使所述计算机系统存储XML文档的一组XQuery状态的代码；

使所述计算机系统在第一时间点确定该组XQuery状态的第一子集，以验证所述XML文档的实例的代码；以及

使所述计算机系统在第一时间点关于该所述第一子集验证所述实例，而不关于不在第一子集中的XQuery状态验证该实例的代码。

14.如权利要求13所述的计算机可读存储介质，其中，所述程序代码进一步包括：

使所述计算机系统在第二时间点确定该组XQuery状态的第二子集以验证该实例的代码，所述第二子集与第一子集不同；以及

使所述计算机系统在第二时间点关于该第二子集验证该实例，而不关于不在第二子集中的XQuery状态验证该实例的代码。

15.一种系统，包括：

处理组件，被配置成：

存储XML文档的一组XQuery状态；

在第一时间点确定该组XQuery状态的第一子集以验证该

XML文档的实例；以及

在第一时间点关于该第一子集验证该实例，而不关于不在

第一子集中的XQuery状态验证该实例。

16.如权利要求15所述的系统，其中，所述处理组件进一步被配置成：

在第二时间点确定该组XQuery状态的第二子集以验证该实例，所述第二子集与第一子集不同；以及

在第二时间点关于该第二子集验证该实例，而不关于不在第二子集中的XQuery状态验证该实例。

Images