OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sdo message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: AW: AW: [sdo] Methods to create XMLStreamReader and ContentHandler


Hi Stefan,

During this mornings call I could not tell if we were in agreement or not.  Below are my current thoughts:

SDOSource and SDOResult
  • These are classes we want.
  • If everyone is fine with them extending SAXSource and SAXResult (like JAXB does) then we can include the implementation right in SDO.  But if implementors want the freedom to implement them in other ways then we could have API on XMLHelper to create them.
  • For the package name maybe "commonj.sdo.helper.util"?
SDOContentHanlder
  • This is a class we want.
  • It would be created from XMLHelper using the following API:
    xmlHelper.createContentHandler()
  • For the package name maybe "commonj.sdo.helper"?
SDO impls of XMLReader and XMLStreamReader
  • These would not be part of the SDO public API, and implementors would not be required to implement them.

-Blaise


Blaise Doughan wrote:
49AD3AFE.40505@oracle.com" type="cite"> Hi Stefan,

SDOSource and SDOResult

My preference would be to have SDOSource and SDOResult as concrete classes that extend SAXSource and SAXResult (just as JAXB does).  I proposed the interface and creation APIs because I thought SAP wanted the ability to implement these classes using StAX


SDOContentHandler

This would be a useful class (based on my experience with JAXB) if the XML is being processed by a SAX parser.  This allows the user to work directly with a parser allowing them to enable such options as validation of the incoming XML against an XML schema.

    SAXParserFactory spf = SAXParserFactory.newInstance();
    SAXParser sp = spf.newSAXParser();
    XMLReader xmlReader = sp.getXMLReader();

    SDOContentHandler sdoContentHandler = xmlHelper.createContentHandler();
    xmlReader.setContentHandler(sdoContentHandler);
    InputSource inputSource = new InputSource(...);
    xmlReader.parse(inputSource);
    XMLDocument xmlDocument = sdoContentHandler.getDocument();


SDO impls of XMLStreamReader and XMLReader

These are XML parsers, in particular XMLReader (SAX) takes in XML content and reports SAX events to ContentHandlers.  Implementing this with SDO extensions would require extending a concrete implementation or throwing method not supported exceptions on undesirable methods.  I can see how these could be used to implement SDOSource/SDOResult, but do not see them being useful public APIs.

-Blaise

Buennig, Stefan wrote:
45E8ACF4DC4D7148AB9A906B6B216DAD01CD2EE5@dewdfe1m.wdf.sap.corp" type="cite">
Hi Blaise,
 
I proposed SDOSource and SDOResult as classes to have a more concrete spec. If we would extend SAXSource and SAXResult the users could have more concrete expectations about performance and memory consumption.
On the other hand I agree SDOSource and SDOResult as interfaces is also a possible option. May be we could easier achieve a consent if we would define interfaces.
 

package commonj.sdo.helper;
import javax.xml.transform.Source;

public interface SDOSource extends Source {

}

(There is no real extension. Is there a need for an SDOSource just for symmetry?)

package commonj.sdo.helper;
import javax.xml.transform.Result;

public interface SDOResult extends Result {

    XMLDocument getDocument();

}

I like the factory-methods on XMLHelper you proposed, but I see the need of an options parameter.

If we define SDOSource and SDOResult in that abstract way and you say it is too complex to require an XMLStreamReader or XMLReader implementation then I do not see any reason to require a SDOContentHandler-implementation. In my opinion XMLStreamReader, XMLReader and SDOContentHandler are on the same level of abstraction and complexity. That's why we should rather require non of them than force implementations to have a SAX-based parser.

Stefan.



Von: Blaise Doughan [mailto:blaise.doughan@oracle.com]
Gesendet: Donnerstag, 26. Februar 2009 14:22
An: Buennig, Stefan
Cc: sdo@lists.oasis-open.org
Betreff: Re: AW: [sdo] Methods to create XMLStreamReader and ContentHandler

Hi Stefan,

If SDOSource and SDOResult were interfaces then vendors could implement them as they saw fit.  We could add the following creation methods to XMLHelper, possibly with an additional options parameter. 
  • public SDOSource createSDOSource(XMLDocument xmlDocument);
  • public SDOSource createSDOSource(DataObject dataObject, java.lang.String rootElementURI, java.lang.String rootElementName);
  • public SDOResult createSDOResult();

Also, shouldn't SdoContentHandler  be SDOContentHandler to be consistent with the other SDO classes (XMLHelper, XSDHelper, even the proposed SDOSource and SDOResult)?

-Blaise

Buennig, Stefan wrote:
Hi Blaise, hi all,
 
SDOSource and SDOResult would be a good way to communicate with other frameworks as JAXB or javax.xml.transform.Transformer.
To be understood by other frameworks, we have to extend an existing well-supported Source and Result.
 
Well supported Sources and Results are:
 
StreamSource and StreamResult,
DOMSource and DOMResult,
StAXSource and StAXResult,
SAXSource and SAXResult.
 
StreamSource and StreamResult
A stream-based approach is not very efficient because it requires always a full serialization or deserialization.
 
DOMSource and DOMResult
This approach requires DOM as interim format. Because of most SDO implementations are not based on an internal DOM representation this would be not efficient.
 
StAXSource and StAXResult
This can be implemented in an efficient way, but it requires some implementation effort by SDO vendors.
The StAXSource implementation requires the XMLStreamReader-implementation I proposes in the XMLHelper interface.
The StAXResult would require an XMLStreamWriter that creates directly an SDO tree.
StAXSource and StAXResult require JAVA 6! (A StAX library is not enough.)
 
SAXSource and SAXResult
This is the way JAXB has chosen.
An SAXSource can be stream-based or XMLReader-based. As mentioned above, a stream-based approach is not very efficient.
The more efficient way requires the implementation of an XMLReader as I proposed in the XMLHelper interface. JAXBSource has chosen that way too.
The SAXResult requires the SdoContentHandler, I proposed in the XMLHelper interface. JAXBResult goes a similar way.
 
As a compromise we could say that we implement SAXSource and SAXResult, but let the vendors decide, if they implement the SAXSource the stream-based or the XMLReader-based way.
 
Stefan.


Von: Blaise Doughan [mailto:blaise.doughan@oracle.com]
Gesendet: Dienstag, 24. Februar 2009 17:49
An: Buennig, Stefan
Cc: sdo@lists.oasis-open.org
Betreff: Re: [sdo] Methods to create XMLStreamReader and ContentHandler

Hi Stefan,

I like SDOContentHandler and the idea of SDOSource and SDOResult, these align well with their JAXB counterparts.  I'm not so sure about the SDO implementations of XMLReader and XMLStreamReader which roughly equates to writing SAX and StAX parsers that act on SDO input.  The implementation of these does not appear trivial to write.

-Blaise

Buennig, Stefan wrote:

Hi all,

as agreed in the F2F here is a first proposal for the interfaces to create XMLStreamReader and ContentHandler:

<<LowLevelXML.doc>>

It is not a finished proposal but rather a base for discussions.

Stefan

Stefan Bünnig
Senior Developer
NW Core JS&I Tools Berlin (AG)
SAP AG
Rosenthaler Straße 30

10178 Berlin
T   +49 30 41092-608
F   +49 6227 78-42807
M  +49 172 3088-367

mailto:stefan.buennig@sap.com
www.sap.com

Sitz der Gesellschaft/Registered Office: Walldorf, Germany
Vorstand/SAP Executive Board: Henning Kagermann (Sprecher/Co-CEO), Léo Apotheker
(Sprecher/Co-CEO), Werner Brandt, Erwin Gunst, Claus Heinrich, Bill McDermott,
Gerhard Oswald, John Schwarz, Jim Hagemann Snabe

Vorsitzender des Aufsichtsrats/Chairperson of the SAP Supervisory Board: Hasso Plattner
Registergericht/Commercial Register Mannheim No HRB 350269

Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige vertrauliche
Informationen enthalten. Sollten Sie diese E-Mail irrtümlich erhalten haben, ist Ihnen eine
Kenntnisnahme des Inhalts, eine Vervielfältigung oder Weitergabe der E-Mail ausdrücklich
untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen
Dank.

This e-mail may contain trade secrets or privileged, undisclosed, or otherwise confidential
information. If you have received this e-mail in error, you are hereby notified that any review,
copying, or distribution of it is strictly prohibited. Please inform us immediately and destroy
the original transmittal. Thank you for your cooperation.


--------------------------------------------------------------------- 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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]