XML Schema is a Case of Premature Optimization

Developers are pretty familiar with the term premature optimization. If you're unfamliar with the term, then just think of it as a bad thing. Premature optimization happens when a developer over zealously optimizes code before running system wide performace tests. For novices and people straight out of school, this doesn't seem to be such a bad thing. However, the bad thing is the fact that if you optimize too early, many of the assumptions that you make may be wrong and even worse the code you've written may have become inscrutable .

XML Schema may be practically inscrutable, however that's not why I think its a case of premature optimization (of course, that's still a good case to make, afterall the commitee seemed to not have a clue as to what they were trying to solve!). I think the pre-optimization is more at the fundamental level.

Let's take a step back and ask ourselves this question "what are schemas for?". The reason we have schemas is so that parties can agree on what language to use before they attempt to converse. In short, if a client conforms to the schema that a server requires, then we have an assurance that the server can receive and parse the messages it sends.

This question opens up another question, "how do they achieve agreement on the language?". Obviously, you have to assume they already have a prior means of conversation. In the world of XML Schemas, it can be either a meeting of organizations to agree on a standard schema or it could be discovered through some schema repository like UDDI.

Yet, in both instances, the way a party agrees to a certain conversation is through agreement to support a certain schema. In other words, a schema is a contract and it is a contract that describes a grammar (syntax or the tokens are XML). No where in that schema are semantics described, that's really for a yet to defined layer (just ask the RDF/OWL folks!)

Buy wait, couldn't a client build its own contract and propose it to a server (or the otheway around)? If the server agrees by returning a confirmation, then conversation can proceed. The benefit of this approach, is information hiding, that is the server doesn't have to enumerate what it can or cannot support. Of course it isn't practical or rather should I say "frustrating". Like asking a guru the meaning of life and all he can respond is with a yes or no. Selecting from a menu is more expedient than having to precisely describe what you want.

XML Schemas are that menu, that menu is an optimization. The less choices one has on that menu, the more expedient it is to get to agreement. It's the difference between fast food and a restaurant. However, it doesn't have to be that way, ordering from a chinese restaurant is almost as quick as ordering from McDonalds. That's because the ingredients tend to be the same, it's just a different combination of ingredients.

Premature optimization is reflected by limitations on choices. The menu needs to be flexible, it should be put together by ingredients that best suits the client. Flexibility is achieved by allowing combination not by constraining one to a fixed set of choices. What better way to gain complete flexibility by always starting from scratch and working to agreement through unbounded conversation. Sure it doesn't sound efficient, but it's pretty darn flexible!