1

I am hosting a C# WCF SOAP which service that has a call which contains the following element

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

The WSDL in question is provided by the client.

The content of this element is valid XML which in general will conform to a different XSD, but for our purposes is arbitrary valid XML

If the data is passed "raw" which is the way the client prefers to send it, SomeXmlElement is null after being deserialized

<SomeXmlElement><SomeArbitraryXml/></SomeXmlElement>

If I have them wrap it in a CDATA it works correctly, but the customer/client complains that they don't have to do that for other implementations, and it causes compatability issues

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

My understanding is that there are only a few choices to have this deserialize correctly.

  1. wrap in CDATA (nested cdata ugh)
  2. Change the schema to use a complex type instead of string, where the complex type references the other XSD schema
  3. xs:any in the schema (what would this deserialize as?)

The customer insists that this is just a deficiency in my code/.Net and that this should deserialize/process fine in the raw format.

Rolling my own deserializer would be possible, or just loading into a DOM and accessing the InnerXml property or whatnot, but thats a lot of work to override default expected behavior imo.

Thoughts? Suggestions? Am I interpreting the XML specs correctly? Are there any choices that don't require schema changes or rewriting lots of WCF default behavior?

Jason Coyne
  • 6,509
  • 8
  • 40
  • 70

1 Answers1

2

Your client has no right to complain. They're publishing an interface and then telling you out-of-band to ignore parts of the interface specification.

If they want to allow arbitrary XML under SomeXmlElement, then they should use xsd:any.

If they want to restrict the XML under SomeXmlElement to that given by another XSD, then they should import or include the other XSD and explicitly reference the allowed elements.

But they should not specify that SomeXmlElement contains an xsd:string and then expect its content model to really be XML. You're the one who has the right to complain.

That their implementations are 10 years old or Java based is irrelevant. XML and XSD specifications go back that far and work well in Java.

So, besides looking for validation here, you probably want advice beyond telling your client to fix their broken interface definition...

Consider rewriting their XSD to be what they really mean, and hold yourself and your code to a higher standard (an actual standard, that is). Anything else would be a hack upon a hack and make you an accessory to their crime.

Community
  • 1
  • 1
kjhughes
  • 106,133
  • 27
  • 181
  • 240
  • I should have clarified, they provided the schema. I'm the one complaining that the data that they want to send doesn't really match the schema. – Jason Coyne Jul 29 '15 at 01:51
  • So their XSD calls for a `xsd:string` in an element but they're telling you out-of-band to send XML instead? – kjhughes Jul 29 '15 at 01:55
  • Its a bit convoluted. They provide the XSD/WSDL. I have to host a service to receive their calls as part of a systems integration. The data they want to send in this element is always going to be XML. they are reluctant to change the schema because they have other implementations. Part of the problem is that they are manually parsing things on their side, so they can just hunt for the right tags and it doesn't matter that it doesn't really validate or deserialize in their 10 year old java implementations. – Jason Coyne Jul 29 '15 at 02:02
  • I agree with kjhughes. Giving you a schema and an instance document when the instance doesn't conform to the schema is like giving you a Java program that won't compile. It's garbage. – Michael Kay Jul 29 '15 at 07:39
  • hrm, I suppose I could just change the WSDL on my end to match what they are sending, but I could also see that causing problems down the line as if they ever have any updates to the spec we have to make sure the changes are preserved. For now they seem to be moving forward with the CDATA route. This question was mostly confirming my thoughts, and building ammo for any debates about the situation. – Jason Coyne Jul 29 '15 at 14:13