SDO 2 uses XMLHelper for marshalling/unmarshalling to XML. The fact that it's in a helper is the way that the spec has made it an optional part of SDO - only needed by SDO users that want to serialize/deserialize their objects as XML. An SDO user that doesn't need XML support, could work in a runtime that doesn't have the XMLHelper. Now, when using XML, the XML users typically expect all of these various input types to be supported. As Daniel puts it, they're just the list of things in the JDK. Talking to Steve Brodsky, an alternative is to add a single load(InputSource ...) API to the SDO spec ... which covers all the main ways of loading XML (Apparently StAXSource is coming in JDK 1.6) ... instead of having methods for all the different argument types. Thoughts?
Frank Daniel Kulp <[EMAIL PROTECTED]> wrote on 03/20/2006 02:49:35 PM: > > Jeremy, > > > > Just FYI, the JAXB 2.0 marshaller/unmarshaller has methods for the > > > XMLStream* and XMLEvent* and such as well as those for InputSource, > > > URL, InputStream, Source, etc.... I'm not sure if you care (since > > > SDO is not JAXB), but I thought I'd mention it. > > > > This highlights the issue I was trying to avoid. As I read this (and I > > confess ignorance with JAXB) it sounds like there is *one* > > (un-)marshaller which has methods on it for different XML access APIs. > > This means that an implementation has to support *all* these different > > APIs - the "kitchen sink" approach that bloats the runtime footprint. > > Well, I'm not sure if it's really "kitchen sink". It's basically all > the formats that are part of the JDK (JDK 1.5) which is all the source > objects, the DOM, the InputSource, the URL, etc... with the addition of > StAX. For the most part, I think internally, (not really sure, I > haven't looked at the code) all they do is wrapper whatever comes in with > a StAX Event thing so the engine itself just uses StAX. The > marshaller/unmarshaller just "wraps" the incoming stuff with the > appropriate wrapper. For the most part, the XMLInputFactory (part of > StAX) contains all the methods for converting from all the other formats > to the appropriate StAX type. Thus, the JAXB runtime doesn't need to > do much. (puts the "kitchen sink" burden on the StAX runtime, not the > JAXB one) > > Obviously, that makes the JAXB runtime directly depend on StAX in ALL > cases. I'm not sure that's what you want or not, although I would vote > +1 to allowing that dependency. :-) > > Enjoy! > -- > J. Daniel Kulp > Principal Engineer > IONA > P: 781-902-8727 C: 508-380-7194 > [EMAIL PROTECTED]
