SOAP标准规范专业资料.doc

SOAP:简朴对象访问合同(-1-1)摘要 SOAP是用在分散或分布环境中互换信息简朴合同，它是一种基于XML合同，涉及三个某些：封装定义了一种描述消息中包括什么内容以及如何解决它们框架，编码规则用于表达应用程序定义数据类型实例，此外尚有一种表达远程过程调用和应答协定。SOAP被设计为可以与各种其他合同结合使用；但这篇文章仅描述如何将SOAP和HTTP及HTTP扩展框架相结合。 目录1. 简介 1.1 设计目的 1.2 符号协定 1.3 SOAP消息举例 2. SOAP消息互换模型 3. 与XML关系 4. SOAP封装 4.1.1 SOAP encodingStyle属性 4.1.2 封装版本模型 4.2 SOAP头 4.2.1 使用SOAP头属性 4.2.2 SOAP actor属性 4.2.3 SOAP mustUnderstand属性 4.3 SOAP体 4.3.1 SOAP头和体关系 4.4 SOAP 错误 4.4.1 SOAP错误代码 5. SOAP编码 5.1 XML编码类型规则 5.2 简朴类型 5.2.1 字符串 5.2.2 枚举 5.2.3 字符数组 5.3 多态 Accessor 5.4 复合类型 5.4.1 复合值和对值引用 5.4.2 数组 5.4.2.1 PartiallyTransmitted Arrays 5.4.2.2 稀疏数组 5.4.3 普通复合类型 5.5 缺省值 5.6 SOAP root属性 6. 在HTTP中使用SOAP 6.1 SOAP HTTP祈求 6.1.1 HTTP头中SOAPAction域 6.2 SOAP HTTP应答 6.3 HTTP扩展框架 6.4 SOAP HTTP举例 7. 用SOAP表达RPC 7.1 RPC和SOAP体 7.2 RPC和SOAP头 8. 安全考虑 9. 参照文献 A. SOAP封装举例 A.1 祈求编码举例 A.2 应答编码举例 1. 简介SOAP以XML形式提供了一种简朴、轻量用于在分散或分布环境中互换构造化和类型化信息机制。SOAP自身并没有定义任何应用程序语义，如编程模型或特定语义实现；事实上它通过提供一种有原则组件包模型和在模块中编码数据机制，定义了一种简朴表达应用程序语义机制。这使SOAP可以被用于从消息传递到RPC各种系统。 SOAP涉及三个某些 SOAP封装（见第4节）构造定义了一种整体框架用来表达消息中包括什么内容，谁来解决这些内容以及这些内容是可选或是必须。 SOAP编码规则（见第5节）定义了用以互换应用程序定义数据类型实例一系列机制。 SOAP RPC表达（见第7节）定义了一种用来表达远程过程调用和应答协定。 虽然这三个某些都作为SOAP一某些一起描述，但它们在功能上是相交。特别，封装和编码规则是在不同名域中定义，这种模块性定义办法增长了简朴性。 在SOAP封装，SOAP编码规则和SOAP RPC协定之外，这个规范还定义了两个合同绑定，描述了在有或没有HTTP扩展框架6状况下，SOAP消息如何包括在HTTP消息5中被传送。1.1 设计目的 SOAP重要设计目的是简朴性和可扩展性，这意味着老式消息系统和分布对象系统某些性质不是SOAP规范一某些。这些性质涉及： 分布式碎片收集 成批传送消息 对象引用（规定分布式碎片收集） 激活机制（规定对象引用） 1.2 符号商定 这篇文章中核心字 MUST，MUST NOT，REQUIRED，SHALL，SHALL NOT,SHOULD，SHOULD NOT，RECOMMENDED，MAY，和OPTIONAL解释在RFC-2119 2中。 这篇文章中用到名域前缀 SOAP-ENV 和 SOAP-ENC分别与和关联。 整篇文档中，名域前缀“xsi”被假定为与URI Schema规范11定义）相连。类似，名域前缀”xsd“被假定为与URI （在 10中定义）相连。名域前缀”tns“用来表达任意名域。所有其他名域前缀都只是例子。 名域URI基本形式”someURI“表达某些依赖于应用程序或上下文URI4。这个规范用扩展BNF（在RFC26165 描述）描述某些构造。 1.3 SOAP消息举例 在这个例子中，GetLastTradePrice SOAP 祈求被发往 StockQuote服务。这个祈求携带一种字符串参数和ticker符号，在SOAP应答中返回一种浮点数。XML名域用来区别SOAP标志符和应用程序特定标志符。这个例子阐明了在第6节中定义HTTP绑定。如果SOAP中管理XML负载规则完全独立于HTTP是没故意义，由于事实上该负载是由HTTP携带。在Appendix A中有更多例子。 例1 在HTTP祈求中嵌入SOAP消息 POST /StockQuote HTTP/1.1Host：Content-Type：text/xml；charset=utf-8Content-Length：nnnnSOAPAction：Some-URI DIS 下面是一条应答消息，涉及HTTP消息，SOAP消息是其详细内容： 例2 在HTTP应答中嵌入SOAP消息 HTTP/1.1 200 OKContent-Type：text/xml；charset=utf-8Content-Length：nnnn 34.5 2. SOAP消息互换模型 SOAP消息从发送方到接受方是单向传送，但正如上面显示，SOAP消息经常以祈求/应答方式实现。 SOAP实现可以通过开发特定网络系统特性来优化。例如，HTTP绑定（见第6节）使SOAP应答消息以HTTP应答方式传播，并使用同一种连接返回祈求。不论SOAP被绑定到哪个合同，SOAP消息采用所谓”消息途径“发送，这使在终节点之外中间节点可以解决消息。 一种接受SOAP消息SOAP应用程序必要按顺序执行如下动作来解决消息： 辨认应用程序想要SOAP消息所有某些 （见4.2.2节） 检查应用程序与否支持第一步中辨认消息中所有必须某些并解决它。如果不支持，则丢弃消息（见4.4节）。在不影响解决成果状况下，解决器也许忽视第一步中辨认出可选某些。 如果这个SOAP应用程序不是这个消息最后目地，则在转发消息之前删除第一步中辨认出来所有某些。 为了对的解决一条消息或者消息一某些，SOAP解决器需要理解：所用互换方式（单向，祈求/应答，多路发送等等），这种方式下接受者任务，RPC机制（如果有话）使用（如第7节中所述），数据体现办法或编码，尚有其他必须语义。 尽管属性例如SOAP encodingstyle（见4.1.1节）可以用于描述一种消息某些方面，但这个规范并不强制所有接受方也必要有同样属性并取同样属性值。举个例子，某一特定应用也许懂得一种元素表达一条遵循第7节商定RPC祈求，但是此外某些应用也许以为指向该元素所有消息都用单向传播，而不是类似第7节祈求应答模式。（译者注：交互双方SOAP消息并不一定要遵循同样格式设定，而只需要以一种双方可理解格式互换信息就可以了） 3. 与XML关系所有SOAP消息都使用XML形式编码（更多关于XML信息请见7）一种SOAP应用程序产生消息中，所有由SOAP定义元素和属性中必要涉及对的名域。SOAP应用程序必要可以解决它接受到消息中SOAP名域（见4.4节），并且它可以解决没有SOAP名域SOAP消息，就象它们有对的名域同样。SOAP定义了两个名域（更多关于XML名域信息请见8）SOAP封装名域标志符是SOAP编码规则名域标志符是SOAP消息中不能包括文档类型声明，也不能涉及消息解决指令。7SOAP使用ID类型id属性来指定一种元素唯一标志符，同步该属性是局部和无需校验。SOAP使用uri-reference类型href属性指定对这个值引用，同步该属性是局部和无需校验。这样就遵从了XML规范7，XML Schema规范11和XML连接语言规范9风格。除了SOAP mustUnderstand 属性(见4.2.3节）和SOAP actor属性(见4.2.2节）之外，普通容许属性和它们值出当前XML文档实例或Schema中（两者效果相似）。也就是说，在DTD或Schema中声明一种缺省值或固定值和在XML文档实例中设立它值在语义上相似。4. SOAP封装SOAP消息是一种XML文档，涉及一种必须SOAP封装，一种可选SOAP头和一种必须SOAP体。在这篇规范剩余某些中，提到SOAP消息时就是指这个XML文档。这一节中定义元素和属性名域标志符为：。一种SOAP消息涉及如下某些：在表达这个消息XML文档中，封装是顶层元素。 应用SOAP互换信息各方是分散且没有预先协定，SOAP头提供了向SOAP消息中添加关于这条SOAP消息某些要素(feature)机制。SOAP定义了少量属性用来表白这项要素（feature）与否可选以及由谁来解决。（见4.2节） SOAP体是包括消息最后接受者想要信息容器（见4.3节）。SOAP为SOAP体定义了一个Fault元素用来报告错误信息。 语法规则如下所示： 封装 元素名是 Envelope 在SOAP消息中必要浮现。 可以包括名域声明和附加属性。如果包括附加属性，这些属性必要限定名域。类似，Envelope可以包括附加子元素，这些也必要限定名域且跟在SOAP体元素之后。 SOAP头 （见4.2节） 元素名是Header 在SOAP消息中也许浮现。如果浮现话，必要是SOAP 封装元素第一种直接子元素。 SOAP头可以包括各种条目，每个都是SOAP头元素直接子元素。所有SOAP头直接子元素都必要限定名域。 SOAP体 （见4.3节） 元素名是Body 在SOAP消息中必要浮现且必要是SOAP封装元素直接子元素。它必要直接跟在SOAP头元素（如果有话）之后。否则它必要是SOAP封装元素第一种直接子元素。 SOAP体可以涉及各种条目，每个条目必要是SOAP体元素直接子元素。SOAP体元素直接子元素可以限定名域。SOAP定义了SOAP Fault元素来表达错误信息。(见4.4节). 4.1.1 SOAP encodingStyle 属性EncodingStyle全局属性用来表达SOAP消息序列化规则。这个属性可以在任何元素中出现，作用范畴与名域声明作用范畴很相似，为这个元素内容和它所有无重载此属性子元素。SOAP消息没有定义缺省编码。属性值是一种或各种URI顺序列表，每个URI拟定了一种或各种序列化规则，用来不同程度反序列化SOAP消息，举例如下：第5节中定义序列化规则由URI确定。使用这个特定序列化规则消息应当用encodingStyle属性阐明这一点。此外，所有以开头URI中序列化规则与第5节中定义SOAP编码规则相一致。一种零长度URI（）明确显示所含元素没有任何编码形式。这可以用来取消上一级元素所有编码声明。4.1.2 封装版本模型SOAP没有定义常规基于主版本号和辅版本号版本形式。SOAP消息必要有一种封装元素与名域VersionMismatch 错误信息（见4.4节）。4.2 SOAP头SOAP为互相通信团队之间提供了一种很灵活机制：在不必预先协定状况下，以分散但原则方式扩展消息。可以在SOAP头中添加条目实现这种扩展，典型例子有认证，事务管理，支付等等。头元素编码为SOAP封装元素第一种直接子元素。头元素所有直接子元素称作条目。条目编码规则如下：一种条目有它完整元素名（涉及名域URI和局部名）拟定。SOAP头直接子元素必要有名域限制。 SOAP encodingStyle属性可以用来批示条目所用编码形式（见4.1.1节） SOAP mustUnderstand属性（见4.2.3节）和SOAP actor属性（见4.2.2节）可以用来批示如何解决这个条目以及由谁来解决。（见4.2.1节） 4.2.1 使用头属性这一节中定义SOAP头属性拟定了SOAP消息接受者应当如何按第2节中所述方式解决消息。产生SOAP消息SOAP应用程序，应当仅仅在SOAP头元素直接子元素中使用这些SOAP头属性。SOAP消息接受者必要忽视所有不在SOAP头元素直接子元素中SOAP头属性。下面例子是一种SOAP头，涉及一种元素标志符Transaction，mustUnderstand取值为1和数值5。这应当以如下方式编码： 5 4.2.2 SOAP actor属性一种SOAP消息从始节点到终节点过程中，也许沿着消息途径通过一系列SOAP中间节点。一种SOAP中间节点是一种可以接受转发SOAP消息应用程序。中间节点和终节点由URI区分。也许SOAP消息终节点并不需要所有某些，而在消息途径上一种和几种中间节点也许需要这些内容。头元素接受者扮演角色类似于一种过滤器，防止这些只发给本接受者消息某些扩散到其他节点。即一种头元素接受者必要不转发这些头元素到SOAP消息途径上下一种应用程序。同样，接受者也许插入一种相似头元素。SOAP actor全局属性可以用于批示头元素接受者。SOAP actor属性值是一种URI。URI 省略SOAP actor属性表达接受者是SOAP消息终节点。如果这个属性要生效，它必要出当前SOAP消息实例中。（见第3节和4.2.1节）4.2.3 SOAP mustUnderstand属性SOAP mustUnderstand全局属性用来批示接受者在解决消息时这个条目与否必要解决。条目接受者由SOAP actor属性定义（见4.2.2节）。MustUnderstand属性值是1 或 0。缺少SOAP mustUnderstand属性在语义上等同于它值为0。如果一种头元素SOAP mustUnderstand属性值是1,那么条目接受者必要或者遵守语义（如以元素全名传送）并按照语义对的解决，或者放弃解决消息（见4.4节）。SOAP mustUnderstand 属性考虑了消息演变精确性（robust evolution）。必要假定包括SOAP mustUnderstand属性且值为1元素以某种方式修改了它们父元素或同层元素语义。以这种方式连接元素保证了语义上变化不会被那些不能完全理解它接受者忽视。如果这个属性要生效，它必要出当前SOAP消息实例中。（见第3节和4.2.1节）4.3 SOAP体SOAP体元素提供了一种简朴机制，使消息最后接受者能互换必要信息。使用体元素典型状况涉及配备RPC祈求和错误报告。体元素编码为SOAP封装元素直接子元素。如果已有一种头元素，那么体元素必要紧跟在头元素之后，否则它必要是SOAP封装元素第一种直接子元素。体元素所有直接子元素称作体条目，每个体条目在SOAP体元素中编码为一种独立元素。条目编码规则如下：一种条目由它元素全名（涉及名域URI和局部名）拟定。SOAP体元素直接子元素也许是名域限制。 SOAP encodingStyle属性也许用来批示条目（见4.1.1节）编码方式。 SOAP定义了一种Fault条目用来报告错误信息。（见4.4节）4.3.1 SOAP头和体关系虽然头和体定义为独立元素，它们事实上是关于系。体条目和头条目关系如下：体条目在语义上等同于actor属性为缺省值且mustUnderstand属性值为1头条目。不使用actor属性则表达缺省actor。（见4.2.2节）4.4 SOAP错误SOAP错误元素用于在SOAP消息中携带错误和（或）状态信息。如果有SOAP错误元素，它必须以以体条目方式浮现，并且在一种体元素中最多余现一次。SOAP错误元素定义了如下四个子元素： faultcode faultcode元素给软件提供了一种辨认此错误算法机制。SOAP错误元素必要有faultcode子元素，并且它值必要是一种合法名（在8节定义）。SOAP定义某些SOAP faultcode描述基本SOAP错误（见4.4.1节）。 faultstring faultstring元素提供了一种错误解释，而不是为了软件解决。faultstring元素类似于HTTP中定义(见5，第6.1节）Reason-Phrase。SOAP错误元素必要有faultstring子元素，并且它应当提供某些错误本质解释信息。 faultactor faultactor元素提供了在消息途径上是谁导致了错误发生信息（见第2节）。它类似于SOAP actor属性（见4.2.2节），只是SOAP actor指是头条目目地，faultactor指是错误来源。faultactor属性值是用来区别错误来源URI。不是SOAP消息最后目地应用程序必要在SOAP Fault元素中包括faultactor元素。消息最后目地可以使用faultactor元素明确批示是它产生了这个错误（参见下面detail元素） detail detail元素用来携带与Body元素关于应用程序所要错误信息。如果Body元素内容不能被成功解决，则必要包括detail子元素。它不能用来携带属于头条目错误信息。头条目详细出错信息必要由头条目携带。Fault元素中没有detail元素表达这个错误与Body元素解决无关。在有错误时候，这可以用来区别Body元素有无被对的解决。detail元素所有直接子元素称作detail条目，并且每个detail条目在detail元素中编码为独立元素。detail条目编码规则如下（参见例10）： 一种detail条目由它元素全名（涉及名域URI和局部名）拟定。SOAP体元素直接子元素也许是名域限制。 SOAP encodingStyle属性也许用来批示detail条目（见4.1.1节）编码方式。 也可以有其他Fault子元素，只要它们是名域限制。4.4.1 SOAP 错误代码在描述这个规范中定义错误时，这一节中定义Faultcode值必要用在faultcode元素中。这些faultcode值得名域标志符为缺省SOAP faultcode值以可扩展方式定义，容许定义新SOAP faultcode值，并与既有faultcode值向后兼容。使用机制类似于HTTP中定义1xx，2xx，3xx等基本状态类（见5第10节），但是，它们定义为XML合法名（见 8 第3节 ），而不是整数。字符.（点）作为faultcode分隔符，点左边错误代码比右边错误代码更为普通。如：Client.Authentication这篇文档中定义faultcode值是：名称 含义 VersionMismatch 解决方发现SOAP封装元素有不合法名域（见4.1.2节） MustUnderstand 解决方不理解或者不服从一种包括值为1mustUnderstand属性 SOAP头元素直接子元素。（见4.2.3节） Client Client错误类表达消息格式错误或者不包括恰当对的信息。例如，消息也许缺少对的认证和支付信息。普通地，它表达消息不能不作修改就重发。参见4.4节SOAP Fault detail子元素描述。 Server Server错误类表达由于消息解决过程而不是消息内容自身使得消息消息不能对的解决。例如，解决消息时也许要与其他解决器通信，但它没有响应。这个消息也许在迟一点时间解决成功。 SOAP Fault子元素详细信息参见4.4节 5. SOAP编码SOAP编码格式基于一种简朴类型系统，概括了程序语言，数据库和半构造化数据等类型系统共同特性。一种类型或者是一种简朴（标量）类型，或者是由几种某些组合而成复合类型，其中每个某些均有自己类型。如下将详细描述这些类型。这一节定义了类型化对象序列化规则。它分两个层次。一方面，给定一种与类型系统符号系统一致Schema（译者注：这里schema不是符合XML语法schema，而仅仅表达广义用于表达消息结构定义方式），就构造了XML语法Schema。然后，给定一种类型系统Schema和与这个Schema一致特定值，就构造了一种XML文档实例。反之，给定一种依照这些规则产生XML文档实例和初始Schema，就可以构造初始值一种副本。这一节中定义元素和属性名域标志符为勉励使用这一节中描述数据模型和编码方式，但也可以在SOAP中使用其她数据模型和编码方式。（见4.1.1节）5.1 XML中编码类型规则XML容许非常灵活数据编码方式。SOAP定义了一种较小规则集合。这一节在总层次上定义了这些编码规则，下一节将描述特定类型编码规则细节。这一节定义编码规则可以与第7节中所述RPC调用和应答映射结合使用。下面术语用来描述编码规则:一种value是一种字符串，类型（数字，日期，枚举等等）名或是几种简朴值组合。所有值均有特定类型。 一种simple value没有名某些， 如特定字符串，整数，枚举值等等。 一种compound value是有关值结合，如定单，股票报表，街道地址等等。 在compound value中，每个有关值都潜在以名，序数或这两者来区别。这叫作accessor。复合值例子有定单和股票报表等等。数组也是复合值。在复合值中，各种accessor有相似名是容许，例如RDF就是这样做。 一种array是一种复合值，成员值按照在数组中位置互相区别。 一种struct也是一种复合值，成员值之间唯一区别是accessor名，accessor名互不相似。 一种simple type是简朴值类，如叫做string integer类，尚有枚举类等等。 一种compound type是复合值类。复合类型例子有定单类，它们有相似accessor名（shipTo，totalCost等），但也许会有不同值（也许后来被设立为拟定值）。 在复合类型中，如果类型内accessor名互不相似，但是也许与其她类型中accessor名相似，即，accessor名加上类型名形成一种唯一标志符，这个名叫作局部范畴名。如果名是直接或间接基于URI一某些，那么不论它出当前什么类型中，这个名自身就可以唯一标志这个accessor，这样名叫作全局范畴名。 给定了schema中有关值序列化信息，就也许拟定某些值只与某个accessor一种实例关于。其他状况下则无法拟定。当且仅当一种accessor引用一种值，这个值才干被视为single-reference，如果有不止一种accessor引用它，那么就将它视为multi-reference。注意，也许一种拟定值在一种schema中是single-reference，而在另一种schema中是multi-reference。 在语句构成上，一种元素也许是independent 或 embedded。一种独立元素指浮现在序列化最顶层任何元素。所有其他元素都是嵌入元素。 虽然用xsi:type属性可以使值构造和类型变为自描述，但是序列化规则容许值类型仅仅参照schema而定。这样schema也许使用XML Schema Part 1：Structures 10和XML Schema Part 2：Datatypes 11中描述符号系统，也也许使用其他符号系统。注意，虽然序列化规则可以用于除了数组和构造之外复合类型，但是许多schema仅仅包括数组和构造类型。序列化规则如下:所有值以元素内容形式表达。一种multi-reference值必要表达为一种独立元素内容，而一种single-reference值最佳不要这样表达（也可以这样表达）。 对于每个具备值元素，值类型时必要用下述三种方式之一描述：(a)所属元素实例有xsi:type属性 (b)所属元素是一种有SOAP-ENC:arrayType 属性（该属性也许是缺省）元素子元素，或者(c)所属元素名具备特定类型，类型可以由schema拟定。 一种简朴值表达为字符数据，即没有任何子元素。每个简朴值必要具备一种类型，这个类型或者是XML Schemas Specification，part 2 11有类型，或者具备源类型（参见5.2节）。 一种复合值编码成一种元素序列，每个accessor用一种嵌入元素表达，该元素元素名和accessor名一致。如果accessor名是局部于其所属类型，则该元素元素名不是合格，否则相应元素名是合格。(参见5.4节) 一种multi-reference简朴值或复合值编码成一种独立元素，这个元素包括一种局部无需校验属性，属性名为id，类型为ID（依照XML Specification 7）。值每个accessor相应一种空元素，该元素有一种局部，无需校验属性，属性名为href，类型为 uri-reference （依照XML Schema Specification 11），href属性值引用了相相应独立元素URI标志符。 字符串和字符数组表达为multi-reference简朴类型，但是特殊规则使它们在普通状况下能被更有效表达（参见5.2.1节和5.2.3节）。字符串和字符数组值accessor也许有一种名字为id，类型为ID（依照XML Specification 7）属性。如果这样，所有这个值所有其他accessor编码成一种空元素，这个元素有一种局部，无需校验属性，属性名为href，类型为 uri-reference （依照XML Schema Specification 11），href属性值引用了包括这个值元素URI标志符。 编码时容许一种值有各种引用，就像各种不同值有各种引用同样，但这仅在从上下文可以懂得这个XML文档实例含义没有变化时才可使用。 数组是复合值（参见5.4.2节）。SOAP数组定义为具备类型SOAP-ENC:Array或从它衍生类型.SOAP数组可以时一维或多维，它们成员以序数位置互相区别。一种数组值表达为反映这个数组一系列元素，数构成员按升序浮现。对多维数组来说，右边这一维变化最快。每个成员元素命名为一种独立元素。（见规则2）SOAP数组可以是single-reference 或multi-reference值，因而可以表达为嵌入元素或独立元素内容。SOAP数组必要包括一种SOAP-ENC:arrayType属性，它值指定了包括元素类型和数组维数。SOAP-ENC:arrayType属性值定义如下： arrayTypeValue = atype asize atype = QName *( rank ) rank = *( , ) asize = #length length = 1*DIGIT atype构造是被包括元素类型名，它表达为QName并且作为类型限制在XML元素声明type属性中浮现（这意味着被包括元素所有值都要与该类型一致，即在SOAP-ENC:arrayType中引用类型必要是每个数构成员类型或超类型）。在arrays of arrays or jagged arrays状况下，类型组件编码为innermost类型且在从第一层开始嵌套数组每一层中，类型名后都跟随一种rank构造。多维数组编码时从第一维起，每一维之间用逗号隔开。asize构造包括一种以逗号分隔列表，数值0，1或其他整数表达数组每一维长度。整数0表达没有指定详细大小，但是也许在检查数组实际成员大小后拟定。例如，一种5个成员整型数组arrayTypeValue值为int5，它atype值是int，asize值是5。同样，一种3个成员两维整型数组arrayTypeValue值为int,3，它atype值是int,，asize值是3。一种SOAP数构成员也许包括一种SOAP-ENC:offset属性表达这一项在整个数组中位置偏移值。这被用来批示一种某些储值数组（见5.4.2.1节）位置偏移值。同样，一种数组成员也许包括一种SOAP-ENC:position属性表达这一项在整个数组中位置，这被用来描述稀疏数组（见5.4.2.2节）成员。SOAP-ENC:offset 和SOAP-ENC:position属性值定义如下：arrayPoint = #length 偏移值和位置从0开始 NULL值或缺省值也许通过省略accssor元素来表达。NULL值也也许通过一种包括值为1xsi:null属性accssor元素来表达，其他依赖于应用程序属性和值也也许用来表达NULL值。 注意，规则2容许独立元素和数构成员名不同于值类型元素。5.2 简朴类型SOAP采用了XML Schema Part 2：Datatypes规范11Built-in datatypes节中所有类型作为简朴类型，涉及值和取值范畴。例如：类型 举例 int 58502 float 3979E+1 negativeInteger -32768 string Louis Satchmo Armstrong 在XML Schema规范中声明数据类型可以直接用在元素schema中，也可以使用从这些类型衍生新类型。一种schema和相应具备这些类型元素数据实例例子如下所示： 455.9-4