Hi Kohsuke,
Thanks for your quick response. For the JAXB RI, is the following compromise possible?
Whenever JAXB RI sees an abstract type, it generates a generic java class that simply
reads in the XML fragment for that element as is. This generic class will have accessor methods
like
DOM getElementAsDOM();
String getElementAsText();
etc.
This class essentially knows how to read XML element as is and how to write it back.
With this (minor?) modification to JAXB RI, we can still use it on schemas which have abstract types.
The application can then deal with abstract type in the schema as it feels fit. This way, JAXB RI is still
usable in cases where schema uses abstract. Let me know what you think.
----- Original Message -----
From: Kohsuke Kawaguchi
To: JAXB-INTEREST_at_JAVA.SUN.COM
Sent: Tuesday, January 21, 2003 3:59 PM
Subject: Why we don't support abstract complex types
> Is there any plan to support abstract types for JAXB 1.0? If not, am I
> out of luck or is there any approach I can use to still use JAXB to do
> most stuff and hand code the java corresponding to abstract types?
In JAXB1.0, I think a provide is not required to support type
substitution through @xsi:type. And RI isn't going to.
An abstract complex type is a sign that @xsi:type is going to be used in
the instance document, so that's why we raise an error.
Now this doesn't mean that other providers are not going to support this
feature since they are allowed to do so by the spec. But I'm not aware
of any such implementation right now.
For RI, unfortunately there's not much workaround. If your application can
ignore the part that use the type substitution, you can cut the relevant
part from your schema.
Or if you are really desperate, I guess technically you can transform it
to another format first then unmarshal it.
Sorry.
regards,
--
Kohsuke KAWAGUCHI 408-276-7063 (x17063)
Sun Microsystems kohsuke.kawaguchi_at_sun.com