> I, too, was curious about the lack of support for abstract types. I was
> thinking it would just be a matter of sticking an "abstract" keyword in the
> class declaration that was generated, but I suppose there's some
> not-so-subtle interactions I'm overlooking.
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.
But what we actually don't support is a type substitution --- any use of
@xsi:type.
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.
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>
regards,
--
Kohsuke KAWAGUCHI 408-276-7063 (x17063)
Sun Microsystems kohsuke.kawaguchi_at_sun.com