此请求/响应结构的概念和技术缺点是什么:
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
与此请求/响应结构相比
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>
我需要设计用于订单处理的 Web 服务接口(interface),并且我正在考虑上述两种替代方案。
版本 A 更加通用,因此当 OrderAttributes
结构以任何方式发生变化时,接口(interface)不需要更改。
但是模式验证是不可能的。
我的问题是,与版本 B 相比,还有哪些其他缺点。我是分析师,不是程序员,所以我不能说,是否对解析请求、从合约生成代码等有一些影响......
最佳答案
首先请注意,在 XML 中通用使用“属性”一词来指代属性可能会造成混淆,其中“属性”指的是与“元素”不同的特定构造:
<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 验证。)
对于 future 的扩展,请考虑使用 xs:any
,它通过 strict, lax, or skip 的 processContents
属性值支持通配符内容的各种解释。 。
关于java - 字符串元素内的 XML 与独立元素,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/37092234/