Hi Blaise,
> My question to you is what is the value to the user of having the public API for SDOSource/SDOResult explicitly extend the SAX counterparts (assuming there is enough industry pressure for the impls of SDOSource/SDOResult to extend the SAX counterparts)?
Having one reliable implementation vs. N implementations with their own nuances and bugs, though perhaps that's not a big win given the ugliness that it introduces into the API.
Thanks.
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org
Blaise Doughan <blaise.doughan@oracle.com>
03/23/2009 04:31 PM |
|
Hi Michael,
I think for the most part we're agreeing. My position again is as follows:
- Introduce SDOSource/SDOResult interfaces that extend Source/Result.
- Only put the API on SDOSource/SDOResult that makes sense for SDO.
- Add some factory methods to XMLHelper.
My question to you is what is the value to the user of having the public API for SDOSource/SDOResult explicitly extend the SAX counterparts (assuming there is enough industry pressure for the impls of SDOSource/SDOResult to extend the SAX counterparts)? The API inherited from the SAX classes is meaningless to the user and we would need comment SDOSource/SDOResult (like JAXBSource/JAXBResult) to tell users to ignore the API.
-Blaise
Michael Glavassevich wrote:
- SDOSource createSource(DataObject dataObject, String rootElementURI, String rootElementName);
- SDOSource createSource(XMLDocument xmlDocument, Object options);
- SDOResult createResult();
- Add an accessor to get the XMLHelper used to create the SDOSource
- Add an accessor to get the XMLDocument (the DataObject/String/String input can be represented as an XMLDocument)
- Add an accessor to get the options parameter
- Add a getContentHandler(): SDOContentHandler method.
- Hi Blaise,
> There is no arguing that implementations of the SDOSource/SDOResults APIs that I have proposed will need to extend existing Source/Result implementations (most will probably use SAX, but StAX is also a possibility).
StAX may be a possibility but you're likely to shoot yourself in the foot by choosing it. Very few frameworks recognize StAXSource/StAXResult, including the JAXB RI the last time I checked.
> Not sure I buy the argument that users need to see that SDOSource/SDOResult extends a concrete implementation before they have the confidence to use it, I think the confidence comes from the companies providing the implementations themselves.
By users I was thinking more of other frameworks / general purpose middleware which has to work with arbitrary SDO implementations (including ones which don't exist yet), though I suppose they could make themselves more robust by wrapping the code in a try/catch and falling back to XMLHelper.save()/load() --> StreamSource/StreamResult if the attempt to use SDOSource/SDOResult fails or possibly check if they implement the JAXP built-in concrete classes before passing them on.
Thanks.
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org
Blaise Doughan <blaise.doughan@oracle.com>
03/23/2009 02:09 PM |
|
Hi Michael,
I agree that JAXP frameworks in general look for concrete Source/Result objects and once you stray away from SAX/DOM/Stream you're taking your chances. A few years ago only a few supported subclasses of this core set. As part of the JAXB group I worked with a number of parsers to get them to recognize subclasses of SAXSource/SAXResult objects in order for JAXBSource/JAXBResult to work.
There is no arguing that implementations of the SDOSource/SDOResults APIs that I have proposed will need to extend existing Source/Result implementations (most will probably use SAX, but StAX is also a possibility). Not sure I buy the argument that users need to see that SDOSource/SDOResult extends a concrete implementation before they have the confidence to use it, I think the confidence comes from the companies providing the implementations themselves.
JAXBSource/JAXBResult extend their SAX counterparts because that's what it took to make them work so that they could be instantiated with constructors. This left a number of nonsensical methods that needed to be explained away with a javadoc comment. Going the factory route we have the opportunity to offer a cleaner API, as well as providing the implementor some additional flexibility.
-Blaise
Michael Glavassevich wrote:
- Hi Blaise,
I was under the impression that the motivator for adding SDOSource/SDOResult to SDO was for integration with other frameworks. Correct me if I'm misunderstanding but it seems like going to a clean API means that users of SDO wouldn't be sure that they could rely on these interfaces. Normally frameworks have a series of instanceof checks for the concrete Sources/Results they recognize/support and when the last one fails an exception is thrown. If I were writing an application which is designed to work with SDO in general I might not trust XMLHelper because some vendor's implementation could return something that blows up when I pass it to JAXB Unmarshaller/Marshaller, JAXP Transformer/Validator, etc... At least if SDOSource/SDOResult (abstract or not) extends SAXSource/SAXResult folks would have a reasonable expectation that they would work.
Thanks.
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org
Blaise Doughan <blaise.doughan@oracle.com>
03/23/2009 09:10 AM |
|
Hello Stefan & Michael,
I have been re-thinking the decision to make SDOSource and SDOResult abstract classes. In JAXB, JAXBSource and JAXBResult are concrete classes that extend their SAX counterparts. JAXB benefits from not needing a factory, but suffers from exposing meaningless public API, the best they can do is add Java doc comments stating that the users should not consider using the inherited API. If we go the factory route then we can offer the benefit of a clean API, and also the potential for implementors to offer Source/Result implementations better tuned for their implementation (on DOM, SAX, or StAX).
All we really need are the attached interfaces and some new creation methods on XMLHelper (the following are based on current XML Helper API):
If there are expectations that a SDOSource from one vendor can act as input to another vendors SDO implementation load operation we can enhance the SDOSource interface further:
public XMLDocument load(Source inputSource, String locationURI, Object options) {
if(inputSource instanceof SDOSource) {
SDOSource sdoSource = (SDOSource) inputSource;
SDOContentHandler sdoContentHandler = this.createContentHandler(options);
sdoSource.getXMLHelper().save(sdoSource.getDocument(), new SAXResult(sdoContentHandler), sdoSource.getOptions());
return sdoContentHandler.getDocument();
}
}
If there are expectations that an SDOResult from one vendor can serve as the output to another vendors SDO implementation save operation we can enhance the SDOResult interface further:
if(outputResult instanceof SDOResult) {
SDOResult sdoResult = (SDOResult) outputResult;
SDOContentHandler sdoContentHandler = sdoResult.getContentHandler();
save(xmlDocument, new SAXResult(sdoContentHandler), options);
}
}
-Blaise
Michael Glavassevich wrote:
- Hi Stefan,
"Buennig, Stefan" <stefan.buennig@sap.com> wrote on 03/20/2009 05:50:21 AM:
> Hi Michael,
>
> what do you think about this SDOResult implementation?
Looks good. That's roughly what I was thinking of.
> package commonj.sdo.helper.util;
>
> import javax.xml.transform.sax.SAXResult;
>
> import commonj.sdo.helper.HelperContext;
> import commonj.sdo.helper.SDOContentHandler;
> import commonj.sdo.helper.XMLDocument;
>
> public class SDOResult extends SAXResult {
>
> private XMLDocument document;
>
> public SDOResult(HelperContext helperContext, Object options) {
> SDOContentHandler sdoContentHandler = helperContext.
> getXMLHelper().createContentHandler(options);
> setHandler(sdoContentHandler);
> }
>
> public void setDocument(XMLDocument document) {
> this.document = document;
> }
>
> public XMLDocument getDocument() {
> if (document == null) {
> SDOContentHandler sdoContentHandler =
> (SDOContentHandler)getHandler();
> document = sdoContentHandler.getDocument();
> }
> return document;
> }
>
> }
> I'm wondering if there should be another constructor to avoid the
> initialization of the SdoContentHandler. This could be useful for
> users of the setDocument-method. Which use-case do you have in mind
> for the setDocument-method?
The library/framework writing to the SDOResult might be SDO-aware and use the setDocument() method but I generally wouldn't expect the application creating the SDOResult to know that. If you want to avoid creating the SDOContentHandler in the constructor I suppose you could cache the HelperContext/options and only create the SDOContentHandler if the getHandler() method is invoked. I'm not sure what "options" can be passed in but if they configure the behvaiour of the SDOContentHandler then they should probably be exposed from SDOResult so that a framework which produces SDO directly can match the behaviour of SDOContentHandler or choose to fall back to using the SDOContentHandler if it doesn't understand or support the options.
> Would you rather prefer an abstract class?
If I were designing SDOSource/SDOResult I probably wouldn't make them abstract but I don't feel strongly either way.
> Stefan.
Thanks.
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.orgpackage commonj.sdo.helper.util;
import javax.xml.transform.Source;
public interface SDOSource extends Source {
}
package commonj.sdo.helper.util;
import javax.xml.transform.Result;
import commonj.sdo.helper.XMLDocument;
public interface SDOResult extends Result {
XMLDocument getDocument();
}
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
