wrote:
> David Carver writes:
>
>
>> Personally, I HATE xsi:type. In most B2B scenarios I've been involved
>> with it causes more interoperability issues then it solves.
>>
> If you're arguing against xsi:type, I can certainly understand that. It's
> the wrong thing in >90% of use cases (probably way more, but I'm just
> guessing and trying to be conservative), and it makes a mess of instance
> documents. It was introduced because some members of the Schema WG were
>
This is what I was saying, xsi:type causes more issues than it solves.
>
> Personally, I'm not convinced that supporting that scenario should have
> made an 80/20 cut for schema, but as happens on a big committee, some
> people argued very strongly for it. You can, of course, turn it off by
> using suitable "block" attributes at the right points in your schema.
> While that pretty much ensures that your instances are clean (I think
> xsi:type is still allowed for better or worse, but it can't then designate
> a type other than the one your element would have had anyway, as I
> recall), but it's a nuissance in the schema.
>
Unfortunately, the block attributes are implemented and supported
differently amongst the current validating parsers. Some say xsi:type
isn't allowed at all (my personal preference) and some allow it as long
as it's the correct type.
