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:
OFBB03BBBC.D76CF3B0-ON85257582.004FA041-85257582.00512A2D@ca.ibm.com"
type="cite">
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>
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):
- SDOSource createSource(DataObject dataObject,
String rootElementURI, String rootElementName);
- SDOSource createSource(XMLDocument
xmlDocument, Object options);
- SDOResult createResult();
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:
- 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
Then the following could be done:
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:
- Add a getContentHandler(): SDOContentHandler
method.
public void save(XMLDocument xmlDocument, Result
outputResult, Object options) {
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
|