OX Mapping - Mapping XML Schema to Classes Pt 1
There's a great interview with Anders Hejlsberg over on The Server Side. Anders was originally the guy behind Turbo Pascal and Delphi and (since joining Microsoft) one of the key people behind C#. One quote that I liked from the interview was as follows:
"My big issue with XSD has always been that people write their applications today with objects and classes and whatever be that in C# or Java or VB, or whatever, and then they want to transport them on the wire, and ideally, we would want to have some sort of type system that at least is fairly close to a what an object is so we can meaningfully map it to XML, and move it over, and then map it back. Unfortunately, XSD has a zillion other features that no one ever asked for. It is incredibly complicated to implement..." "...That makes that particular integration very hard...."
This struck a chord because this complexity has been underlying some of the recent work I've been doing. I thought it might be valuable to blog about these issues in the hope that there may be an easier approach, a tool to use or a technique that I've missed to make it a lot easier. It's also valuable to put all of this in context with upcoming developments such as Comega, OX Mapping tools and even version 2 of the Typed DataSet Generator.
So, what's the problem...? The issue is mapping types defined in an XML Schema to real classes in a program. Why is this a big deal... ? This underpins the whole philosophy of 'schema first' web services - or even 'interface first' programming for SOA. If you want to start with a design or an interface then you will need a way of mapping the meta data from the schema to the structures in your programming language. It's the same problem when mapping from a relational database, you start with the database schema and need to map it to your classes.
It's also not just web for services. Taking a step back, if you define your interfaces in terms of types from an XML Schema then - even if you do not intend to make a web service out of it - you've established a good fundamental type system for your design. This could allow you to break away parts of your apps in the future knowing that you have a cross-platform standards based metadata system.
So what are the options... ? These are the options that I've looked at - applying to the .NET world:
- Access the XML directly, do you need to map these messages to objects? This is an option, and strongly advocated by many groups. Web services do use messages and you could treat the data as messages using the XML DOM or something similar. The issue here is that you lose type safety. You also have to perform the message decoding yourself.
- Access the XML via a Typed DataSet. The Typed DataSet generator will cope with most simple schemas. There are some issues with Typed Datasets and the mapping is very simplistic. There are also some performance question marks over using the ADO.NET classes - it would be nice if there was an interface compatible native class generator too.
- Use an OX Mapping Tool. Fairly new on the scene, these are like OR Mapping tools but map from XSD to classes instead of a relational schema to classes. Some examples (for Java) include Caster, JAXB etc. Here's an article comparing Caster to the Typed DataSet Generator.
- Wait for the next round of tools from Microsoft (post Whidbey). Think of Comega and other new tools.
- and as always... write something yourself.
What is wrong with XSD Files? Why is OX Mapping so hard? XML schema files describe messages, they were there to replace DTDs. The problem is that these messages are now being used as the transport for remote services and XML Schemas are now being re-used in conjunction with WSDL files as the 'header file' for the internet.
The problem is that XML Schema files were never intended to be used for programmatic metadata. There are some major issues behind schema files that prevent creating complex type systems with relationships and other features:
- XML tags can be defined as being optional or occur many times. Each of these combinations needs to be dealt with differently. If a complex type definition in XML schema contains a tag that is optional then the mapping class needs to take this into account and use a boolean to indicate that it is present or use nullable value types (Whidbey+ only).
- Type definitions themselves have no direct mapping. When performing OX Mapping your .NET class needs to map to a set of elements in the XML. This set of elements is described as a complex type in the schema. The problem is that an element can be defined by an anonymous type definition in the schema or the element can be defined by a named complex type, which in turn may come from a different schema and/or defined as an extension of another complex type.
- The XML Schema file goes beyond message structure in certain areas. The key tag defines indexing and the unique tag defines index uniqueness in the message. Although the unique tag can be used to validate the message, the key tag is used as a hint to the parser as to how the message will be accessed. This is good news for OX Mapping tools that can make use of this extra information to provide helper functions into the data structure. The big problem is that these constraint tags are defined at the element level and not the complex type level. They can define keys and relationships at the element level for the message but this information is not inheritable. This means individual types that are intended to be re-usable across different schemas cannot include their own individual index key and relationship hints for other schemas to use.
These mapping issues (and others) can be overcome. I'll cover this in a separate blog entry and compare it with the Typed DataSet generator.