CN1455901A

CN1455901A - Xml编码方案

Info

Publication number: CN1455901A
Application number: CN01815548A
Authority: CN
Inventors: 厄恩斯特·Y·C·万
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2000-10-06
Filing date: 2001-10-05
Publication date: 2003-11-12
Anticipated expiration: 2021-10-05
Also published as: CN1244062C; US20040028049A1; EP1323064A1; EP1323064A4; WO2002029602A1; KR100566019B1; AUPR063400A0; DE60129232T2; KR20030061819A; US7647552B2; ATE366441T1; DE60129232D1; JP2004510279A; EP1323064B1; JP4574114B2

Abstract

本文描述了一种用于传达层次型表达式(102)描述的文档(104)的结构的至少一部分的方法(900)。该方法标识(902)了文档(104)的层次型表达式(即，树结构)。优选情况下，该标识是使用XML标记执行的。然后，该表达式被分组(906)为许多数据包。在一对数据包之间至少创建(908)一个链接，该链接用于表示表达式的对应的的组件(例如，结构和内容)之间的互连。然后，数据包被形成(910)通信流。链接保持了数据包内的层次型表达式。

Description

XML编码方案

技术领域

本发明涉及XML(可扩展标记语言)文档的编码，具体来说，至少涉及对XML文档的压缩、流式传输、搜索和动态构成中的一个。

背景技术

要使MPEG-7说明的流式传输、下载和存储更有效，可以对说明进行编码和压缩。对与提供MPEG-7说明有关的许多问题的分析涉及考虑用于进行二进制已编码的格式。现有的用于XML的编码方案，包括来自WAP(无线应用协议论坛)的WBXML、Millau算法和XMill算法都已经被考虑。

借助于WBXML，频繁使用的XML标记、属性和值被分配来自全局代码空间的固定的代码集。在整个文档实例中不断重复的应用程序特定的标记名称、属性名称和一些属性值被分配来自一些局部代码空间的代码。WBXML保留了XML文档的结构。未在文档类型定义(DTD)中定义的内容以及属性值可以以内嵌方式存储或存储在字符串表中。文档的代码空间的表对特定类的应用程序是已知的或与文档一起传输。

虽然WBXML标记化了标记和属性，但是没有对文本内容进行压缩。尽管如此对于建议用于WAP的无线标记语言(WML)文档可能已经足够，WBXML是为WML设计的，因为此类文档通常具有有限的文本内容，对于典型的充满文本XML文档，WBXML算不上是非常有效的编码格式。Millau方法通过使用传统的文本压缩算法来压缩文本，扩展了WBXML编码格式。Millau还利用架构和数据类型以对基元数据类型的属性值更好地进行压缩。

Xmill算法的作者提出了一种甚至更复杂的编码方案，虽然这样的方案不基于WBXML。除了将结构和文本编码分开以及使用DTD中的类型信息和用于对内置数据类型的值进行编码的架构之外，该方案还：

(i)将相同的或相关的类型的元素组合到容器中(以提高冗余度)，

(ii)单独地使用不同的压缩器对每个容器进行压缩，

(iii)允许原子压缩器被组合成更复杂的压缩器，以及

(iv)允许对高度专门的数据类型使用新的专门的压缩器。

虽然如此，现有的编码方案只是为压缩而设计的。它们不支持XML文档的流式传输。此外，使用XPath/XPointer寻址方案仍不能有效地定位元素，也不能如文档所构成的那样增量地对其进行编码。

发明内容

根据本说明书的一个方面，提供了一种用于传达层次型表达式描述的文档的结构的至少一部分的方法，所说的方法包括下面的步骤：

标识所说的文档的所说的表达式；

将所说的表达式分组为许多数据包，所说的数据包具有预先确定的大小，所说的分组包括在一对所说的数据包之间至少创建一个链接，所说的链接表示所说的表达式的对应的组件之间的互连；以及

将所说的数据包形成通信流，其特征在于，所说的链接保持了所说的数据包内的所说的表达式。

根据本说明书的另一个方面，提供了一种用于传达层次型表达式描述的文档的结构的至少一部分的方法，所说的方法包括下面的步骤：

至少标识所说的表达式的一部分和将所说的部分分组到预先确定的大小的至少一个数据包，其特征在于，所说的表达式的所说的部分的一个或多个不在一个所说的数据包内，定义了从所说的一个数据包到至少另一个将所说的非适合部分分组到其中的所说的数据包的至少一个链接，所说的链接保持了所说的数据包中的所说的文档的层次型结构。

根据本说明书的另一个方面，提供了一种促进对XML文档的结构进行访问的方法，所说的方法包括下面的步骤：

标识所说的文档的层次型表达式；

将所说的表达式分组为许多预先确定的数据包大小的数据包；

在所说的数据包之间形成链接，以将所说的表达式的那些部分定义为不能够在一个数据包内表达，从而能在取消分组之后重建所说的表达式。

目前描述的编码和解码方案将结构和文本编码分开，并使用架构和数据类型对内置数据类型的值进行编码。此外，说明书还提供了对流式传输的支持，并允许使用类似于XPath/XPointer的寻址机制进行有效的搜索。如此还允许对如XML文档所构成的那样对其进行编码和流式传输。这些功能对于广播和移动应用十分重要。目前描述的编码方案还支持多个名称空间，并提供位流的EBNF定义和一组用于构建可扩展编码器的接口。

附图说明

现在参考图形和附录描述本发明的一个或多个实施例，其中：

图1概要描述了一种已编码的XML文档；

图2描述了结构段的组织；

图3概要描述了编码器模式；

图4概要描述了解码器模式；

图5概要说明了将XML文档增量编码到多个数据包的编码器；

图6A和6B显示了如何使用节点定位器将一个节点链接到其他结构数据包中的子树以及每个节点定位器如何包含子树的数据包的数据包号码；

图7概要描述了如何将长字符串存储为多个文本数据包中的字符串段，每个数据包指向包含下一段的文本数据包；

图8是可以用来实现所描述的布局的计算机系统的示意方框图表示；

图9是XML文档编码操作的流程图；

图10是说明如何以编码操作对不同的数据类型进行处理的流程图；以及

附录提供了对于已编码的位流和它的参数有用的定义。

具体实施方式

优选情况下，将要参考图1到7和9和10进行描述的对XML文档进行编码和解码的方法，使用如图8所示的通用计算机系统800来实现，其特征在于，图1到7的过程可以作为诸如在计算机系统800内执行的应用程序的软件来实现。具体来说，这些方法的步骤可以通过由计算机执行的软件中的指令来实施。软件可以被分成两个单独的部分：一个部分用于执行编码/解码方法；另一部分用于管理编码/解码方法和用户之间的用户界面。软件可以存储在计算机可读的介质中，例如，包括下文所述的存储设备。软件从计算机可读的介质中被加载到计算机，然后由计算机执行。具有此类软件的计算机可读的介质或在记录它上面的计算机程序是计算机程序产品。优选情况下，在计算机中使用计算机程序产品影响着用于对XML文档进行编码/解码的有利的装置。

计算机系统800包括一个计算机模块801，诸如键盘802和鼠标803之类的输入设备，包括打印机815和显示设备814的输出设备。调制器-解调器(调制解调器)收发器设备816由计算机模块801用来与通信网络820进行通信，例如，可通过电话线821或其他功能介质进行连接。可使用调制解调器816来对因特网、诸如局域网(LAN)或广域网(WAN)之类的其他网络系统进行访问。如图所示的服务器计算机系统850连接到网络820，能与计算机系统800进行通信。服务器计算机850通常具有类似的结构和/或以与计算机系统800类似的或对其补充的方式运行。例如，在计算机系统800可以执行XML编码功能的同时，服务器计算机850也可以执行补充的XML解码功能，以及相反的功能。

计算机模块801通常至少包括一个处理器单元805、例如由半导体随机存取存储器(RAM)和只读存储器(ROM)构成的存储器单元806，包括视频接口807的输入/输出(I/O)接口，以及用于连接键盘802和鼠标803以及可选地连接游戏杆(未显示)的I/O接口813，以及用于连接调制解调器816的接808。还提供了存储设备809，通常包括硬盘驱动器810和软盘驱动器811。还可以使用磁带驱动器(未显示)。通常提供CD-ROM驱动器812作为非易失性数据源。计算机模块801的组件805到813，通常通过互相连接的总线804进行通信，所采用的方式导致对相关的技术中的那些人已知的计算机系统800的操作的传统模式。可以在上面实施所描述的布局的计算机示例包括IBM-PC以及兼容的计算机、Sun Sparcstations或从此发展而来的类似的计算机系统。

通常，应用程序驻留在硬盘驱动器810并在其执行中由处理器805读取和控制。程序的中间存储和从网络820获取的任何数据可以使用半导体存储器806并可能与硬盘驱动器810协同来完成。在一些情况下，应用程序可以用CD-ROM或软盘提供到用户，并通过对应的驱动器812或811读取，或者可以由用户通过调制解调器设备816从网络820读取。此外，软件还可以从其他计算机可读的介质加载到计算机系统800，包括磁带、ROM或集成电路、磁光盘、计算机模块801和另一个设备之间的无线或红外传输信道、诸如PCMCIA卡之类的计算机可读的卡，以及因特网和Intranet，包括电子邮件传输和记录在网站上的信息。前述的内容只是相关的计算机可读的介质的示范。也可以使用其他计算机可读的介质。

在操作中，XML文档编码/解码功能是在服务器计算机850或计算机系统800其中的一个系统中执行的，如此形成的分组位流通过通信网络820进行传输，以便分别由计算机系统800或服务器计算机850接收和解码，视具体情况而定。如此，XML文档可以方便地在两个位置之间以有效的方式进行传输，同时提供了在接收器端在接收时动态将文档解码的最佳时间，而不必首先接收整个文档。

编码和解码的方法可以部分地或整体地由专用的硬件实现：如执行编码和/或解码或功能或子功能的一个或多个集成电路。此类专用的硬件可以包括图形处理器、数字信号处理器、或一个或多个微处理器和关联的存储器。

对XML进行编码和压缩

将结构和文本分开

传统上，XML文档通常以它们的原始的文本格式存储和传输。在一些应用程序中，XML文档是使用一些用于存储或传输的传统的文本压缩算法来进行压缩的，并在对它们解析和处理之前解压缩回XML。

根据本说明书，对XML文档进行编码的另一种方式是对文档的树形层次结构(如文档的DOM表达式)。编码可以以宽度优先或深度优先的方式执行。要使压缩和解码更有效，由XML文档内的标记表示的XML结构，可以与XML文档文本分开和编码。在传输已编码的文档时，结构和文本可以以单独的流发送或连结到单个流中。

如图1所示，根据该实施例，XML文档104的树形表达式102，该树形表达式通常在存储器中出现，包括许多节点116，并以深度优先方式编码。文档104的结构和其中包含的文本可以以显示的方式分别作为两个单独的流106和108进行编码，或连结到单个流中。结构流106由代码表110和114开头。树102的已编码的节点118都具有大小字段(未显示)，表示节点的大小，并包括其后裔节点的总大小。某些已编码的叶节点118包含链接112，这些链接将那些叶节点链接到文本流108中的它们对应的编码内容。文本流108中的每个编码字符串都由表示字符串的大小的大小字段(未显示)开头。在连结到单个流的情况下，包含链接112的根的数据包应该在那些包含链接112所指向的文本的数据包前面，从而确保文档104的结构组件在对应的文本(内容)组件之前由解码器接收到。

图9中还描述了图1中所示的方法作为编码方法900的流程图，该方法可以作为在计算机系统800上运行的软件程序来实现。方法900至少传达层次型表达式描述的文档的结构的一部分，并具有入口步骤902。最初，在步骤904中，方法900标识文档104的层次型表达式(例如，树结构)。优选情况下，该标识如上文所提及的是使用XML标记执行的。在步骤906，表达式被分组到许多数据包中。在步骤908中，至少在一对数据包之间创建一个链接。该链接表示该表达式的对应的组件(例如，结构和内容)之间的互连。在步骤910中，数据包被形成通信流。链接保持了数据包内的层次型表达式。方法900在步骤912结束。

一般来说，结构信息的量比文本内容的量小得多。结构通常在一个文档实例内嵌套和重复。将结构与文本分开允许任何重复模式由压缩算法比较轻松地标识，该算法通常通过固定大小的窗口检查输入流。此外，结构和文本流具有相当不同的特征。因此，不同的和更有效的编码方法可以应用到每一个结构和文本。

结构在提供用于解释文本的上下文时是关键的。在编码器中将结构和文本分开可使对应的解码器更快地解析文档的结构，从而只处理相关的元素而忽略它不知道或不需要的元素(和后裔)。解码器甚至可以选择不缓冲与任何不相干的元素关联的的文本。解码器是否将已编码的文档转换回XML取决于要执行的特定应用程序(请参阅下面有关应用程序编程接口-API的讨论)。

代码表

文档说明的元素和它们的属性在DTD或架构中定义。通常，一组元素和它们关联的属性在一个文档实例中反复地使用。元素名称以及属性名称和值可以被分配代码以减少要求对它们进行编码的字节的数量。

通常，每一个应用程序域都使用许多架构和/或DTD中定义的不同的元素集。此外，每个架构或DTD都可以包含不同名称空间的定义。即使某些元素和类型对多个类别的应用程序是共同的，它们通常也以不同的模式使用。即，对域A和B共同的元素X，可以频繁地在域A中使用，而很少在域B中使用。此外，始终会更新现有的架构并创建新架构。因此，最好将代码分配留给忽略它们的域中的互操作性的组织。例如，MPEG-7说明是XML文档。MPEG可以为其自己的描述符和说明方案定义代码空间以及它们使用的外部元素和类型。MPEG还可以定义生成代码空间的方法。理想的情况下，该方法应该基于熵(平均信息量)—即，基于描述符的发生的数量以及说明中的说明方案或说明的类(请参阅有关生成代码空间的部分)。

将元素和属性分开

XML标记通常包括元素名称和一组属性名称/值对。潜在地，大的属性集可以以元素实例来指定。因此，将元素名称与属性分开将更快地解析文档树和定位元素。此外，某些属性或属性名称/值对比其他的属性或属性名称/值对使用得更频繁。将属性名称、值和名称/值对分组为不同的部分通常产生更好的压缩。

内置数据类型和特殊类型的编码值

编码器将根据属性的值和内置(或默认)数据类型的元素的类型将它们编码进更有效的表达式。如果包含类型信息的架构不可用，那么值将被作为字符串对待。此外，如果值(例如，单个位整数)将更有效地表示为字符串，编码器还可以选择将它作为字符串对待并不对其进行编码。默认情况下，字符串被作为通用文本格式(UTF-8)字符串来编码，通用文本格式提供了将多字节字符的字符串编码的标准和有效方式。此外，UTF字符串包括长度信息，避免查找适当的分隔符的的问题，并可使人轻松地跳到字符串的末尾。

可以为特殊的数据类型使用特殊类型的编码器。这些特殊类型的编码器可以使用编码器API的setTypeEncoder()接口来指定(如下面所讨论的)。优选情况下，有关特殊类型的编码器的信息存储在结构段的标头部分，优选情况下作为类型编码器标识符的表。此外，默认类型编码器(内置数据类型的)可以使用相同的机制来覆盖。如此在某些内置数据类型通常将使用默认编码器进行编码的情况下，可以使用特殊的编码器，如此，需要位流内的标识，以致于要正确地复制XML文档，需要替代的解码过程。每个已编码的值的前面有用于对值进行编码的类型编码器的标识符。

如此，根据本说明书实现的XML文档编码器可以包括用于XML文档内的不同类型的结构和文本的许多编码格式。某些编码格式可以被内置或默认，并用于已知的或通常遇到的数据类型。可以为任何特殊的数据类型使用特殊类型的编码器。在这种情况下，在编码过程中使用的特定类型编码器的标识可以被集成到数据包的标头部分，从而能使解码器标识那些需要用于编码文档中的编码类型的解码过程。在适当的地方，特定类型的编码器可以通过统一资源标识符(URI)从计算机网络进行访问。在解码器无法访问或实现对应于编码文档中的一个数据包内遇到的编码类型的解码过程的情况下，默认响应可以是忽略该编码数据，可能会导致复制空数据(例如，空白显示)。一种替代方法是，在解码器可以操作以从连接的网络获取特殊类型的解码器的情况下，例如使用可以跟随编码数据的URI。编码器/解码器格式的URI可以被集成到上文提及的表中，从而包括在位流中(请参阅附录)。

在此方法的进一步扩展中，多个编码格式可以用于单个数据类型。例如，可以基于字符串的长度不同地对文本字符串进行编码，如此表示了执行解码过程所需要的时间和可以获得的压缩水平之间的折衷。例如，具有0-9字符的文本字符串可能不能被编码，而具有10-99和100-999字符的字符串可以以相应的(不同的)编码格式被编码。此外，那些编码格式中的一个或多个可以用于特殊的数据类型。如此在此示例中编码器对文本字符串进行编码时，编码器可以在实践中对于0-9字符串不使用编码，对于10-99字符串使用默认编码器，对于具有100个以上文本字符的字符串，使用特殊的编码器。

图10显示了具有步骤1102的入口点的对XML文档进行编码的方法1000的示例。最初，在步骤1004中，方法1000检查XML文档104以标识构成XML文档104的组成部分的每一种数据类型。在步骤1006，方法1000操作以标识对于其对应的特殊编码格式可用的第一个数据类型集。标识了特殊的数据类型之后，步骤1008用对应的特殊编码格式对具有第一个集中的数据类型的每一部分的XML文档进行编码。接下来，在步骤1010中，方法1000用对应于其余部分的数据类型的默认编码格式对XML文档的每一个其余部分进行编码。在步骤1012中，表达式由使用对应的特殊编码格式至少引用第一个集中的每一个数据类型的信息构成。在步骤1014中，表达式与作为XML文档104的编码形式的编码部分关联。然后，方法1000在步骤1016结束。

结构段(或结构流)

图2显示了结构段(或流)106的各个部分。结构段以标头202开头，其正文被分成许多部分204。标头202标识XML的版本和编码格式的版本。

正文中的每一部分204以表示该部分类型的唯一签名开头。因此，各个部分不必以特定顺序排列。虽然如此，在下面的讨论中，我们假设各个部分以图2所示的顺序排列。部分签名后面跟着表示该部分的大小的大小字段。

ID表部分206可使具有ID的元素被在文档层次结构部分208快速定位。即使文档具有带有ID的元素，编码文档中可以没有ID表206。这是因为，包含ID定义的DTD或架构在编码时可能不可用。

优选情况下，部分210是为文档类型声明和内部(DTD)子集预留的。对于基于XML架构的文档，例如MPEG-7说明，此部分210将不存在。

有名称空间212、元素名称214、属性名称216和属性值218的代码表的部分。此后这些代码表将被称为本地代码表，以将它们与为编码器和解码器预先定义的并且不在位流中传输的任何代码表区别开来。例如，MPEG-7或XML架构可以有预先定义为代码表。

本地代码表后面通常跟包含属性名称/值对220的表的部分，该部分使用本地代码表以及任何预先定义的代码表中定义的代码。

文档层次结构部分208是使用本地和预先定义的代码表中的代码进行编码的XML文档的树结构。

除了使用代码表和用于进行编码的类型编码器之外，在大多数情况下，编码器还使用压缩器压缩每一部分。不是独立地压缩结构段106的正文的每一部分，结构段的正文可以一起压缩。这实际上可能由于较小的开销和更大的数据量导致更好的压缩比率。然而，这样的压缩需要解压缩整个结构正文才能发现一个文档是否包含特定的元素。可以对这两种方法进行测试，以确定在实践中哪一种方法更好。虽然如此，如果一部分较小，压缩可能没有效，编码器可能选择不压缩该部分。每一部分都具有一个压缩标志，以表示是否已经应用压缩。如果已经应用压缩，每一部分的开始处的大小字段以字节为单位表示该部分的经压缩的(而不是未经压缩的)的大小。

潜在地，可以考虑每一部分中的数据的特征，为每一部分使用不同的压缩器。有关所使用的压缩器的信息在标头部分提供。默认值是使用ZLIB压缩结构段以及文本段中的所有部分。ZLIB算法生成一个标头和校验和，以便在解码器端验证压缩的数据的完整性。

文本段(或文本流)

文本段108以文本段签名开头，后面跟表示编码文本的大小的大小字段。文本段包含那些是元素的文本的UTF-8字符串的序列。

编码器和解码器模式

编码器模式

图3显示了集成了所有编码器302的XML编码器模式300，用于将XML文档编码到位流306以便进行存储或传输。编码器模式300可以作为在计算机模块801内操作的软件程序或子程序实现，程序通常存储在HDD810，并由处理器805在其执行中读取和控制。位流306可以在创建时通过I/O接808和网络820进行传输，以便由服务器计算机850补充解码和复制。或者，位流306可以存储在HDD810中或作为驱动器812中的CD-ROM以便进行后面的复制。编码器302可以支持应用程序编程接口(API)308(例如，DOM API)以便在创建树102时对文档树102进行编码。标准库310(用于XML)用于提供代码表312，内置数据类型的编码器314，可以在编码过程中使用的默认压缩器316。还可以为各个域定义域特定的库318。每个域特定的库318可以包含针对特定域的代码表320和针对某些数据类型的编码器322。应用程序还可以提供特定模块324，包括如上文讨论的针对特殊数据类型的应用程序特定的编码器326和对应的压缩器328。然而，这些类型编码器326和压缩器328必须是可下载的，并且是不依赖于平台的或预先安装在解码器端。应用程序还可以命令编码器326使用其预先定义的代码表330。代码表330可以被集成到位流306中或预先安装在解码器端。图3中所示的每一个单个编码器和压缩器可以通过软件(子)程序或在某些情况下通过特殊用途的硬件(例如，用于快速编码)来实现。

解码器模式

图4显示了补充的XML解码器模式400，包括解码器402，用于将XML位流306解码以输出XML文档104。或者，解码器可以支持API 408(例如，SAX(“用于XML的简单API”)或DOMAPI)，可使应用程序构成其自己的文档树102的内部模式。这就使解码器402不必输出XML文档104，使应用程序不必重新解析重建的XML文档104。在任一种情况下，在对XML位流306进行解码时，解码器402使用标准库410，任何域特定的库418以及任何预先安装或下载的应用程序特定的模块424(编码器使用的)。在图4中，解码器模式400的元素以类似于图3的方式进行编号，以便在在编号时存在差异100，元素具有对应的功能。解码器模式400可以在计算机模块801内实现，以对从服务器计算机850通过网络820接收到的位流306进行解码。或者，解码器模式400可以操作以对从CD-ROM获得的位流进行解码。类似于编码器302，可以在解码器402内使用软件和硬件解码过程。

在大多数情况下，客户端的解码器402不必对DTD或架构验证解码的XML文档104。在客户端进行验证是昂贵的，无效率的，最可能是多余的。解码器104可以假设已经在服务器端对照DTD或架构对XML文档进行了验证。同样，诸如内置到二进制格式中的校验和之类的基础传输以及任何错误检测机制应该能够捕获任何传输错误。

定位元素

可以使用ID或XPath/XPointer片段引用和定位XML元素。如上文所述，结构段106的ID表206可使带有ID的元素在文档层次结构部分208中快速地被定位。然后可以使用编码元素中的定位器有效地定位与元素关联的任何文本和属性。

下面是可以附加到统一资源标识符(URI)的XPath片段的某些示例：

·/doc/chapter[2]/section[3]

选择文档的第二章的第三节

·chapter[contains(string(title)，＂Overview＂)]

选择具有一个或多个包含文本“Overview”子标题的上下文节点的子章节

·child∷^*[self∷appendix or self∷index]

选择上下文节点的子附录和索引

·child∷^*[self∷chapter or self∷appendix][position()＝last()]

选择上下文节点的最后一章或子附录

·para[@type＝＂warning＂]

选择具有带有值“warning”的类型属性的上下文节点的所有子段落

·para[@id]

选择具有ID属性的上下文节点的所有子段落。

XPath/XPointer片段包括表示XML文档内的所需要的元素的绝对或相对位置的位置步骤的列表。通常，片段包含一个元素名称的列表。可以使用谓词和函数，如在上文的示例中，以指定诸如一个阵列内的元素的索引、属性的存在、匹配属性值和匹配文本内容之类的更多选择条件。

编码文档层次结构的密实度可使它被解析(和实例化)，而不必扩展为完整的对象树表达式。片段地址首先被转换为编码形式。此类转换过程的其中一个结果是，它允许人立即确定在文档中是否实际存在所需要的元素。匹配编码片段地址的组件还比匹配子字符串效率高得多。该设计允许对简单的XPath/XPointer片段(最频繁使用的)进行快速的评估。在比较复杂的片段地址的情况下，首先搜索文档层次结构还大大地缩小后面的评估步骤的范围。

分组流式传输的位流

流式传输XML

传统上，XML文档通常以它们的原始的文本格式存储和传输。在一些应用程序中，XML文档是使用一些用于存储或传输的传统的文本压缩算法来进行压缩的，并在对它们解析和处理之前解压缩回XML。虽然压缩可以大大地缩小XML文档的大小，在这样的情况下，在可以执行解析和处理之前，应用程序仍必须接收整个XML文档。

流式传输XML文档意味着，解析和处理可以在接收到XML文档的足够多的部分之后尽快地开始。这样的功能在低带宽通信链路和/或使用资源非常有限的设备的情况下最有用。

由于普通的XML分析程序期望XML文档被很好地构成(即，具有匹配和非重叠的起始标记和结束标记对)，分析程序只能以深度优先方式解析XML文档，并且不能忽略文档的部分，除非XML文档的内容被重组以支持它。

分组位流

如前面所述，将XML文档编码为完整的结构段106以及完整的文本段108将大大地缩小数据的大小，同时，允许检测出某些传输错误。虽然如此，解码器402仍必须在它可以处理大量的编码数据之前接收这些编码数据。例如，解码器402将在可以开始对文档层次结构进行解析之前全部接收代码表110。同时，解码器402必须等待文本段108的某些段的到达才能获取与节点关联的文本。为使处理在解码器端尽快地开始，XML文档104，如图5所示，必须被增量地编码，允许编码数据500的较小的数据包502在它们可用时发送到解码器402。在图5中，交叉平行线所画出的阴影部分的数据包504表示结构数据包，对角线数据包506表示文本数据包。在这些数据包前面是标头数据包508，后面跟尾部数据包510。在首选的布局中，每个数据包502都具有与完整的结构段106或完整的文本段108相同的结构。同时，每个数据包502都可以依赖于在它之前发送的那些数据包502，在某些实现中，依赖于在它之后发送的预先确定的数量的数据包。如此预先确定的数量可以动态地确定。

除了需要在提供文档时对其进行处理之外，编码器/解码器通常具有固定大小的输出/输入缓冲区。相应地，除了非常短的文档外，编码器302必须将XML文档增量地编码到多个数据包。每一个数据包502(包括504、506、508和510)都以数据包标头开头。数据包标头包含一个数据包号码，用作数据包ID以及用于对数据包进行排序并检测任何缺少的数据包。数据包标头还包含一个大小字段，它以字节为单位表示数据包502的大小，一个类型字段，它表示数据包是否是结构数据包504、文本数据包506、标头数据包508、尾部数据包510或其他类型的数据包502，以命令数据包为例，未在图5中显示，但在此文档稍后进行描述。

对于每个结构数据包504，集成在其中的ID表只包含该数据包中包括的那些元素的ID。其代码表只包含没有被传输的新代码。已经被传输的代码将不会被重新分配或重新映射。默认实现简单地将新值附加到该表中，并使用入口的索引(按表的基本索引增加)作为它们的代码。稍微复杂一点的(但代码效率比较高的)方法是计数值的发生次数并重映射代码，以使比较频繁地发生的值只是在数据包被输出之前被重映射到较短的代码。如果使用预先定义的代码表或如果重映射不基于发生的次数，在压缩之前对值进行排序可能会导致更好的压缩率。可以实现用于分配代码的不同的算法。虽然如此，一旦输出，代码便是固定的，并且不能被重新指定到其他值或在后面的数据包中重新映射。预先定义的代码表还可以使用编码器接口的UseCodeTable()方法来指定，在此说明书稍后将对此进行描述。该方法还允许人指定预先定义的代码表是否将以数据被编码为位流。对于XML(或诸如MPEG-7之类的应用程序域)的许多名称空间的代码表有希望被硬连线到所有XML(MPEG-7)编码器和解码器，并且不必编码到位流。

如果ID、元素名称、属性名称或属性值比预先定义的长度长，它将以文本数据包和字符串定位器编码，而不是实际的字符串出现在表中。

结构数据包的文档层次结构部分包含一个节点的序列。每个节点都具有以字节为单位表示其(编码)大小的大小字段，包括在数据包中已编码的其后裔节点的总大小。节点可以是一个元素节点、注释节点、文本节点或节点定位器。每个节点都具有表示其类型的nodeType字段。

文档层次结构可以包含：

(i)完整的文档树：这只有对于非常短的文档才可能；

(ii)完整的子树：子树是以前面的数据包中已编码的另一个节点的子节点；以及

(iii)不完整的子树：子树是不完整的，因为整个子树由于时间和/或大小约束不能被编码到一个数据包中。

按照图6A所示的方式使用节点定位器，对于具有不完整的子树602和604的树结构622，用于定位缺少的节点和不完整的子树的后裔。在这一方面，并参考前面的示例，尽管文档104的层次型树表达式102在编码发生时是已知的，在对传达的数据包进行解码时，通常只有树表达式102的一些部分是可用的。随着接收到越来越多的数据包，可以重建树。例如，在图6B所示的数据流中，数据包620(在此示例中是数据流中的#2数据包)包括文档的树结构622的部分，该结构包括节点A、B1、B2和B3。然而，在此示例中，数据包620的大小不足以描述整个树结构622和容纳诸如B4和D1之类的其他节点。如此，节点定位器608和606分别集成到对应的父节点(分别是B3和B2)，并包含结构数据包的相应的数据包号码610和612，结构数据包包含缺少的节点和它们的子树的序列。如此，在接收图6B所示的数据包的序列时，树622的一部分可以在接收数据包(#2)620时重建，包括节点D1的分支可以在接收数据包(#7)610时重建，树的平衡在接收数据包(#20)612时重建。

优选情况下，每个元素节点都包含名称空间代码、元素(名称)代码，并且如果元素具有属性，还包含属性名称/值对表中的第一个属性的字节偏移量和属性的数量。

每个文本节点或注释节点通常都包含文本定位器而不是实际的文本。文本定位器将文本数据包的数据包号码和字节偏移量指定到文本数据包中。

在某些情况下，字符串可以超过数据包的最大大小。在发生这种情况时，字符串作为片段存储多个文本数据包中，如图7所示。每个文本数据包702都具有标志704，表示它是否包含采用UTF-8编码的字符串和字符串定位器或字符串片段的列表。在字符串片段的情况下，还包括下一个片段的数据包号码。如果文本数据包包含字符串的最后几个(或唯一)片段，下一个片段的数据包号码被设置为零，如图所示。

用于构建文档树的命令

XML文档可以分组以便在正在被编码甚至在生成时流式传输到接收器(根据某些预先定义的DTD或架构)。在这种情况下，XML文档通常是使用如DOM API之类的API实时构建的。不是解析XML文件，编码器302操作以直接从存储器表达式构建位流306。使用API插入和附加的节点和子树被作为(二进制)命令数据包编码，以在解码器端修改存储器表达式。数据包号码可以确保命令数据包以正确的序列执行。

由于传输的节点是同一文档(符合某些预先定义的DTD或架构)的组成部分，文档是在线的，并且始终在编码器302和解码器402之间同步，因此相对于节点的内容不应该有任何一致性问题。在某些呈现内容中，某些信息只有时间相关性。即，某些信息只在呈现期间的某些时间段内相关。与呈现内容的两个不同的时间实例相关的信息单位(例如，足球比赛的分数)本身可以不一致。呈现说明方案对于建立呈现的时间和同步模式是理想的。包括XML数据的任何媒体对象的时间可以由开始时间和持续时间来表示。此类呈现编码器/解码器对通常将包括内部排列的XML编码器/解码器，如上文所述。呈现解码器，而不是XML解码器，操作以解释开始时间和持续时间属性。呈现编码器还决定是否要从存储器中删除不再相关的XML子树。只要涉及XML编码器/解码器，就没有一致性问题。如果始终需要生成器才能生成有效的文档(片段)，那么，不需要用命令删除(可能不一致或无效的)节点或子树。即，只需要插入和附加命令。

命令数据包包含要附加或插入的子树的路径(根)和包含该子树的结构数据包的数据包号码。例如，回到图6B，如果节点B4的定位器608不能够容纳在数据包620中，那么，必须在数据包#2和#20之间插入有效地将节点B4附加到节点A的命令数据包。那么，该命令数据包将包括指向数据包612的定位器，该定位器包括由节点B4定义的结构。

位流的定义

优选情况下，位流306以附录定义的方式以扩展Backus-Naur形式(ENBF)定义。字符由单引号引起来，字符串由双引号引起来。除非特别声明，采用UTF-8编码方案中的UCS字符和UTF字符串(包括长度信息)。

API

文档和架构的API

解码器402并不总是需要将已编码的文档转换回XML。如上所述，解码器402可以支持诸如SAX API、DOM API或其他专用API之类的API，以允许应用程序直接访问解码的内容。这就使解码器402不必重建和输出XML文档，使应用程序不必重新解析重建的XML文档。

应用程序还可能必须访问存储在架构中的信息。由于架构也是XML文档，因此，可以以同样的方式对它们进行编码。使用现有的SAX或DOM API来访问和解释架构定义是非常乏味的。支持诸如Wan E.、Anderson M.、Lennon A.说明对象模型(DesOM)文档ISO/IEC JTC1/SC29/WG11 MPEG00/M5817，Noordwijkerhout，March 2000，中定义的架构API之类的分析程序，将使访问架构的定义更为容易。

为允许对内置数据类型和特殊类型的值有效地进行编码，编码器必须能够从架构获得类型信息。因此，架构API也对编码器302非常重要。

编码器的API

下面建议的二进制格式允许实现各种功能和复杂性的编码器。本节描述的接口允许人构建一个基本编码器，然后将基本编码器扩展，以提供编码方案支持的更复杂的功能。

编码器接口

void SetMaxPacketSize(in unsigned long maxPacketSize)

·以字节为单位设置最大数据包大小。

void SetMaxPrivateDataSize(in unsigned long maxPrivateDataSize)

·以字节为单位设置专用数据的最大大小。注意，可以包括在数据包中的专用数据的量由数据包的最大大小进行限制。不期望有大量的专用数据，因为这样会与减少位流的大小的目标有冲突。

void SetHeaderUserData(in ByteArray headerData)

·将用户数据写入到标头数据包。任何现有的数据都将被覆盖。

void UseCodeTable(in CodeTable codeTable，in Boolean encodelt)

·通知编码器有关预先定义的代码表以及代码表是否应该以数据进行编码。

void SetCompressor(in Section section，in Inflater compressor)

·命令编码器使用指定部分的指定压缩器。部分是具有下列值的枚举：STRUCT_BODY＝I，TEXT_BODY＝2，ID_TABLE＝3，NS_SECT＝4，ELEMENT_SECT＝5，ATTR_NAME_SECT＝6，

ATTR_VALU E_SECT＝7，ATTR_PAIR_SECT＝8，DOC_HIERARCHYSECT＝9.

Inflater与java.util.zip封装的Inflater具有相同的接口。

void Flush()

·将缓冲区中的数据包清空到输出流。

void OnOutput()

·在缓冲区中的数据包集被输出以允许应用程序将应用程序特定的数据插入到数据包之前接收通知。

void SetPacketUserData(in ByteArray userData)

·将用户数据写入到除缓冲区中的任何标头数据包之外的每一个数据包。任何现有的用户数据都将被覆盖。

代码表接口

unsigned short GetSize()

·获取代码表中的入口的数量。

wstring GetNamespace(in unsigned short i)

·获取与代码表的第i个入口关联的值的名称空间。

wstring GetValue(in unsigned short i)

·获取与代码表的第i个入口关联的值。

wstring GetType(in unsigned short i)

·获取与代码表的第i个入口关联的值的类型。

ByteArray GetCode(in unsigned short i)

·获取与代码表的第i个入口关联的值。

unsigned short GetlndexByCode(in ByteArray code)

·获取与代码关联的值。

unsigned short GetlndexByValue(in wstring value)

·获取与代码关联的值。

unsigned short GetMaxCodeValue()

·获取代码表保留的最大代码值。编码器可自由地使用比最大代码值大的代码值。视应用程序的情况，还可以实现编码器以使用预先定义的代码表留下的孔。

类型编码器接口

ByteArray Encode(in wstring text)

·将值编码到其文本表达式中提供的字节阵列。

wstdng Decode(in ByteArray encodedText)

·将编码值解码到值的文本表达式中。

对XML数据，具体来说对呈现内容的MPEG-7说明进行编码

如果包括MPEG-7说明(它们是用于描述视听(AV)内容的XML数据)的XML数据(的片段)将被流式播放并以AV内容呈现，必须指定媒体对象(包括XML数据)的时间以及它们之间的同步。类似于XML，DDL(XML的说明定义语言)不定义用于呈现媒体对象的时间和同步模式。如上文所提及的，此处被称为“呈现说明方案”的类似于SMIL的MPEG-7说明方案需要提供时间和同步模式，以便创作多媒体文件。

它已经建议，可以以与AV对象同样的方式对待MPEG-7说明。这意味着，在呈现内容中使用的每一个MPEG-7说明片段，类似于AV对象，将用定义其时间范围的开始时间和持续时间标记。这就允许MPEG-7片段和AV对象被映射到“呈现说明方案”的一个类的媒体对象元素，并受到相同时间和同步模式的制约。具体来说，在基于SMIL的“呈现说明方案”的情况下，可以定义诸如<mpeg7>标记之类的新媒体对象元素。或者，还可以作为特定的文本类型来对待MPEG-7说明。

还可以以单个流或以单独的流发送不同类型的MPEG-7说明。还可以以单个数据流或以单独的流发送具有不同时间范围的子片段的MPEG-7说明片段。与前面讨论的XML编码器300不同，这是一个呈现编码器的角色。

呈现编码器用开始时间和持续时间包装XML数据包，表示何时需要数据包的内容以及需要多长时间。数据包可以包含：

(i)多个简短的说明片段(每个片段都带有自己的时间范围)连结在一起以达到高的压缩率并最大限度地降低开销；

(ii)单个说明片段；以及

(iii)大的说明片段的一部分。

在数据包包含多个说明片段的情况下，数据包的开始时间是片段的开始时间中的最早的，而数据包的持续时间是片段的最后的结束时间(由将片段的持续时间与其开始时间相加计算出)和数据包的开始时间之间的差。

在广播应用中，为能使用户随时接收到呈现内容，相关的材料必须每隔一定间隔重复。虽然只有一些XML数据包必须重发，因为一些前面发送的XML数据包可能不再相关，但是标头数据包需要重复。这意味着，在广播应用的情况下，标头数据包可以散布于结构、文本和命令数据包中，以便将传输重置到一个已知状态。

工业应用前景

从上文的描述中可以显然地看出，所描述的布局适用于计算机和数据处理行业，适用于与其关联的通信资源的有效应用领域，同时与部分地接收的信息一起工作的能力。

前述的内容只描述了本发明的一个或多个实施例，在不偏离本发明的范围和精神和情况下，也可以对具体的实施例作出修改和/或更改，实施例只作说明，而不具有任何限制性。例如，尽管是以XML文档为例进行描述的，此处描述的过程适用于任何层次型表达式，如文档的树表达式。

附录：

位流的定义

位流将以扩展Backus-Naur形式(ENBF)定义。字符由单引号引起来，字符串由双引号引起来。除非特别声明，采用UTF-8编码中的UCS字符和UTF字符串(包括长度信息)。

　　xmlbitStream    ∷＝xmLpacket+

　　注意：编码XML文档的位流包括数据包序列。序列以标头数据包开头并以尾
部数据包结束。

　　数据包

　　xml_packet    ∷＝packet_header packet_body
        <!-- SIPO <DP n="22"> -->
        <dp n="d22"/>
　　packet_header  ∷＝packet_signature packet-number packet-size packet-type

　　                   packet_private_data

　　packet_number  ∷＝variable_length_natural_number

　　       注意：packet_number必须大于0。

　　packet_type    ∷＝header_packet|structure_packet|text_packet|trailer_packet|

　　                   command_packet

　　packet_signature   ∷＝′x′′m′′1′′b′T′n′′p′′k′

　　packet_size        ∷＝unsigned_short

　　注意：对于unsigned_short，范围0-65535中的未经签名的整数是使用2个
字节表示的，第一个字节是高阶字节的整数。

　　packet_private_data    ∷＝byte_array

　　packet_body∷＝header_body|trailer_body|structure_body|text_body|

　　       command_body

　　header_packet     ∷＝′h′

　　structure_packet  ∷＝′s′

　　text_packet       ∷＝′t′

　　trailer_packet    ∷＝′e′

　　command_packet    ∷＝′c′

　　byte_array∷＝size_in byte byte*

　　size_in byte      ∷＝variable_length_natural_number

　　注意：对于variable_length_natural_number，范围0-1，073，741，813中的自然
数是使用1到4个字节表示的，第一个字节是高阶字节的数字。实际使用了高阶字
节的两个最有效的位表示用于表示数字的更多字节的数字。例如，′01′意味着一个更
多字节或2字节表达式，′11′意味着3个更多字节或4字节表达式。)

　　Byte    ∷＝[#xO0 #xFF]

　　标头

　　header_body∷＝enoding_version xml_version xml_params max_packet_size

　　             max_decompressed_packet_size  max_packet_number

　　　           section_compressor_list type_encoder_list
        <!-- SIPO <DP n="23"> -->
        <dp n="d23"/>
　　xml_params∷＝count xml_encoding xml_standalone

　　encoding_version∷＝＂1.0＂

　　xml_version∷＝＂1.0＂

　　count      ∷＝variable_length_natural_number

　　xml_encoding∷＝UTF8_string

　　注意：对于UTF8_String，开头两个字节是未经签名的短的UTF长度，该长
度指定了要被读取的更多字节的数量。更多字节包含字符串的UTF-8编码。

　　xml_standalcne∷＝′y′[′n′max_packet_size∷＝variable_length_natural_number

　　注意：值为0意味着最大数据包大小是未知的。max_packet_number∷＝
variable_length_natural_number

　　注意：值为0意味最大数据包数是未知的。

　　section_compressor_list  ∷＝count(section_ID compressor_URI)*

　　type_encoder_list  ∷＝count(type_ID type_encoder_URI)*

　　compressor_URI  ∷＝URI

　　type_encoder_URI∷＝URI

　　URI    ∷＝UTF8_string

　　section_ID∷＝struct_body_ID|text_body_ID|id_table_ID|ns_section_ID|

　　       element_sect_ID|attribute_name_sect_ID|attribute_value_sect_ID

　　       |attribute_pair_sect_ID|doc_hierarchy_sect_ID

　　struct_body_ID∷＝′s′

　　text_body_ID    ∷＝′t′

　　id table ID     ∷＝′i′

　　ns_section_ID   ∷＝′n′

　　element sect_ID ∷＝′e′

　　attribute_name_sect_ID    ∷＝′a′

　　attribute_value_sect_ID   ∷＝′v′

　　attribute_pair_sect_ID    ∷＝′p′

　　doc_hierarchy_sect_ID     ∷＝′d′

　　type_ID  ∷＝[#x00 #xFF]
        <!-- SIPO <DP n="24"> -->
        <dp n="d24"/>
　　other_type_ID      ∷＝#x00

　　string_ID∷＝#x01

　　string_locator_ID  ∷＝#x02

　　boolean_ID         ∷＝#x03

　　byte_ID  ∷＝#x04

　　unsigned_short_ID∷＝#x05

　　short_ID∷＝#x06

　　unsigned_long_ID∷＝#x07

　　long_ID   ∷＝#x08

　　float_ID  ∷＝#x09

　　double_ID∷＝#x0A

　　date_ID∷＝#x0B

　　time_ID ∷＝#xOC

　　注意：上述内置数据类型的列表是不完整的。类型00-0F是用
于内置数据类型的。XML编码器可以将类型10-FF分配到应用程序
特定的类型。应用程序负责为任何应用程序特定的类型提供(Java)
类型的编码器和解码器。这些类型的编码器和解码器必须在需要它们
之前预先安装或下载。当类型信息不可用，XML文本和属性值将作
为字符串来对待。

　　尾部

　　trailer_body    ∷＝

　　注意：此刻，尾部数据包只用于表示XML文档的结束。尾部数据包的正文是
空的。

　　结构数据包

　　structure_body  ∷＝[ID_table_section][internal_subset_section]

　　      [ns_table_section][element._name_codetable_section]

　　      [attribute_name_codetable_section]

　　      [attribute_value_codetable_section]

　　      [attribute_name_value_pair_section][document_hierarchy_section]
        <!-- SIPO <DP n="25"> -->
        <dp n="d25"/>
　　注意：虽然上述EBNF规则将结构数据包的正文的各个部分定义为以特定顺序
排列，各个部分实际上被允许以任何顺序排列，因为每个部分都由其唯一签名标识。

　　ID表部分

　　ID_table_section∷＝ID_table_section_signature section_size compressed

　　        entry_count(ID_table|compressed ID table)

　　section_size    ∷＝size_in_byte

　　注意：section_size存储排除了其签名的部分的大小。

　　compressed      ∷＝boolean

　　注意：压缩标志表示表是否经过压缩。

　　注意：对于布尔值，字节值1表示true，字节值0表示false。

　　entry_count    ∷＝variable_length_natural_number

　　size of compressed ID table    ∷＝variable_length_natural_number

　　ID_table∷＝(ID_string offset to the_document_hierarchy)*

　　注意：ID_table定义了未经压缩的ID表的结构。ID表只收集出现在相同数
据包的文档层次结构中的节点(不包括由节点定位器引用的节点)的ID。如果在编码
期间类型信息不可用，将不会将ID收集到ID表中，即使它们出现在文档中，因为
编码器没有方法可以标识它们。

　　ID_string∷＝UTF8_string

　　offset to the_document_hierarchy  ∷＝byte_offset

　　注意：offset_to_the document_hierarchy是对于(未经压缩的)
document_hierarchy_section中的document_hierarchy的字节偏移量，不是对于(未
经压缩的)document_hierarhy_section的字节偏移量

　　byte_offset    ∷＝variable_length_natural_number

　　ID_table_section_signature∷＝#xFF01

　　内部子集部分

　　Internal_subset_section∷＝internal_subset_section_signature section_size

　　        compressed[byte*]

　　注意：内部子集部分的详细信息还需要定义。

　　NS_table_section_signature∷＝#xFF02
        <!-- SIPO <DP n="26"> -->
        <dp n="d26"/>
　　名称空间表部分

　　NS_table_section∷＝NS_table_section_signature section_size compressed

　　        entry_count index_base(NS_table|compressed_NS_table)

　　indexbase    ∷＝variable_length_natural_number

　　注意：到NS_table的索引用作名称空间代码。索引的基在字段index_base中
指定。名称空间代码0预留给空名称空间。因此，名称空间表不能具有index_base 0。

　　NS_table∷＝(NS_URI)*

　　注意：NS_table定义了未经压缩的NS表的结构。到表的索引用作名称空间代
码。索引的基在字段index_base中指定。名称空间代码0预留给空名称空间。因此，
名称空间表不能具有index_base 0。

　　NS_URI∷＝URI

　　NS_table_section_signature∷＝#xFF03

　　代码表部分

　　element_name_codetable_section∷＝element_name_codetable_section_signature

　　       section_size compressed entry_count index_base (

　　       element_name_codetable|compressed_element_name_codetable)
attribute_name_codetable_section∷＝attribute_name_codetable_section_signature

　　       section_size compressed entry_count index_base (

　　       attribute_name_codetable|compressed_attribute_name_codetable)
attribute_value_codetable_section∷＝attribute_value_codetable_section_signature

　　       section_size compressed entry_count index_base

　　       has_predefined_code(attribute_value_codetable|

　　       compressed_attribute_value_codetable)

　　注意：到每个代码表的索引用作代码，除非有预定义的代码。代码表允许用于编
码和实际值的代码之间的映射。每个表的索引的基是在该表的字段index_base中指定
的。只允许正代码。因此，index_base不能具有值0。

　　element_name_codetable_section_signature      ∷＝#xFF04

　　attribute_name_codetable_section_signature    ∷＝#xFF05

　　attribute_value_codetable_section_signature   ∷＝#xFF06
        <!-- SIPO <DP n="27"> -->
        <dp n="d27"/>
　　has_predefined_code    ∷＝boolean

　　注意：has_.predefined_code标志指定代码表是否具有predefined_code列。

　　元素名称代码表

　　element_name_codetable  ∷＝element_name_code_table_entry*

　　注意：element_name_codetable定义了未经压缩的元素名称代码表的结构。到
每个表的索引用作元素名称代码，除非有预定义的代码。索引的基在字段index_base
中指定。代码0是预留的。因此，代码表不能具有index_base 0。

　　element_name_codetable_entry∷＝ns_code element_name type_ID[

　　       predefined_code]

　　注意：除了对编码器已知的内置数据类型和特殊类型，所有其他类型的文本内
容都作为字符串编码。

　　predefined_code  ∷＝byte_array

　　注意：空的predefined_code意味着该入口没有预定义的代码。这种情况不应
该发生。如果预先定义的代码表中缺少一个值。编码器必须为该值生成一个代码并将
它存储在predefined_code字段中。

　　element_name    ∷＝non_empty_UTF8_string|(#x0000 string_locator)

　　注意：元素名称通常内嵌存储在表中。然而，如果元素名称太长，则它可以存储
在一个单独的文本数据包中，字符串定位器在表中使用。

　　string_locator    ∷＝text_packet_number byte_offset

　　注意：byte_offset指定了可以找到字符串的地方的文本数据包的正文中的偏移量。

　　non_empty_UTF8_string    ∷＝UTF8_string-＂＂

　　属性名称代码表

　　attribute_name_codetable  ∷＝attribute_name_code_table_entry*

　　注意：attribute_name_codetable定义了未经压缩的属性名称代码表的结构。到
每个表的索引用作属性名称代码，除非有预定义的代码。索引的基在字段index_base
中指定。代码0是预留的。因此，代码表不能具有index_base 0。

　　attribute_name_codetable_entry∷＝ns_code attribute_name type_ID[

　　         predefined_code]

　　注意：除了对编码器已知的内置数据类型和特殊类型，所有其他类型的文本内
        <!-- SIPO <DP n="28"> -->
        <dp n="d28"/>
容都作为字符串编码。

　　attribute_name  ∷＝non_empty_UTF8_string|(#x0000 string_locator)

　　注意：属性名称通常内嵌存储在表中。然而，如果属性名称太长，则它可以存储
在一个单独的文本数据包中，字符串定位器在表中使用。

　　属性值代码表

　　attribute_value_codetable  ∷＝attribute_value_code_table_entry*

　　注意：attribute_value_codetable定义了未经压缩的属性值代码表的结构。到每
个表的索引用作属性值代码，除非有预定义的代码。索引的基在字段index_base中指
定。代码0是预留的。因此，代码表不能具有index_base 0。

　　attribute_value_codetable_entry∷＝ns_code attribute_value type_ID[

　　         predefined code]

　　注意：除了对编码器已知的内置数据类型和特殊类型，所有其他类型的文本内
容都作为字符串编码。

　　attribute_value  ∷＝encoded_value

　　注意：属性值通常内嵌存储在表中。

　　encoded_value∷＝encoded_value_of_non_string_type|non_empty_UTF8_string|(

　　....″″#x00)|(#x0000 string_locator)

　　注意：是根据值的类型进行编码的。除了对编码器已知的内置数据类型和特殊类
型，值作为字符串编码。

　　注意：空的UTF8字符串必须后面跟着#x00以便将它与有效的字符串定位器
区别开来。此外，如果属性名称太长，则它可以存储在一个单独的文本数据包中，字
符串定位器在表中使用。

　　属性名称/值对部分

　　attribute_name_value_pair_section∷＝attribute_name_value_pair_section_signature

　　         section_size compressed entry_count index_base(

　　         attribute_name_value_pair_table

　　         compressed_attribute_name_value_pair_table)
attribute_name_value_pair_table＝attribute_name_value_pair_entry*

　　注意：attribute_name_value_pair_table定义了未经压缩的属性名称/值对表的
        <!-- SIPO <DP n="29"> -->
        <dp n="d29"/>
结构。索引的基(＞0)是在字段index_base中指定的。
attribute_name_value_pair_entry    ∷＝attribute_name_code attribute_value_code

　　attribute_name_value_pair_section_signature    ∷＝#xFF07

　　文档层次结构部分

　　document_hierarchy_section∷＝document_hierarchy_section_signature section_size

　　        compressed(subtree|compressed_subtree)

　　subtree  ∷＝node

　　        注意：子树定义了未经压缩的XML子树的结构。

　　node    ∷＝node_size node_type(element_node|text_node|

　　        comment_node|node_locator)

　　注意：节点大小包括节点以及在同一数据包中已编码的其后裔节点的大小。

　　node_type∷＝(element_node_signature element_flag)|

　　      ((text_node_signature|comment_node_signature|

　　      locator_node signature)#x0)

　　element_node_signature  ∷＝#x3

　　text_node_signature      ∷＝#x5

　　comment_node_signature∷＝#x9

　　locatore_node_signature  ∷＝#xC

　　element_flag∷＝has_attributes|has_children|has_attributes_and_children

　　has attributes    ∷＝0x1

　　has children      ∷＝0x2

　　has_attributes_and_children∷＝0x3

　　element_node    ∷＝element_name_code[attributes][child_node*]

　　child nodes     ∷＝node

　　attributes∷＝index_of_starting_attribute_name_value_pair

　　        number_of_attributes

　　number_of_attributes    ∷＝variable_length_natural_number

　　text_locator    ∷＝string_locator

　　comment_node    ∷＝text_locator
        <!-- SIPO <DP n="30"> -->
        <dp n="d30"/>
　　node_locator    ∷＝packet_number

　　文本数据包

　　text_body∷＝compressed(encoded_text|compressed_encoded_text)

　　encoded_text∷＝(0x00 encoded_value*)|(next_packet_number UTF8_string

　　)

　　注意：如果next_packet_number为零，文本数据包的第一个字符串可以是长
字符串的最后的片段。如果next_packet_number是非零，整个文本数据包都包含字
符串的单个片段。

　　next_packet_number    ∷＝variable_length_natural_number

　　命令数据包

　　command_body  ∷＝command path packet_number_of_subtree

　　注意：要添加的子树以指定的数据包号码在结构数据包中定义。command∷＝
insert_command|append_command

　　insert command  ∷＝#x01

　　append_command∷＝#x02

　　path    ∷＝URI_reference

　　URI-reference    ∷＝UTFS_string

Claims

1.一种用于传达层次型表达式描述的文档的结构的至少一部分的方法，所说的方法包括下面的步骤：

标识所说的文档的所说的表达式；

将所说的数据包形成通信流，其中，所说的链接保持了所说的数据包内的所说的表达式。

2.根据权利要求1所述的一种方法，进一步包括下面的步骤：

接收所说的流；

对来自所说的流的所说的数据包进行解码以标识所说的链接；

使用所说的链接为不以所说的流的一个数据包分组的所说的表达式的那些部分重建所说的表达式。

3.根据权利要求1或2所述的一种方法，其特征在于，所说的对应的组件至少包括所说的文档的一个结构组件和一个内容组件。

4.一种用于传达层次型表达式描述的文档的结构的至少一部分的方法，所说的方法包括下面的步骤：

至少标识所说的表达式的一部分并将所说的部分分组到预先确定的大小的至少一个数据包；以及

所说的表达式的所说的部分的任何一个或多个不在一个所说的数据包内，定义了一个从所说的一个数据包到至少另一个将所说的非适合部分分组到其中的所说的数据包的至少一个链接，所说的链接保持了所说的数据包中的所说的文档的层次型结构。

5.根据权利要求1到4中任何一个权利要求所述的方法，其特征在于，所说的层次型表达式包括一个树表达式。

6.根据权利要求1到5中任何一个权利要求的方法，其特征在于，所说的文档包括XML文档。

7.根据权利要求1到6中任何一个权利要求所述的方法，其特征在于，所说的预先确定的大小是一个预先确定的最大大小。

8.一种促进对XML文档的结构进行访问的方法，所说的方法包括下面的步骤：

标识所说的文档的层次型表达式；

9.一种对XML文档进行编码的方法，所说的方法包括下面的步骤：

检查所说的XML文档以标识构成所说的XML文档的一部分的每个数据类型；

标识其有对应的特殊编码格式的所说的数据类型的第一个集；

用对应的特殊编码格式对具有所说的第一个集中的数据类型的所说的XML文档的每一部分进行第一次编码；

用对应于所说的其余部分的数据类型的默认编码格式对所说的XML文档的每一其余部分进行第二次编码；

用对应的特殊编码格式形成至少引用所说的第一个集中的每一个所说的数据类型的信息的表达式；以及

将所说的表达式和所说的编码部分作为所说的XML文档的编码形式关联。

10.根据权利要求9所述的方法，其特征在于，所说的编码单独对所说的XML文档的结构和内容部分进行编码，并且所说的表达式保留在所说的XML文档的编码形式的标头部分。

11.根据权利要求10所述的方法，其特征在于，所说的表达式作为一个表保留在所说的标头部分。

12.根据权利要求10所述的方法，其特征在于，所说的单独已编码的部分包括至少一个位流的数据包。

13.根据权利要求9所述的方法，其特征在于，所说的第一次编码包括检查所说的特殊数据类型和所说的对应的部分，确定要应用到所说的部分的其中一个所说的编码格式。

14.根据权利要求9所述的方法，其特征在于，所说的编码包括选择对应于所说的部分的数据类型的许多所说的编码格式中的一个并用所说的选择的编码格式对所说的部分进行编码。

15.一种对已编码的XML文档进行解码的方法，所说的方法包括下面的步骤：

检查所说的已编码的XML文档以标识与构成所说的XML文档的一部分的每一个数据类型关联的编码格式；以及

使用补充对对应的数据类型进行编码的编码格式的解码器对每一个所说的部分进行解码。

16.根据权利要求15所述的方法，其特征在于，所说的已编码的XML文档包括所说的XML文档的单独已编码的结构部分和内容部分，所说的检查包括从至少一个结构部分标识将所说的XML文档的编码部分与对应的编码格式关联的表达式。

17.根据权利要求16所述的方法，其特征在于，所说的编码XML文档是作为许多数据包构成的，所说的表达式是在至少一个所说的数据包的标头内构成的。

18.根据权利要求17所述的方法，其特征在于，所说的表达式包括一个表。

19.根据权利要求16到18中任何一个权利要求所述的方法，其特征在于，所说的表达式包括一个URI。

20.根据权利要求16所述的方法，其特征在于，所说的表达式至少涉及一组具有对应的解码格式的特殊数据类型。

21.根据权利要求15所述的方法，其特征在于，如果没有解码器可用来对所说的编码XML文档的一部分进行解码，所说的方法包括忽略所说的部分。

22.分组的位流是使用权利要求1到14中任何一个权利要求的方法构成的。

23.一种用于传达层次型表达式描述的文档的结构的至少一部分的装置，所说的装置包括：

用于标识所说的文档的所说的表达式的装置；

用于将所说的表达式分组为许多数据包的装置，所说的数据包具有预先确定的大小，所说的分组包括在一对所说的数据包之间至少创建一个链接，所说的链接表示所说的表达式的对应的组件之间的互连；以及

用于将所说的数据包形成通信流的装置，其特征在于，所说的链接保持了所说的数据包内的所说的表达式。

24.用于对XML文档进行编码的装置，所说的装置包括：

用于检查所说的XML文档以标识构成所说的XML文档的一部分的每个数据类型的装置；

用于标识其有对应的特殊编码格式的所说的数据类型的第一个集的装置；

用于用对应的特殊编码格式对具有所说的第一个集中的数据类型的所说的XML文档的每一部分进行第一次已编码的装置；

用于用对应于所说的其余部分的数据类型的默认编码格式对所说的XML文档的每一其余部分进行第二次已编码的装置；

用于用对应的特殊编码格式形成至少引用所说的第一个集中的每一个所说的数据类型的信息的表达式的装置；以及

用于将所说的表达式和所说的编码部分作为所说的XML文档的编码形式关联的装置。

25.在上面记录了程序的计算机可读的介质，其特征在于，程序被配置为使计算机执行一个过程，以便传达层次型表达式描述的文档的结构的至少一部分，所说的程序包括下面的步骤：

标识所说的文档的所说的表达式；

26.根据权利要求25所述的计算机可读的介质进一步包括下面的步骤：

接收所说的流；

27.根据权利要求25或26所述的一种计算机可读的介质，其特征在于，所说的对应的组件至少包括所说的文档的一个结构组件和一个内容组件。

28.在上面记录了程序的计算机可读的介质，其特征在于，程序被配置为使计算机执行该过程，以便传达层次型表达式描述的文档的结构的至少一部分，所说的程序包括下面的步骤：

29.根据权利要求25到28中任何一个权利要求所述的计算机可读的介质，其特征在于，所说的层次型表达式包括一个树表达式。

30.根据权利要求25到29中任何一个权利要求的计算机可读的介质，其特征在于，所说的文档包括XML文档。

31.根据权利要求25到30中任何一个权利要求所述的计算机可读的介质，其特征在于，所说的预先确定的大小是一个预先确定的最大大小。

32.在上面记录了程序的计算机可读的介质，其特征在于，程序被配置为使计算机执行一个过程，以促进对XML文档的结构进行访问，所说的程序包括下面的步骤：

标识所说的文档的层次型表达式；

33.在上面记录了程序的计算机可读的介质，其特征在于，程序被配置为使计算机执行一个过程，以对XML文档进行编码，所说的程序包括下面的步骤：

34.根据权利要求33所述的计算机可读的介质，其特征在于，所说的编码单独对所说的XML文档的结构和内容部分进行编码，并且所说的表达式保留在所说的XML文档的编码形式的标头部分。

35.根据权利要求34所述的计算机可读的介质，其特征在于，所说的表达式作为一个表保留在所说的标头部分。

36.根据权利要求34所述的计算机可读的介质，其特征在于，所说的单独已编码的部分包括至少一个位流的数据包。

37.根据权利要求33所述的计算机可读的介质，其特征在于，所说的第一次编码包括检查所说的特殊数据类型和所说的对应的部分，确定要应用到所说的部分的其中一个所说的编码格式。

38.根据权利要求33所述的计算机可读的介质，其特征在于，所说的编码包括选择对应于所说的部分的数据类型的许多所说的编码格式中的一个并用所说的选择的编码格式对所说的部分进行编码。

39.在上面记录了程序的计算机可读的介质，其特征在于，程序被配置为使计算机执行一个过程，以对已编码的XML文档进行解码，所说的程序包括下面的步骤：

40.根据权利要求39所述的计算机可读的介质，其特征在于，所说的已编码的XML文档包括所说的XML文档的单独已编码的结构部分和内容部分，所说的检查包括从至少一个结构部分标识将所说的XML文档的编码部分与对应的编码格式关联的表达式。

41.根据权利要求40所述的计算机可读的介质，其特征在于，所说的编码XML文档是作为许多数据包构成的，所说的表达式是在至少一个所说的数据包的标头内构成的。

42.根据权利要求41所述的计算机可读的介质，其特征在于，所说的表达式包括一个表。

43.根据权利要求40到42中任何一个权利要求所述的计算机可读的介质，其特征在于，所说的表达式包括一个URI。

44.根据权利要求43所述的计算机可读的介质，其特征在于，所说的表达式至少涉及一组具有对应的解码格式的特殊数据类型。

45.根据权利要求44所述的计算机可读的介质，其特征在于，如果没有解码器可用来对所说的编码XML文档的一部分进行解码，所说的计算机可读的介质包括忽略所说的部分。

46.一种用于传达层次型表达式描述的文档的结构的至少一部分的装置，所说的装置包括：

用于标识所说的文档的所说的表达式的标识装置；

用于将所说的表达式分组为许多数据包的分组装置装置，所说的数据包具有预先确定的大小，所说的分组包括在一对所说的数据包之间至少创建一个链接，所说的链接表示所说的表达式的对应的组件之间的互连；以及

用于将所说的数据包形成通信流的形成装置，其中，所说的链接保持了所说的数据包内的所说的表达式。

47.用于对XML文档进行编码的装置，所说的装置包括：

用于检查所说的XML文档以标识构成所说的XML文档的一部分的每个数据类型的检查装置；

用于标识其有对应的特殊编码格式的所说的数据类型的第一个集的标识装置；

用对应的特殊编码格式对具有所说的第一个集中的数据类型的所说的XML文档的每一部分进行编码的第一编码装置；

用对应于所说的其余部分的数据类型的默认编码格式对所说的XML文档的每一其余部分进行编码的第二编码装置；

用于用对应的特殊编码格式形成至少引用所说的第一个集中的每一个所说的数据类型的信息的表达式的形成装置；以及

用于将所说的表达式和所说的编码部分作为所说的XML文档的编码形式关联的关联装置。

48.对层次型表达式描述的文档进行编码的方法，大体上如此处参考图形所描述的那样。

49.对集成了层次型表达式的分组流进行解码的方法，大体上如此处参考图形所描述的那样。

50.对使用层次型表达式描述的文档进行传达的方法，大体上如此处参考图形所描述的那样。

51.用于执行权利要求48到50中的任何一个权利要求的方法的装置。

52.在上面记录了计算机程序的计算机可读的介质，用于执行权利要求48到50中的任何一个权利要求的方法。