Thanks for the clarifications, Joe. I've got a couple of comments inline. - Dennis
Joseph Fialli wrote: >On Mon, 1 Apr 2002 11:00:36 -0800, Dennis Sosnoski <[EMAIL PROTECTED]> wrote: > >>The new approach looks a lot like Castor and the rest - the binding uses >>JavaBeans or equivalents, the framework builds the beans (as opposed to >>the objects building themselves in the current EA version), >> > >The new approach allows for either the old style implementation >that embeds the framework in the object or for the framework to >build the bean. The extra level of indirection at the user >API level allows for both implementation strategies without forcing >the implementation decision in the user api. Additionally, >this architectural change allows for future support of binding >existing JavaBean class(es) to a generated XML Schema. > I have a hard time understanding how a single approach can allow both forms of implementation - if it does, I'm very glad to hear it. From my notes your presentations only discussed JavaBean binding with the objects constructed by the framework. Your response to my question on this point at the BOF also did not mention that an embedding implementation would still be possible. >>validation >>is handled in the setter methods of the beans. >>They're also planning to >>*require* SAX2 parser support, a really strange requirement; >> > >Actually, "require" is too strong a statement to make at >this phase of the specification effort. This could be >relaxed to an "optional" capability based on future feedback. > My wording was based on your presentations, in which you stated that the API would allow the user to specify a SAX2 parser to be used by the implementation. Here again, if it's to be changed to an optional capability I think this would be an excellent step. If it's not optional this forces the implementation to support a SAX2 parser interface and makes it really awkward to use anything else - the implementation would need to essentially duplicate the same functionality in an entirely different manner. As for the rest of it, I look forward to seeing the next version of the JAXB specification. I think the work being done on this is very valuable, and I don't mean to in any way discourage people from using it once it becomes available. The current EA code sounds like a dead end, though, unless Sun chooses to make it open source - it's not licensed for anything other than evaluation use, and we know that the APIs are going to be completely different in the next version of JAXB. That's why I recommended that anyone looking for data binding now should avoid the current JAXB EA version. Do you disagree on this? ___________________________________________________________________________ To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff SERVLET-INTEREST". Archives: http://archives.java.sun.com/archives/servlet-interest.html Resources: http://java.sun.com/products/servlet/external-resources.html LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
