Life and code.
RSS icon Home icon
  • XSD As A Type System Redux

    Posted on January 26th, 2004 Brian No comments

    Steve has written a lot over the last few days on his belief the XSD is not a type system. This was one his favorite topics to toss around with me when we were both at Avanade. If you haven’t read his disserations, you should check out Part 1, Don Box‘s reply, and Steve’s Part 2, in reply to Don. It’s all great.

    I find that I tend to side with Steve’s position that XSD is not a type system. Although it can be used as a type system, it really is much more powerful at not being a type system. If you are using it as such, you should really be using something simpler than XSD, like .NET’s common type system. It describes types much more succinctly. A parallel might be C++ to C: C++ is an object-oriented language with object-oriented features. You can code C++ so that it degenerates to not being object-oriented, but you’d be missing out on a whole heckuva lot. Now, this discussion is interesting and all, but it’s not what this post is really all about. This was the background to set up a higher-level question that came up while I was having coffee this afternoon with Corey and Chris.

    We’ve been beholden to a statically typed language for this entire discussion, and it has been forgotten that an entire realm of dynamically typed languages exist out there, and I believe they render the entire discussion meaningless. Langauges like ECMAScript, Ruby, or Python. Take ECMAScript, for example: It’s dynamically typed, and the concept of a class only exists in-so-much as each object is its own class. Equality is based strictly on structure. In such a language, the idea of a nominal type is pointless, and therefore such a language can always parse any given XML structure and create a type at runtime to represent that XML. It doesn’t matter whether the schema validates or not as long as the XML is well-formed. It seems to me that the robustness provided by the dynamic typing makes it a near-essential feature for writing flexible, resilient consumers and services. Certainly it cannot be worse than requiring re-generation of some proxy classes at build time. I am beginning to think that this entire is-it-a-type-system discussion is irrelevant in the face of languages that neither use nor require a type system.

    Comments are closed.