Question

此请求/响应结构的概念和技术缺点是什么：

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服务接口，我正在考虑上面提到的两个替代方案。

版本A更通用，因此当OrderAttributes结构以任何方式更改时，界面无需更改。

但架构验证是不可能的。

我的问题是，与版本B相比还有什么其他缺点。我是分析师，而不是程序员，所以我不能说，如果对解析请求有影响，从合同生成代码等......

Answer 1

首先请注意，您通常使用属性一词来引用属性可能会令人困惑，其中属性指的是与元素不同的特定构造：

<element attribute="attribute value">
    <childElement>child element value</childElement>
</element>

然后，在进行设计时，您可能会考虑将哪些属性表示为XML属性以及您希望将哪些属性表示为XML元素。请参阅 XML attribute vs XML element 以寻求帮助。

关于 A vs B 提议的设计，请注意 A 根本不可行 - 您无法在声明的元素中使用非转义标记如您所示，拥有xs:string个内容。此外， A 无论如何都需要进一步解析OrderAttributes内容，而 B 会利用XML解析器来处理OrderAttributes内容。（而且，就像你说的那样， B 也不会利用XSD验证。）

对于将来的扩展，请考虑使用 xs:any ，它通过<{>> strict, lax, or skip的processContents属性值支持对通配符内容的各种解释

字符串元素与独立元素之间的XML

1 个答案: