On Fri, Aug 7, 2009 at 9:10 AM, Michael Kay
<mike@saxonica.com> wrote:
> XSD 1.0 had xsi:type because its bogus models of what people
> used attributes for was not sustainable.
>
> XSD 1.1 fixes this a little by allowing selection of type by
> a wider range of markup. So I would expect that xsi:type will
> wither on the vine over the next decade. I don't know that it
> is a show-stopper, because there is a better workaround.
>
> (The rub being that where companies don't switch to the
> latest version of the XSD 1.1 spec, they will be more stuck
> with xsi:type. And this rub exists largely because XSD 1.0 is
> so monolithic that implementers are loath to re-visit their
> implementations.)
There are some important specs like FpML that (for better or for worse)
place very heavy reliance on xsi:type, and the reality is that they aren't
going to change in a hurry: there are zillions of financial transactions
whizzing around the world that use this attribute.
Incidentally XSLT also makes use of namespaced attributes (e.g.
xsl:use-when). They aren't used in every stylesheet, but they serve an
important purpose and you can't just get rid of them.
Also we have xml:lang, soap:mustUnderstand, soap:actor etc. (these latter two often appear on their own outside the soap namespace context e.g. ebXML) etc. Personally I am not against namespaced attributes but there again I do not develop XML/XSL tools merely just use them so I am not au fait with the pain they may (or may not cause). As a developer once I "got" how namespaces work they have never really caused me much pain.
