Question

我之前为客户实施的WS制作了XSD + WSDL。我们实施客户端。我在WS Create-operation中输入了这样的类型：

<xs:complexType name="tWorkCreate">
 <xs:sequence>
  <xs:element ref="plan:workkey"  />
  <xs:element ref="plan:workdata"  />
 </xs:sequence>
</xs:complexType>

现在我想为新的Update操作使用相同的类型，但是命名是错误的。所以我打算这样做：

<xs:complexType name="tWorkSet">
 <xs:sequence>
  <xs:element ref="plan:workkey"  />
  <xs:element ref="plan:workdata"  />
 </xs:sequence>
</xs:complexType>


<xs:complexType name="tWorkCreate">
 <xs:complexContent>
  <xs:extension base="tWorkSet">
    <xs:sequence>
    </xs:sequence>
  </xs:extension>
 </xs:complexContent>
</xs:complexType>

并直接使用tWorkSet进行Update操作（tWorkCreate操作将是相同的）。现有客户不需要（并且没有实施）Update。不重复类型的原因是我们可以在代码中同样处理Update和Create。那么复制类型还是更好吗？这个扩展方案是否合理？

Answer 1

是的，以这种方式重构类型定义是一个好主意，并且向后兼容¹。在重构之后，在类型重构之前有效的所有相同XML文档都将是有效的。实际上，它比向后兼容更好，因为完全在更改之前有效的XML文档集在更改之后有效。

_{¹假设客户端与类型名称本身没有直接依赖关系，例如通过JAXB绑定或在XML doc实例中使用xsi:type。 [感谢Petru Gardea.]}

Answer 2

应用于XSD时，向后兼容性非常棘手。可以以多种方式使用模式;如果没有对边界的充分理解，那只是猜测。例如，一般来说，声称更改类型名称是向后兼容的是错误的;如果有人在其有效的XML中使用xsi：type会怎样？

还应仔细规划创建类型层次结构。与今天的大多数主流OO语言一样，您只能从一种类型扩展。

在您的情况下，您似乎担心重用;然后最安全的可能是通过创建一个组来重新使用，然后根据需要由您的类型引用。当然，＆＃34;最安全＆＃34;取决于您定义的边界。对于JAXB，.NET等，支持组，并且默认情况下它们是内联的 - 即它们在XML和生成的代码方面没有任何足迹。

<xs:group name="tWorkSet">
    <xs:sequence>
        <xs:element ref="plan:workkey"/>
        <xs:element ref="plan:workdata"/>
    </xs:sequence>
</xs:group>

<xs:complexType name="tWorkCreate">
    <xs:group ref="tWorkSet"/>
</xs:complexType>

是通过从完全相同的类型向后兼容来扩展它来修改现有的XSD类型吗？

2 个答案: