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
