45E8ACF4DC4D7148AB9A906B6B216DAD01C324B5@dewdfe1m.wdf.sap.corp"
type="cite">
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.
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:
45E8ACF4DC4D7148AB9A906B6B216DAD01C319F4@dewdfe1m.wdf.sap.corp"
type="cite">
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