xsi:type Train Wreck7182004-01-29T07:44:00-05:00$Date: 2005-09-11 10:27:02 -0400 (Sun, 11 Sep 2005) $NormanWalsh2004Norman WalshI’ve never liked xsi:type. From my perspective, elements have
declarations and those declarations tell you the type of an element.
Sir WalterScottA rusty nail placed near a faithful compass, will sway it from
the truth, and wreck the argosy.I’ve never liked xsi:type.
Whenever I think about it, my intuition whispers softly that any design
that requires it is somehow flawed or at least ugly.From my perspective, elements have declarations and those
declarations tell you the type of an element. I don’t care if the notion
of type is explicitly part of the schema language or not.An address is an
“address” because somewhere there’s a declaration for that element that
tells you what attributes and children it can have. Things that can
have streets and cities and postal codes are addresses so that’s what makes an
address an “address”.Here’s an address type, for example:
]]>And we might associate that type with a particular element using
the declaration:]]>In the old days, when we used DTDs, there was a one-to-one correspondence
between element names and their declarations. That’s no longer true, but I
still think my premise holds. If there are several declarations for
address, at least one of them must apply
if the document is valid. (If the document isn’t valid, all bets are off anyway.)
If more than one declaration applies, some schema languages call that an error
and some don’t. If it isn’t an error, I’d probably like a warning about that
in my development environment, but as far as I’m concerned, the tool is free
to pick any one of the declarations (or all of them, if that’s appropriate in
the processing environment).Now, my choice of element names in the address type belies a desire to handle
international addresses (if I was only concerned with U.S. addresses, I’d have
just named the children state and
zip). So let’s make
an international address type:
]]>And associate it with an element:]]>With these types and declarations, I can write a stylesheet that
processes addresses and
intladdresses and I can do that with full knowledge
of the attributes and children each can have because I know how
address and intladdress are
declared.Enter xsi:type.Because an international address is defined as an extension of an address,
things like this are valid:The House of CommonsLondonSW1A 0AAGB
]]>What does this mean? It means that the declaration for address
isn’t relevant here. The type of our element has been hijacked.Critically, it means the mental model that knowing an element’s name
(in a particular context) and knowing that it’s valid tells you enough about it’s
type to process it is wrong.This XSLT template is going to silently do the wrong thing:
,
]]>XSLT 2.0 provides machinery to deal
with this situation. You can, for example, match on the name of the
type instead of the name of the element. But that means you’re going
to need a type-aware XSLT 2.0 processor and a possibly substantial
rewrite of your stylesheets.Your other applications, in Perl,
Python, your language of
choice, are going to have to be adapted as well. I think that’s going to mean
explicitly checking for xsi:type or
getting some sort of general access to the PSVIPSVIPost Schema Validation InfosetPost Schema Validation Infoset.This isn’t news, of course. In fact, I must have known this at some level
all along. But my attention was drawn to this particular side-effect
of xsi:type recently and it makes me
like xsi:type even less.W3C XML Schema fans will probably tell me that if I just accept
the W3C XML Schema type-based model of the world, upgrade my tools,
and treat the type information as primary, it’ll all “just work”.
What’s more, I expect they’ll tell me this is “the right way” to work
with XML. Then one of them will tell me that XML is, like, you know,
“object oriented.” I don’t know if that’ll make me laugh or cry, but
I’ll argue that
they’re wrong.Alas, you can’t prevent the use of xsi:type
(W3C XML Schema implicitly declares them globally and offers no provision for
constraining their use). So you’ll have to support them, or use some other
constraint mechanism to prevent them, if you support W3C XML Schema.