Re: [wsbpel] Issue 11 - Call for Discussion

["Yaron Y. Goland" <ygoland@bea.com>]

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.
>  >
>  >
> 
>