Friday, June 04, 2010
Thoughts on XML 2.0
In my travels, I have ran across lots of horrific usages of XML. While part of the challenge is related to learning XML via Dummies books and other introductory methods that don't make it to more complex design considerations, some of it is attributable to those who desire a richer grammar and end up reinventing the wheel. The below enhancements are all related to the latter.
- Currency: We live in a global economy and should never assume that money is always in local currency. Anytime you are dealing with currency, it should be treated as a complex type that ideally should be built in. For example, you may have an attribute known as amount, an enumeration of the currency used such as Rupees, Dollars, Yen, etc and another enumeration that contains the country of the currency since dollars, rupees and yen are all used beyond a single country.
- Duration: Ever notice the concept of valid date ranges being constantly used. It should be straight-forward to have a reusable complex type that allows someone to specify a from and to date.
- Enumeration: This is probably the more interesting challenge in that we first need to a way to specify whether they are open or closed such that this can be validated via schema. The need to extend enumerations (open) within a business context is important. Examples may include supporting new diagnosis codes and procedures as medical technology advances or even the additional of new countries. Sometimes, enumerations also need to be closed and not subject to further extension (aka final). For example, if you decided to treat Gender as an enumeration, you may at most have a fixed number of values that shouldn't change over its lifetime.
- Boolean: The funny thing about Boolean is that it really isn't boolean. Those who grew up on mainframes and C may think of booleans as being represented by 0 and 1. Those who grew up with English as their background, may think of booleans as TRUE and FALSE. Shouldn't we strongly type booleans so that they are represented one and only one way?
- Namespace: We need to eliminate the notion of a default namespace and instead have the ability to mandate that all XML have one? This would making parsing ambiguity disappear.
- Character Set: Wouldn't it be good if you could specify what are the allowed character sets for a given attribute such that it could be validated via schema? Should I be able to shove Japanese Kanji via Unicode into an attribute where the receiver can only process English?
Links to this post: