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