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