XML 字符串元素内部与独立元素
XML inside an string element vs independent elements
这个request/response结构的概念和技术缺点是什么:
A)
<xs:element name="OrderRequest">
<xs:complexType>
<xs:sequence>
<xs:element name="OrderID" type="xs:integer"/>
<xs:element name="OrderType" type="xs:integer"/>
<xsd:element name='OrderAttributes' type='xsd:string'/>
</xs:sequence>
</xs:complexType>
</xs:element>
其中 OrderAttributes
元素将包含以下 XML 结构中的字符串:
<OrderName> xy </OrderName>
<OrderDate> xy </OrderDate>
<OrderDetails> xy </OrderDetails>
....lots of other attributes
与此 request/response 结构相比
B)
<xs:element name="OrderRequest">
<xs:complexType>
<xs:sequence>
<xs:element name="OrderID" type="xs:integer"/>
<xs:element name="OrderType" type="xs:integer"/>
<xsd:element name="OrderAttributes">
<xs:complexType>
<xs:sequence>
<xs:element name="OrderName" type="xs:string"/>
<xs:element name="OrderDate" type="xs:date"/>
<xs:element name="OrderDetails" type="xs:string"/>
....lots of other attributes
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
我需要为订单处理设计网络服务接口,我正在考虑上面提到的两种选择。
版本 A 更通用,因此当 OrderAttributes
结构以任何方式发生变化时,无需更改接口。
但是无法进行架构验证。
我的问题是,与版本 B 相比还有哪些其他缺点。我是分析师,不是程序员,所以我不能说,如果对解析请求、从合同生成代码等有一些影响...
首先请注意,您一般使用 属性 来指代 属性 在 XML,其中 attribute 指的是不同于 element[=40= 的特定结构]:
<element attribute="attribute value">
<childElement>child element value</childElement>
</element>
然后,在进行设计时,您可能会考虑将哪些属性表示为 XML 属性,将哪些属性表示为 XML 元素。请参阅 XML attribute vs XML element 以帮助决定。
关于您的 A 与 B 提议的设计,请注意 A 根本不可行- 您不能在声明为具有 xs:string
内容的元素中包含未转义的标记,如您所示。此外,A 无论如何都需要进一步解析 OrderAttributes
内容,而 B 将利用 XML 解析器来处理OrderAttributes
内容。 (而且,正如您所说,B 也不会利用 XSD 验证。)
为了将来的扩展,请考虑使用 xs:any
, which supports various interpretations of wildcard contents via its processContents
attribute values of strict, lax, or skip.
这个request/response结构的概念和技术缺点是什么:
A)
<xs:element name="OrderRequest">
<xs:complexType>
<xs:sequence>
<xs:element name="OrderID" type="xs:integer"/>
<xs:element name="OrderType" type="xs:integer"/>
<xsd:element name='OrderAttributes' type='xsd:string'/>
</xs:sequence>
</xs:complexType>
</xs:element>
其中 OrderAttributes
元素将包含以下 XML 结构中的字符串:
<OrderName> xy </OrderName>
<OrderDate> xy </OrderDate>
<OrderDetails> xy </OrderDetails>
....lots of other attributes
与此 request/response 结构相比
B)
<xs:element name="OrderRequest">
<xs:complexType>
<xs:sequence>
<xs:element name="OrderID" type="xs:integer"/>
<xs:element name="OrderType" type="xs:integer"/>
<xsd:element name="OrderAttributes">
<xs:complexType>
<xs:sequence>
<xs:element name="OrderName" type="xs:string"/>
<xs:element name="OrderDate" type="xs:date"/>
<xs:element name="OrderDetails" type="xs:string"/>
....lots of other attributes
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
我需要为订单处理设计网络服务接口,我正在考虑上面提到的两种选择。
版本 A 更通用,因此当 OrderAttributes
结构以任何方式发生变化时,无需更改接口。
但是无法进行架构验证。
我的问题是,与版本 B 相比还有哪些其他缺点。我是分析师,不是程序员,所以我不能说,如果对解析请求、从合同生成代码等有一些影响...
首先请注意,您一般使用 属性 来指代 属性 在 XML,其中 attribute 指的是不同于 element[=40= 的特定结构]:
<element attribute="attribute value">
<childElement>child element value</childElement>
</element>
然后,在进行设计时,您可能会考虑将哪些属性表示为 XML 属性,将哪些属性表示为 XML 元素。请参阅 XML attribute vs XML element 以帮助决定。
关于您的 A 与 B 提议的设计,请注意 A 根本不可行- 您不能在声明为具有 xs:string
内容的元素中包含未转义的标记,如您所示。此外,A 无论如何都需要进一步解析 OrderAttributes
内容,而 B 将利用 XML 解析器来处理OrderAttributes
内容。 (而且,正如您所说,B 也不会利用 XSD 验证。)
为了将来的扩展,请考虑使用 xs:any
, which supports various interpretations of wildcard contents via its processContents
attribute values of strict, lax, or skip.