RE: [wsbpel] Issue 11 - Call for Discussion

["Edwin Khodabakchian" <edwink@collaxa.com>]

Yaron,

I am curious: How does the execution of the embedded ECMA4X scriptlets
within BPEL help you address the {while+invoke+assign} validation problem?

It seems to me that simple assignment like what Danny and Alex are
suggesting should be declarative. Here is why:

1. This approach is more tool friendly than the reverse engineering of code
snippet.

2. Most of the companion languages (XBeans, JAXB, Collaxa's XML Facades)
require some type of XML-Object mapping which does not work well with more
sophisticated schema...therefore developers will have to use some type of
XPATH, DOM, etc...So you might as well do it declaratively.

3. As pointed out, this is orthogonal to type validation because some use
case: {while+invoke+receive+assign} require the incremental build out of
documents. It seems that a separate issue should be opened to track
validation (which could be addressed by doing validation only on the edges).
More generically, any logic that combines sync or async interaction and
build out of a document will not be able to be compressed into a single
activity, companion language or not.

4. The alternative approach to doing assignment using a custom XPATH
function is expensive when adding a small optional part to a large document.

5. I am not sure I understand why you think this would be such a big effort:
The proposal is a simple reflection of exiting DOM APIs, well articulated
and scoped out.

I think that we should have *clear* and simple alternatives to the (simple)
use cases driving Danny and Alex before we decide to kill it.

Best,

Edwin

-----Original Message-----
From: Yaron Y. Goland [mailto:ygoland@bea.com] 
Sent: Tuesday, March 02, 2004 3:50 PM
To: Alex Yiu
Cc: Ron Ten-Hove; Wsbpel@Lists. Oasis-Open. Org (E-mail)
Subject: Re: [wsbpel] Issue 11 - Call for Discussion

Why do you assume that the use of a companion language must be 
non-portable? If ECMA, for example, defines a standard way to call out 
to XScript (the XML enabled version of ECMAScript) from inside of BPEL 
then clearly the result is portable and standardized.

Having a XML manipulation feature that can't handle the most common XML 
manipulation use case there is, a while with inconsistent intermediate 
states, doesn't seem a worthwhile effort.

I think we need to invoke the 80/20 principle. If the XML manipulation 
feature won't meet the XML manipulation needs of 80% of the BPEL's out 
there (and the current proposal clearly will not) then is it really 
worth the effort?

		Yaron


Alex Yiu wrote:

> Hi all,
> 
> I think Yaron's usecase (while+appendChild) is a valid one, which the
> atomicity of assign cannot help much in "schema inconsistent state
> situation". :-)
> 
> However, as I mentioned before, BPEL community needs to recognize and
> agree that the 3 operations (e.g. insertBefore and appendChild)
> potentially added by issue 11 are NOT aimed to solve ALL XML
> manipulation problems. Those 3 operations are aimed at simple XML
> manipulation, NOT complicated ones.
> 
> I think it is a good idea to make simple XML manipulation possible in
> BPEL and leave complicated XML manipulation to other languages. So, we
> will NOT run into a slippery slope situation and re-invent wheels for
> other emerging standards. (e.g. XUpdate)
> 
> IMHO, it is perfectly fine for us to say some usecases of
> while+appendChild cannot be performed by the BPEL language itself. There
> may be semantic (e.g. this schema inconsistent state situation) and
> performance deficiency to perform those complicated XML manipulation in
> BPEL.
> 
> One situation that I want to avoid is:
> A user just wants to do a simple insert into an existing document. There
> is no standard mechanism that BPEL specifies to do that. That user is
> forced to choose a potentially non-portable language or language binding
> to do just this extremely simple operation. Then, BPEL will end up in a
> close-to-zero portability situation.
> 
> 
> Thanks for reading this email!
> 
> 
> 
> Regards,
> Alex Yiu
> 
> 
> Yaron Y. Goland wrote:
> 
>  >
>  >
>  > Ron Ten-Hove wrote:
>  >
>  >> This is why <assign> is atomic. The intermediate states are never
>  >> exposed.
>  >
>  >
>  > Even trivial XML manipulation tends to involve some forms of
>  > computation during the manipulation process. A classic example is a
>  > while loop that goes through a document pulling out information in
>  > order to create a new document. During the time the while loop is
>  > iterating it is likely that the new document will be in a schema
>  > inconsistent state. Assign's atomicity is of no use here since there
>  > is no way to shove a while loop into an assign.
>  >
>  > More generally, any XML manipulation which is not strictly linear and
>  > involves schema inconsistent intermediate states cannot be dealt with
>  > in BPEL since assign cannot contain decision or iteration logic.
>  >
>  > Therefore if one wants to enable even simple XML manipulation in BPEL
>  > one inevitably ends up having to create some kind of transacted schema
>  > free zone. I'm suggesting we don't want to go there.
>  >
>  >> Is it your assertion that we should create a standard that MUST be
>  >> supplemented by an unspecified companion language, in order to create
>  >> executable processes?
>  >>
>  >
>  > Not at all. There are many ways to make BPEL work on its own. But I am
>  > asserting that BPEL should focus on the areas that it adds value and
>  > not re-invent functionality that is widely available in a standardized
>  > form.
>  >
>  >> -Ron
>  >>
>  >
>  > To unsubscribe from this mailing list (and be removed from the roster
>  > of the OASIS TC), go to
>  >
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.
php.
>  >
>  >
> 
> 

To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.
php.