RE: [xml-dev] ten years later, time to repeat it?

["Michael Kay" <mike@saxonica.com>]

> I can understand the occasional need for typing, sure, but 
> the expanded name should be all you need to look up the type 
> definition in a schema. In other words, the expanded name 
> *is* the type name. If you want the element in that position 
> in your language to potentially be a whale or a lemur, then 
> have the schema offer <whale> and <lemur>, not some hack with 
> xsi:type. This is one part that IMHO DTDs got right.

For a great many purposes, having a one-to-one mapping between element names
and types (=content models) is a nice simple way of doing things. But there
are quite a few scenarios where it can be handy to have an indirection. 

* you might want two different elements to have the same content model
(delivery address and billing address). This is particularly true of course
for simple types like decimal.

* you might want the same element to be validated against different rules on
different occasions (a draft contract satisfies different rules from a
completed contract)

* you might want to overload an element name, so that it satisfies different
rules depending on where it appears

* you might want to declare that in a particular instance, an element
conforms to a more extensive set of constraints than it actually needs to.

I can't say I find the xsi:type mechanism remotely elegant as a way of
dealing with these requirements, but the basic idea that element names and
types are separate concepts seems to me to be sound in principle. It's
interesting, and probably not unconnected, that SQL also decided to create
an indirection between a table name and a type.

Michael Kay
http://www.saxonica.com/