> The more precise way of saying is that we don't support type
> substitution, not just abstract type.
>
> The use of the abstract type is a clearly indication that the type
> substitution is going to be used, so that's why RI complains about it.
I don't think it's quite that clear, though. An abstract type could be used
as a mechanism for maintaining common definitions for subtypes, yet not
actually be used directly in any element or attribute declarations.
But... without a block attribute set to #all, you really couldn't be certain
it won't be substituted for in a document, could you?
> Removing the xsi:type support from v1.0 was an expert group decision,
> and I personally think it was a very reasonable thing to do. You
> can't just take XML schema as its entirety at once. It's just
> too complicated. We needed to set a realistic goal to deliver
> something
> soon.
I was not trying to twist your arm. I fully understand the strategy of
incremental releases.
> As an example of showing how it's complicated. Take the following
> schema:
>
> <xs:element name="foo" type="xs:string" />
>
> Now this might look like an easy example with the obvious binding to:
>
> interface Foo {
> String getValue();
> }
>
> or something, but supporting type substitution means that you
> need to be
> able to unmarshal
>
> <foo xsi:type="IDREF"> refToSomeOtherObject </foo>
>
> and
>
> <foo xsi:type="myComplexType" abc="def"> aaa </foo>
Of course you'd have to construct the right instance and perform the
appropriate cast. I know you can construct the proper mechanisms, but I
respect your desire to avoid doing so right *now*. I was just curious.
Thanks,
Jeff