XSD gripe 2 – DataType hell

I know I am just the latest in a long line of people to “comment” on this subject – but I just wanted to give my two cents.

I appreciate the fact that the XSD designers wanted to vastly enrich my datatype life. But why come up with a bunch of built-in SimpleType datatypes which are just derivations of other SimpleTypes when you gave me a nice mechanism for doing so myself? If I really want a nonPositiveInteger – then I can easily define it myself using constraining facets. If I really want a gYearMonth then... does anyone really need a gYearMonth?

(I also don’t really understand having a set of limitless integers – at least they could have come up with a name that people would not pick by default - something like IntegerDontUseThisUnlessYouAbsolutelyHaveTo – but that is another rant for another time).

One can point out that there is the primitive datatypes – but again, too much here and I would argue that most users would not tend to limit their SimpleType datatype usage to the primitives – particularly because the primitives don’t contain an integer type.

I really think XSD would be a lot better off here if they had gone the programming language route and really limited the amount of built-in value types. I understand that there is value with have a large set of built-in datatypes, but I think they have gone well beyond the 90/10 rule on this.

Comments

• Anonymous
  December 30, 2004
  Amen brother. We even submitted last call comments to that fact, if I remember correctly.
  
  So to use a common phrase: Just say no to xs:nonPositiveInteger (or xs:gMonthDay).
  
  Much worse are things like allowing patterns to restrict the value space by restricting the lexical space. That works for validation, but once you store the typed value, you normally do not remember whether you had 3 or 4 leading zeros...