Ryan,
Thank you very much for your reply.
> You hit the nail on the head - performance and flexibility.
I don't think you get my point. Did you understand that when I talked
about the "flexibility" to write invalid XML, I was speaking
sarcastically? If you could, please review the original email I sent on
this thread, and reply.
> API's should be flexible enough to allow people to do
> what they want, be it valid or invalid xml.
OK. Let's take a poll. Everyone who wants to use JAXB to generate
invalid XML, raise your hand ;) Seriously, I'd like to know the use
case for that...
I understand the need to turn the validation mechanism "off" for
performance reasons. Nonetheless, the framework should be designed to
create valid XML, and should make it easy for the programmer, using
*familiar OO techniques*, to generate valid XML. It should be *hard* if
not *impossible* for the developer using JAXB-generated classes to
marshal invalid XML, even when the explicit validation mechanism is
turned off. This is just good design, IMO, and I don't think there
should be a performance hit for this at all.
As my prior example shows, the JAXB RI is *unnecessarily* creating
code that is counter-intuitive to use and conflicts with the common
usage patterns for OO inheritance. This *is* an ease of use problem,
and it is an important one. JAXB (like most computer technology) exists
purely to provide convenience and "ease of use" compared to its
alternatives (DOM, SAX, etc.) Of course I can do a Validator.validate()
or whatever and find out that my object graph is invalid. But what
about all the code that comes before that? This is the real problem. I
want a framework that uses predictable (and sensible) polymorphism (in
the java classes), or no polymorphism at all.
Or maybe I'm wrong. I have yet to hear a sufficient, specific
explanation for the described behavior, nor any examples of frameworks
that do what I'd expect. Are there any? Also, this isn't just a rant
-- I am willing to be wrong here, and I am willing to help fix
bugs/problem solve/etc. if necessary.
- Matt
-----Original Message-----
From: Ryan Shoemaker - JavaSoft East [mailto:Ryan.Shoemaker_at_Sun.COM]
Sent: Tuesday, June 29, 2004 12:18 PM
To: users_at_jaxb.dev.java.net
Subject: Re: Polymorphism problems
Matt Munz wrote:
> 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 ? ;)
>
You hit the nail on the head - performance and flexibility. The JAXB
expert group decided that validation had to be optional because it is
such an expensive operation. In many cases, the design cycle only
relies on validation during development. When the application is
deployed, validation is disabled to achieve higher throughput. There
are many other reasons to make it switchable. For example, validation
may occur in another phase before the XML even reaches JAXB, so you
wouldn't want to validate again during unmarshal.
As far as ease of use goes, I tend to think that validation in JAXB is
easy - a boolean on the unmarshal side and a call to validate() before
marshalling. API's should be flexible enough to allow people to do
what they want, be it valid or invalid xml.
Thanks,
--Ryan
---------------------------------------------------------------------
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