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

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

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

所讨论的WSDL由客户机提供

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

如果数据被传递为“raw”，这是客户机希望发送数据的方式，那么somexmlement在被反序列化后为null

<SomeXmlElement><SomeArbitraryXml/></SomeXmlElement>

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

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

]>

我的理解是，只有少数几种选择可以正确地进行反序列化

包装在CDATA中（嵌套CDATA）

将模式更改为使用复杂类型而不是字符串，其中复杂类型引用其他XSD模式

xs:schema中的任何内容（这将反序列化为什么？）

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

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

---

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

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

如果他们想在

somexmlement

下允许任意XML，那么他们应该使用

xsd:any

如果他们想将

somexmlement

下的XML限制为另一个XSD给出的XML，那么他们应该使用另一个XSD并显式引用允许的元素

但是他们不应该指定

somexmlement

包含

xsd:string

，然后期望它的内容模型是真正的XML你是有权抱怨的人。

---

他们的实现已经有10年的历史，或者基于Java，这与此无关。XML和XSD规范可以追溯到很久以前，并且在Java中运行良好

所以，除了在这里寻找验证之外，除了告诉客户修复其损坏的接口定义之外，您可能还需要其他建议

---

考虑将他们的XSD重写为他们真正的意思，并将您自己和您的代码保持在更高的标准（即实际的标准）。其他任何事情都可能是一次又一次的黑客攻击，使你成为他们犯罪的从犯。

我应该澄清一下，他们提供了模式。我是那个抱怨他们想要发送的数据与模式不匹配的人。所以他们的XSD在元素中调用了

XSD:string

，但他们告诉你带外发送XML？这有点复杂。它们提供XSD/WSDL。作为系统集成的一部分，我必须主持一个服务来接收他们的呼叫。他们想在这个元素中发送的数据总是XML。他们不愿意更改模式，因为他们有其他实现。问题的一部分是，他们正在手动解析自己的东西，因此他们可以只寻找正确的标记，而在他们10年的java实现中，它是否真的验证或反序列化并不重要。我同意kjhughes的观点。当实例不符合模式时，给您一个模式和实例文档就像给您一个不会编译的Java程序。这是garbage.hrm，我想我可以在我这边更改WSDL以匹配他们发送的内容，但我也可以看到，如果他们对规范进行了任何更新，那么会导致问题，我们必须确保保留更改。目前，他们似乎正在继续CDATA路线。这个问题主要是证实了我的想法，并为任何有关局势的辩论准备了弹药。