[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: AW: [sdo] Code for SDOSource, SDOResult and ContentHandler
Hi Blaise,
> I
would like to see SDOSource follow what is done in JAXBSource (namespaces=true,
and namespace-prefixes=false).
The "http://xml.org/sax/features/namespace-prefixes" = false would mean that the generation
of prefixed element names is not necessary for the ContentHandler. I found out
that the Transformer in JDK 6 produces invalid XML in a StreamResult if
QNames are not generated. That's why I proposed to support this as an option or
have "http://xml.org/sax/features/namespace-prefixes" = true as
default.
>
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.
Some
SAXSource consumers modifiy the flag directly at the by
SAXSource.getXMLReader().setFeature("http://xml.org/sax/features/namespace-prefixes", true/false)
In
that case your approach wouldn't work. We had no standard way to translate this
as an option. The option would get lost.
I was
always surprised that the other teams would prefer a concrete SDOSource
implementation rather than an abstract class.
I'm
afraid that we will not be able to find a common implementation that fits all
vendors needs and all legal concerns.
As a
chance the keep the idea of a concrete implementation alive I can repeat my
proposal to have a XMLReader-factory method at the XMLHelper. This XMLReader
could be used to implement the SDOSource. The factory method could hide all the
vendor specific stuff.
The
only other solution I see is to have abstract SDOSource/SDOResult classes and
factory-methods.
Stefan.
Von: Blaise Doughan [mailto:blaise.doughan@oracle.com] Gesendet: Dienstag, 17. März 2009 13:29 An: Buennig, Stefan Cc: sdo@lists.oasis-open.org Betreff: Re: [sdo] Code for SDOSource, SDOResult and ContentHandler 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: 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"> |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]