Re: [jira] Commented: (TUSCANY-118) Adding Serializer/Deserializer for DataObject using StAX for better Axis2 AXIOM integration

[Frank Budinsky <fr...@ca.ibm.com>]

Here is what I just found out the SDO 2.1 spec will say about this:

Upcoming SDO 2.1 functionality - addition to XMLHelper:
  XMLDocument load(Source inputSource, String locationURI, Object options) 
throws IOException;
  void save(XMLDocument xmlDocument, Result outputResult, Object options) 
throws IOException;

Source and Result are standard parts of JDK 1.4 in the javax.xml.transform 
package. They represent a way to refer to an XML document independent of 
the parser or stream technology. This is part of JDK 1.4 so it introduces 
a JDK 1.4 dependency in SDO. There are implementations of the Source and 
Result APIs for DOM, SAX, and Streams in JDK 1.4, and in the future (JDK 
1.6) there is StAX. Since Source/Result are interfaces, then there can be 
any number of implementations. The requirement would be for an 
implementation of SDO to support at a minimum the Source/Results that are 
part of whatever level of the JDK the SDO implementation pre-reqs.

Frank.

Jeremy Boynes <jb...@apache.org> wrote on 03/20/2006 05:47:28 PM:

> Frank Budinsky wrote:
> > 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.
> 
> I think this is the crux of the matter. I think a user will expect an
> implementation to support /any/ variation rather than /all/ variations.
> This reflects a typical usage pattern where an application uses a
> particular XML interface API (e.g. DOM) rather than all of them (DOM
> some places, SAX others, etc.).
> 
> > 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.
> 
> I don't think users want a single method that does everything - I think
> they prefer something that integrates well with the API they are already
> using. I mean, the ultimate is flexibility is load(Object) but I would
> not consider that to be useful.
> 
> The key realization here is that the API should not attempt to
> hide/abstract away the different interfaces to XML documents. Instead it
> should embrace each one and fully exploit its capabilities.
> 
> Getting concrete, I would suggest that instead of a single XMLHelper
> there should be individual ones for each technology: DOMHelper,
> SAXHelper, StAXHelper, XMLBeansHelper, CastorHelper and so forth.
> 
> --
> Jeremy