Re: [sdo] Code for SDOSource, SDOResult and ContentHandler

[Blaise Doughan <blaise.doughan@oracle.com>]

Title: Code for SDOSource, SDOResult and ContentHandler

Hi Stefan,

Wrt the two SAX parser properties (namespaces and namespace-prefixes) I would like to see SDOSource follow what is done in JAXBSource (namespaces=true, and namespace-prefixes=false).  Our SDO customer base is JAXB knowledgeable and its easy for us to explain where SDO offers value add over JAXB, but hard when we need to explain arbitrary differences.

The assumption about the options object being a "Map" is not valid, most implementations probably use a Map but this isn't enforced by the SDO API which specifies an "Object".  Also you appear to be indirectly proposing that the following SAX properties become properties understood by a standard XMLHelper:

• http://xml.org/sax/features/namespaces
• http://xml.org/sax/features/namespace-prefixes

If the above properties are available as either standard or proprietary properties to XML save operations then why not make the user responsible for setting it (on the properties Object) themselves rather than having it added by the SDOSource object?  Then the options parameter to SDOSource could be an Object to match the one on the XMLHelper.save operation.

-Blaise

Buennig, Stefan wrote:

45E8ACF4DC4D7148AB9A906B6B216DAD01DB4FC2@dewdfe1m.wdf.sap.corp" type="cite">

<<SDOSourceResult.zip>>

Hi all,

I have implemented SDOSource and SDOResult in a way that we could have it in our API.
Please have especially a look at SDOSource. As I already mentioned, the implementation is not trivial. The code is similar to JAXBSource. Of course a little bit JavaDoc is missing.

The SDOSource implementation delegates to

XMLHelper.save(XMLDocument xmlDocument, Result outputResult, Object options)

It makes the following assumptions:

• The save-method supports a SAXResult
• A Map is supported as options-Object
• The implementation cares about the SAX-feature "http://xml.org/sax/features/namespace-prefixes". (As an alternative the implementation could always work in the proposed default mode "http://xml.org/sax/features/namespace-prefixes" = true)

Some background to the SAX-feature "http://xml.org/sax/features/namespace-prefixes":
This feature decides if QNames like "tns:elementName" are generated for the ContenHandler-calls or not. Some ContentHandlers require that feature to be true, others don't. (Xalan, Saxon require this to work well, JAXB doesn't). For ContentHandlers that do not need the QNames, the generation of prefixed names is wasted performance.

A careful consumer of a SAXSource sets the feature at the XMLReader as it is needed, but that's not always the case. That's why the proposal supports the SAX-features by an options-Map and the default mode should be "http://xml.org/sax/features/namespace-prefixes" = true to be on the save side.

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