javax.xml.transform.Source and javax.xml.transform.Result seems to be the
good cadidates.
In JDK 1.4.x, there're three implementation classes for Source:
DOMSource, SAXSource, StreamSource
In JDK 1.6, there're more:
DOMSource, JAXBSource, SAXSource, StAXSource, StreamSource
Before we move the JDK 1.6, we can use our own version of StAXSource.
Raymond
----- Original Message -----
From: "Frank Budinsky" <[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Monday, March 20, 2006 2:12 PM
Subject: Re: [jira] Commented: (TUSCANY-118) Adding Serializer/Deserializer
for DataObject using StAX for better Axis2 AXIOM integration
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]
