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