Ed,
Thanks.
> * The spec doesn't require JAXB implementations to marshal valid XML.
I don't know if I should laugh or cry :) Can someone please explain what the point of marshalling invalid XML is? Certainly, implementations should *try* to make it *easier* to generate valid XML and should *discourage* (if not overtly make difficult or prevent) the creation of invalid XML. I mean, I appreciate the "power" and "flexibility" to make invalid XML, but what what else do I get ? ;)
Thanks for the tip about the validator. I've been using the marshaller to validate...
- Matt
-----Original Message-----
From: Ed Mooney [mailto:Ed.Mooney_at_Sun.COM]
Sent: Tuesday, June 29, 2004 11:30 AM
To: users_at_jaxb.dev.java.net
Subject: Re: Polymorphism problems
Sorry for not having dug deeply enough to address the root of your
issue, but I wanted to chime in here with these points:
* If xjc compiled your schema, you can trust that it's valid.
* The spec doesn't require JAXB implementations to marshal valid XML.
Use the Validator class to check the validity of your content tree.
E.g.:
Validator v = context.createValidator();
v.validate(content);
Regards,
-- Ed
Matt Munz wrote:
> Andrew,
>
>
>>sorry if I have missed something but I think JAXB does behave how you
>>want?
>
>
> Nope. As I mentioned in my first post, the marshaller creates invalid XML.
>
>
>>I'm not sure what you mean here - if you marshall a list of objects then
>>you will get xml output corresponding to the bindings of those objects?
>>that's what my original code was suggesting is the correct behaviour
>
>
> Well, I would expect the marshaled XML to validate, which it does not. I believe that my printNames method is a closer analogy to the proper algorithm for marshalling than your main method. Your method may accurately represent JAXB's algorithm, but I believe that this behavior is unnecessarily naïve and violates my concept of proper OO polymorphism.
>
>
>>I was playing with exactly this yesterday - and it does work. The
>>restricted types implement the interface generated for the base type.
>
>
> Yes they do, however, substituting instances of the sub-interface in places in the object graph reserved for instances of the super-interface produces invalid XML when marshalling. This clearly violates the is-a principle that I described previously.
>
>
>>also I'm a little confused by the schema snippet you posted - the XML
>>Primer says you must duplicate the content from the base in the derived
>>definition (unlike how java inheritance is declared) - which from my
>>reading would mean that Employee would need to declare both "name" and
>>"title". although this is all new to me (but I would like to
>>understand..)
>
>
> I am certainly no XML Schema expert. If this schema is not spec-compliant, I would love to know why. I wrote this schema with the help of XML Spy. I have been able to create XML that validates to this schema, according to XML spy, and neither xjc nor Castor has complained when compiling bindings for it. This leads me to believe that the schema is valid... I can't find the part of the Primer you mention -- please provide a precise reference (URL + section #).
>
> - Matt
>
[ ... ]
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
For additional commands, e-mail: users-help_at_jaxb.dev.java.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
For additional commands, e-mail: users-help_at_jaxb.dev.java.net