Dave Orchard on profiling XSD

Dave Orchard posted this piece in response to my posts on profiling XSD. He thinks I'm missng the point that this is an issue for users because they can't get interoperability across their implementation of schema. I disagree. What users can't get is interoperability across their implemenetations of OO serializers whose behavior is defined (typically) at dev time by consuming a schema. This is not the same thing. There are no ambiguities that need to be resolved in XSD, as there were in SOAP and WSDL. Having WS-I define a subset of schema that amounts to a lowest-common denominator for what object serializers must do and then developing to that is a sure fire way to turn Web services into an (O)RPC mechanism, and nothing more. As I've said before, if that's all we're doing, then what's the point?

In response to my statement about changing tools if the one you are using doesn't do what you need, Dave says:

So this means that if .Net doesn't support something then all of .Net should be thrown out? We all know that a company is *not* going to throw out all of .Net Web services because of some "technical" schema problems.

No, of course not. You could step away from the object <=> XML marshaling plumbing and consume a message directly as XML if desired. You can do this in ASP.NET Web Services (ASMX) and in WSE, and you'll be able to do it Indigo too. But even that's not required. XmlSerializer, the object <=> XML marshaler in .NET today can be used independent of XSD. You can write your own class that uses XmlSerializer to map your data to objects. So the only thing you're walking away from is the wizard/command-line tool that takes your XSD and does that for you.

It's those tools that we're really talking about. Should the interoperable standard for message description be based on *today's* tools? What would be the criteria? If an XSD feature made a tool crash, it makes sense to throw it out, right? But what if other tools can process it? Is one tool choking enough to drop a piece of XSD on the floor? What if none of the tools crash, but one ignores the feature and exposes only a subset of a message as a result, is that okay? What if a tool maps something from XSD into an object model, but doesn't capture all the semantics? For instance, what if a tool maps an integer restricted to the range 0 to 100 to an integer with any value. Is that okay, or should restriction of simple types be disallowed, even though the next version of the tool might add this enhancement? And what happens when we go beyond .NET and Java and think about SQL Server support for Web services, or PERL Web service toolkits, or Kafka, which is written in XSLT? Do the things those less mainstream tools can and can't do matter, or do we only care about ASMX and JAX-RPC programmers?

Beyond tools, what about the schemas that already exist. Dave suggests that XHTML 1.1, which uses xs:redefine, xs:group, and a host of other XSD-isms, isn't interesting to WS-I. But I work on applications for MSDN, a business that publishes information online, and all of the content in our new online system is represented using XHTML. We're working on internal Web services for publishing and external Web services for delivery of that content. I want my services to be interoperable too, but subsetting XSD isn't going to do it because I'm using an existing schema. Is my problem domain just not important? How about XBRL for financial records and HL7 for health care information? A big part of the value of Web services will only be realized when we have standard schema for describing information. Don't we care about those vertical standards too?

I'm not a big fan of XSD, as anyone who reads my blog can attest. But I accept that we're using it because there's industry concensus on it. Tools do not require concensus. I don't want to live in a world where we tie our hands based on a how today's tools work. More importantly, I don't want to standardize any aspect of Web services that frames the technology as nothing more than an (O)RPC mechanism and hiding every aspect of XML from the user is more important than leveraging the power XML offers. As I seem to be saying a lot lately, if that's all we end up doing, we're really missing the point.