如果字符串元素包含有效的 XML，是否需要 CDATA 来验证/反序列化架构

Question

我正在托管一个 C# WCF SOAP，该服务的调用包含以下元素

<element name="SomeXmlElement" type="xsd:string" minOccurs="0"/>

有问题的 WSDL 由客户端提供。

此元素的内容是有效的 XML，通常符合不同的 XSD，但对于我们的目的，是任意有效的 XML

如果数据是“原始”传递的，这是客户端喜欢发送的方式，SomeXmlElement 在反序列化后为空

<SomeXmlElement><SomeArbitraryXml/></SomeXmlElement>

如果我让他们将其包装在 CDATA 中，它可以正常工作，但客户/客户抱怨他们不必为其他实现这样做，这会导致兼容性问题

<SomeXmlElement><![CDATA[<SomeArbitraryXml/>]]></SomeXmlElement>

我的理解是，只有几个选择可以正确反序列化。

1. 在 CDATA 中换行（嵌套 cdata 啊）
2. 将架构更改为使用复杂类型而不是字符串，其中复杂类型引用其他 XSD 架构
3. xs:any 在架构中（反序列化为什么？）

客户坚持认为这只是我的代码/.Net 中的一个缺陷，这应该以原始格式反序列化/处理。

滚动我自己的反序列化器是可能的，或者只是加载到 DOM 并访问 InnerXml 属性或诸如此类的东西，但是要覆盖默认的预期行为 imo 需要做很多工作。

想法？建议？我是否正确解释了 XML 规范？是否有不需要更改架构或重写大量 WCF 默认行为的选择？

Answer 1

您的客户无权投诉。他们发布了一个接口，然后在带外告诉您忽略部分接口规范。

如果他们想在SomeXmlElement 下允许任意XML，那么他们应该使用xsd:any。

如果他们想将 SomeXmlElement 下的 XML 限制为另一个 XSD 给出的 XML，那么他们应该 import or include 另一个 XSD 并明确引用允许的元素。

但他们不应该指定SomeXmlElement 包含xsd:string，然后期望它的内容模型真的是XML。 你是有权投诉的人。

---

他们的实现已有 10 年历史或基于 Java 是无关紧要的。 XML 和 XSD 规范可以追溯到那么远，并且在 Java 中运行良好。

因此，除了在这里寻找验证之外，您可能还需要一些建议，而不是告诉您的客户修复他们损坏的接口定义......

考虑将他们的 XSD 重写为他们真正的意思，并让您自己和您的代码达到更高的标准（即实际标准）。其他任何事情都将是对黑客的攻击，并使您成为他们犯罪的附属品。