Sorry I screwed up the files when changing my real code to an example.
I should have tested them before posting.
Files:
http://web.mit.edu/rajsingh/www/xml/test.xsd
http://web.mit.edu/rajsingh/www/xml/test.xml
http://web.mit.edu/rajsingh/www/xml/test-xsd.zip
test.xsd and test.xml now validate in XMLmind Xsdvalid, XMLSpy 2004,
and JWSDP 1.3. JWSDP 1.3 generates the java code for test.xsd fine as
well (archived in test-xsd.zip). I try a simple unmarshalling with the
following code:
JAXBContext jc = JAXBContext.newInstance("com.example.x");
Unmarshaller unmarshaller = jc.createUnmarshaller();
unmarshaller.unmarshal(new StreamSource(test.xml));
This is the error I get:
DefaultValidationEventHandler: [ERROR]: Unexpected element
{
http://example.com/x}:Bel
Location: line 5 of file:test.xml
javax.xml.bind.UnmarshalException: Unexpected element
{
http://example.com/x}:Bel
You're right that the xsi:type strategy doesn't look very elegant in
the XML instance file, but looks much better in the schema. Looks
aren't really that important, though. What really matters is
extensibility. Let's say I use xs:choice to specify the types of
elements that C can contain. If someone writes a new object (call it D)
that extends A, D can't be put in C unless I update my choices. Whereas
if I use the type strategy, D can immediately be used in C. In my
situation I have a lot of these cases, so it is not a trivial issue.
--Raj
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
For additional commands, e-mail: users-help_at_jaxb.dev.java.net