WCF: Contract first web services & Data Contract Serialization from XSD schema

Contract Generation from WSDL/XML Schema - DataContractSerializer vs. XmlSerializer

Working on creating DataContracts for Windows Communication Foundation. I am currently building them in C# .NET 3.5 with Visual Studio 2008. The main problem is our business analyst created the XSD schemas in Altova XML Spy which allows for great flexibility, but as you saw in yesterday's blog, there can be issues with the svcutil creating contracts with the DataContractSerializer. That's what we examine here.

Here is the command I am currently running from my Visual Studio Command Prompt:
svcutil.exe "C:\DEV\MyServices\DataContracts\Schemas\OfficialRecord ver. 1.2.xsd" /dataContractOnly /serializer:DataContractSerializer /language:C# /out:MyDataContract.cs

I am attempting to generate this into code (schema-first design) but there are problems with converting it.

Error: You must qualify all elements. Easiest way: In the schema definition, you can add attribute elementFormDefault="qualified"
Big Problem: Certain constructs are not allowed in WCF. For example:

• Xsd:choice
• Xsd:group
• Xsd:any
• Xsd:ref
• Xsd:attribute

This msdn white paper shows what is allowed/disallowed:
http://msdn2.microsoft.com/en-us/library/ms733112.aspx
Other errors in WCF:
Tips & Tricks with WCF

Solution? Apparently there is a way for XMLSpy to generate classes from an XSD. So… I loaded it. Checked it out… oops! It only works in the “Enterprise” edition. (I have Professional)
 
The main reason I was taking the “schema-first web services” approach was so it was based off Business Analyst decisions. In addition, if schema changed (or we have new schemas), we could quickly and easily regenerate the code. 2 flaws with that way of thinking:

1. If we’re only adding/updating 1 or 2 properties in a schema, it’s a waste of time to regenerate using the svcutil (the VS tool I’m using)
2. I doubt there will ever be major redesigns.

 
My thoughts on this all…

1. Is the XSD trying to specify TOO MUCH? I mean, XSD validation should probably only happen on the request (we’re the ones generating the response)
2. I could write an xsd code generator. I did my research on this too (to see what exists out there) but they all have flaws.
3. I can just old-skool it and transfer it over by hand.

Excerpt from Sonua's blog:
http://blogs.msdn.com/sonuarora/archive/2007/06/16/
contract-generation-from-wsdl-xml-schema-datacontractserializer-vs-xmlserializer.aspx

WCF LOB Adapter SDK metadata object model generates WSDL / XML Schema with constructs that are well-liked by DataContractSerializer.  The Svcutil.Exe creates a proxy / service interface from this WSDL containing attributes such as ServiceContract, OperationContract, DataContract, DataMember, etc.  If the adapter developer provides own XML Schema structure in OperationMetadata and/or TypeMetadata derived class and the XML Schema contains constructs that are ignored or forbidden  by DataContractSerializer, the Svcutil.Exe and Add Adapter Service Reference Visual Studio Plug-In  falls back to use XmlSerializer for serialization.   

Following are some examples of forbidden XML Schema constructs:

• Xsd:choice
• Xsd:group
• Xsd:any
• Xsd:ref
• Xsd:attribute

The metadata object model in WCF LOB Adapter SDK avoids generating any XML Schema constructs that are ignored and forbidden by DataContractSerializer.  But if the adapter developer wants to provide their own schema, then it is outside the Adapter SDK control and the WSDL will contain the XML Schema definitions as provided by the adapter developer.   The generate CLR proxy will have the XmlSerializer attributes defined on operations and its members.

What does this mean to the end-user? 

Adapter Consumers who want to use the adapter in BizTalk Server are not affected with XML/CLR (de) serialization, as they are working directly with XML Schema types.  As long as the XML message conforms to the XML Schema, the adapter understands it.   

But if the same adapter is also now being used within a .NET application that will convert the WSDL / XML Schema into relevant CLR objects, the end-users who are working with the generated CLR object may contain definitions that are “bizarre”. 

Let me give you an example.   Consider an XML Schema with optional elements defined (i.e. minOccurs=’0’).   When using DataContractSerializer, the minOccurs should map to IsRequired attribute in the CLR object.   The XmlSerializer on the other hand generates a proxy that contains the xxxSpecified properties for each optional element.  The xxxSpecified was a pain for our customers in .NET 2.0 when used with xsd.exe or wsdl.exe.  Now, let’s add another complex type in the WSDL that uses a forbidden construct such as “xsd:attribute”.  The Svcutil.Exe will revert to use XmlSerializer and generate an output that contains xxxSpecified fields.