Re: AW: [sdo] SDOSource, SDOResult and ContentHandler

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

Title: SDOSource, SDOResult and ContentHandler

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.

• http://www.oasis-open.org/apps/org/workgroup/sdo/download.php/31882/SDO%20TC%20Meeting%20minutes%20-%20March%2031%2C%202009.txt

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.

---

Von: Blaise Doughan [mailto:blaise.doughan@oracle.com]
Gesendet: Montag, 27. April 2009 21:57
An: Buennig, Stefan
Cc: sdo@lists.oasis-open.org
Betreff: Re: [sdo] SDOSource, SDOResult and ContentHandler

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
  • No API
    
• 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 

---

Subject:

Re: [sdo] 2nd try: SDOSource, SDOResult and ContentHandler

From:

"Michael Glavassevich" <mrglavas@ca.ibm.com>

Date:

Wed, 18 Mar 2009 19:39:00 +0200

To:

<sdo@lists.oasis-open.org>

To:

<sdo@lists.oasis-open.org>

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