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