[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Fw: AW: AW: AW: [sdo] Methods to create XMLStreamReader and ContentHandler
Hi Guys,
Forwarding some comments on the current proposal for Issue 158. Michael is
joining the TC so that he can participate in the discussion himself.
Thanks,
Frank.
----- Forwarded by Frank Budinsky/Toronto/IBM on 03/09/2009 09:51 AM -----
Michael Glavassevich/Toronto/IBM
03/06/2009 12:18 PM
To
Frank Budinsky/Toronto/IBM@IBMCA
cc
Subject
Re: Fw: AW: AW: AW: [sdo] Methods to create XMLStreamReader and
ContentHandler
Hi Frank,
To work with frameworks which know nothing about SDO you need to extend
existing Source/Result classes from JAXP. Stream/DOM are poor choices for
performance. The StAXSource/StAXResult variant is still relatively new.
You'll find few implementations which actually support it. Currently
available versions of Apache Xerces don't (though the dev stream in Apache
SVN does). Apache Xalan doesn't. I've heard that Saxon doesn't either.
The last time I checked the JAXB RI in Java 6 also didn't support it. Even
if it were widely supported I wouldn't necessarily state "Re-use of
content-strings because XMLStreamReader provides String-based access by
String: XMLStreamReader.getText()" as an advantage for StAX. This assumes
that consumers actually call the getText() method on XMLStreamReader. I
would expect most consumers which have been performance tuned to bias
towards text XML where the transient char[] accessor (i.e.
getTextCharacters()) would generally be cheaper than getText() (usually
requires creation of new strings).
So ruling out Stream, StAX and DOM that only leaves the
SAXSource/SAXResult combo and would agree that that's the best choice
available from JAXP for extending. Assuming SDOContentHandler is added to
XMLHelper I think the implementations of SDOSource/SDOResult could be
trivial. They could just delegate to the XMLHelper for SAX
serialization/deserialization.
A down side of JAXBSource/JAXBResult is that you always have to read them
as SAXSource/SAXResult because they provide no getters/setters for the
underlying JAXB objects. It would be nice if SDOSource and SDOResult
didn't assume that the only way to get information in and out of them is
by serialization to / deserialization from SAX events. You could imagine
implementations which are aware of SDO and could have optimized paths for
JAXB, XSLT, etc... which consume the SDO directly.
I'm thinking of something along the lines of:
public class SDOSource extends SAXSource {
public SDOSource(XMLDocument doc) {}
public void setDocument(XMLDocument doc) {}
public XMLDocument getDocument() {}
}
An SDO aware consumer could recognize that the Source object is an
SDOSource and get the XMLDocument directly. A non-SDO aware consumer
would recognize this as a SAXSource and consume it as such. So you get a
default behaviour that is likely to work with a large number if not all
consumers of Source/Result today, and leave it open to more efficiently
process SDOSource/SDOResult if the consumer is aware of SDO.
Thanks.
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
Phone: 905-413-2565 T/L 313-2565
E-mail: mrglavas@ca.ibm.com
Frank Budinsky/Toronto/IBM
03/04/2009 12:42 PM
To
Michael Glavassevich/Toronto/IBM@IBMCA
cc
Subject
Fw: AW: AW: AW: [sdo] Methods to create XMLStreamReader and ContentHandler
Hi Michael,
Here is the discussion I mentioned in my other note.
This is the original attachment:: [attachment "LowLevelXML.doc" deleted by
Michael Glavassevich/Toronto/IBM]
Thanks,
Frank.
----- Forwarded by Frank Budinsky/Toronto/IBM on 03/04/2009 12:36 PM -----
"Buennig, Stefan" <stefan.buennig@sap.com>
03/04/2009 09:04 AM
To
<sdo@lists.oasis-open.org>
cc
Subject
AW: AW: AW: [sdo] Methods to create XMLStreamReader and ContentHandler
Hi Blaise,
I think, in general we are in agreement.
We still have to decide, if we want to provide a complete
SDOSource/SDOResult implementation that the user creates by constructor or
just abstract classes which are created by factory-methods in the
XMLHelper.
Full SDOSource/SDOResult implementation
If we want to provide a fully implemented SDOSource and SDOResult then all
behavior to implement these classes must be available by the official API.
This has the following implications:
SDOSource: The API of SDO needs something to fire ContentHandler-events.
This is either an XMLReader or something that is useful to implement an
XMLReader.
JAXB has Marshaller.marshal(Object jaxbElement, org.xml.sax.ContentHandler
handler) for this, we don't have a similar method.
The only way that is available by the current API to fire
ContentHandler-events is by a SAXResult:
SAXResult saxResult = new SAXResult(contentHandler);
xmlHelper.save(xmlDocument, saxResult, options);
In my opinion it is hard to find an implementation for SDOSource that
works fine with every SDO-implementation and is just based on our API.
That's why I always proposed to have a factory method for an XMLReader
too.
SDOResult: To consume the ContentHandler-events an implementation of a
ContentHandler is needed. We could use the proposed SDOContentHandler for
this.
Abstract SDOSource/SDOResult
If we defined SDOSource and SDOResult as abstract classes that extend
SAXSource and SAXResult, we could hide a lot of implementation-details
from our API. The vendors could provide their own implementation with
their own optimizations and options. In that case factory methods would be
required in XMLHelper.
I believe that it's easier to achieve an agreement for abstract SDOSource
and SDOResult.
I'm not sure if we need an extra commonj.sdo.helper.util-package.
Stefan.
Von: Blaise Doughan [mailto:blaise.doughan@oracle.com]
Gesendet: Dienstag, 3. März 2009 22:35
An: Buennig, Stefan
Cc: sdo@lists.oasis-open.org
Betreff: 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:
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:
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 SDO
Source 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]