7C3EF93EEBC6EB4A8B4470853DE86566AEBDA8@dewdfe18.wdf.sap.corp"
type="cite">
Hi Blaise,
I'm wasn't aware that Frank's
opinions automatically become resolutions. ;-) For what it's worth, I
do remember that Stefan removed the methods for the next call, and,
during the discussion, Frank retracted his objections to the methods.
Didn't seem to make the minutes, though.
I don't think Stefan's example
necessarily relies on projection... Imagine that the SDOAwareFramework
is some kind of cross-vendor CopyHelper that looks at the objects in
the source document, and creates objects of the corresponding types
using the target HelperContext. With the API as Stefan proposes it,
the CopyHelper "transform" could be written with the standard SDO API.
That is, the SDOAwareFramework could be written by a third vendor.
I think there is also a use case
where the SDO's on both sides are the same (ie, from the same vendor),
but the framework component is from a different vendor. That is, the
framework component could rely on projection working.
I agree that setDocument on
SDOResult has somewhat an SPI character, since it is meant to be called
by the "middleman" component, not by the consumer of the SDOResult. So
I guess the real question is only whether the functionality offered by
the API is worth the potential confusion to users. As far as behavior
is concerned, in answer to your questions, we see the setter as simply
being a setter. Whatever value the user sets will be returned by the
next get.
GetHelperContext() on SDOResult
is necessary if we are going to have setDocument(). I agree that
getHelperContext() on SDOSource is only a convenience method, really
provided only for symmetry with SDOResult.
Hopefully, we will get this
decided during today's call.
Best Regards,
Ron
Hi Stefan,
In the minutes from March 31st after discussing Michaels email there is
some mention by Frank that we may not need setDocument on SDOResult.
At this point it is my understanding that projection is only guaranteed
to work between SDO implementations belonging to the same vendor. As
such your optimization is only useful if the SDOResult is also from
that same implementation. Therefore the same optimization can be
obtained by down casting to the specific implementation of SDOResult
and calling a vendor specific setDocument method.
If we put the setDocument (which is really an SPI) method on SDOResult
we would need to address the following issues:
- What happens if the user calls setDocument and them uses the
SDOResult in a transformation? Is it a no-op or is the document
replaced?
- What happens if the user calls setDocument with an XMLDocument
from another vendor? Is an exception thrown or something vendor
specific?
Sounds like we want to expose the HelperContext from
SDOSource/SDOResult. The difference between options #2 & #3 below
is how the HelperContext is obtained. We can either expose it through
a getHelperContext() method or leverage the getHelperContext() method
on Type that is being proposed as part of the HelperContext creation
API.
-Blaise
Buennig, Stefan wrote:
45E8ACF4DC4D7148AB9A906B6B216DAD02145A57@dewdfe1m.wdf.sap.corp"
type="cite">
Hi Blaise,
it was not my understanding that
we all agreed that setDocument is not necessary. I tried to respect
Michaels proposal. (see attached mail)
In Michaels use-case an
SDO-aware framework is able to handle DataObjects directly and creates
the XMLDocument. For this use-case the methods getHelperContext() and
setDocument(...) are necessary at SDOResult.
Example: SDOawareFramework.transform(Source,
Result);
Parameters: SDOSource and
SDOResult
SDOSource.getDocument() ->
some modifications ->
SdoResult.getHelperContext()
->
optional: projection into the
HelperContext ->
HelperContext.getXMLHelper().createDocument(...)
->
SDOResult.setDocument(...)
In my opinion it's worth having
these methods in the interface to support this use-case.
Your Option#3: I think it's ok
to expose the options to the interface too.
Stefan.
Hi Stefan,
I thought we had all agreed that only the supplier of the SDOResult
Implementation could make use of the setDocument API, so that method is
not required as the implementation could cast to their own
implementation class. I think the following options for API exist:
Option #1 - SDOSource/SDOResult Minimal API
The following is the bare minimum API that is required. An
SDOSource from one implementation can serve as input to another
implementation, but there is no public API available to SDO savvy
applications to optimize this process.
- SDOSource
- SDOResult
- XMLDocument getDocument();
Option #2 - SDOSource/SDOResult Minimal API & Accessors
The following API builds on option #1, accessors have been
added to get the parameters used in the createSDOSource/SDOResult
methods. Assuming API is added to SDO 3 that allows you to get the
HelperContext from a DataObject, then some optimizations could be done.
- SDOSource
- XMLDocument getDocument();
- Object getOptions();
- SDOResult
- XMLDocument getDocument();
- Object getOptions();
Option #3 - SDOSource/SDOResult Full API & Accessors
If SDO 3 does not add API to get the HelperContext from a DataObject
then additional API would need to be added to get the HelperContext or
XMLHelper.
- SDOSource
- XMLDocument getDocument();
- Object getOptions();
- HelperContext getHelperContext() or XMLHelper
getXMLHelper()
- SDOResult
- XMLDocument getDocument();
- Object getOptions();
- HelperContext getHelperContext() or XMLHelper
getXMLHelper()
-Blaise
Buennig, Stefan wrote:
45E8ACF4DC4D7148AB9A906B6B216DAD02145819@dewdfe1m.wdf.sap.corp"
type="cite">
Hi all,
here is a proposal for SDOSource,
SDOResult and SDOContentHandler.
<<SDOSourceResult4.zip>>
The zip contains the API including
JavaDoc and the related chapters in spec as Word-doc.
If my English sounds German don't
hesitate to correct me ;-)
Stefan.
---------------------------------------------------------------------
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
Hi Stefan,
One comment on SDOResult:
To allow applications to work with SDO directly I would have
expected a setDocument() method on SDOResult. This would allow an
SDO-aware application to bypass the SAX events like they would be able
to with SDOSource.
Thanks.
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org
"Buennig, Stefan" <stefan.buennig@sap.com>
wrote on 03/18/2009 11:10:26 AM:
> Hi all,
> this is the new Code for SDOSource, SDOResult and the
interfaces for
> SDOContentHandler and XMLHelper.
> As we agreed in the call, SDOSource is an abstract class
now.
> Because of the implementation of SDOResult is trivial, I kept the
> concrete implementation.
> XMLHelper has factory methods for both SDOSource and
SDOResult to besymmetric.
> XMLHelper has a factory method for the new SDOContentHandler.
> The options-parameters aren't Maps anymore but Objects as
in the
> existing methods.
> Stefan.
>
>
---------------------------------------------------------------------
> 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
---------------------------------------------------------------------
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