OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [wsbpel] Issue 11 - Call for Discussion


I knew that XScript will come up in this discussion thread. :-)
When I said "a potentially non-portable language or language binding", I should have emphasized more on the binding part. Even if one language is portable and standardized, it does not mean the embedding of such a language is portable and standardized. E.g. both Java and SQL are standardized, it does not mean embedding SQL in Java automatically standardized. That is why Oracle standardized SQLJ through ANSI explicitly.

However, if BPEL invokes the services of another language through a (local) WSDL, then that is another case. The language binding is more portable in that case.

One of the major reasons that made me changed from "neutral" to "for" Danny's suggestion is his argument about we have not reached any form of plateau yet in terms of <assign> functionality. Currently, assign has "replace" semantics only, but not "insertBefore", "appendChild" and "remove". If assign has those 3 operations, then we at least reach the plateau of DOM API in structure modification sense.

If assign with replace,  insert, append, remove functionality did NOT fulfill the 80/20 rule, then assign with replace only will sure do not fulfill the 80/20 rule. Why would we settle with a even smaller % of functionality coverage?? If X% was bad, why (X-Y)% is better???

Once we reach the plateau of DOM-API equivalent in BPEL 1.1 cycle, it would let us have a better foundation to leverage XUpdate in BPEL 1.X cycle in future. Because, we would have a better experience on what users want to do in terms of XML manipulation.

Another data point to consider: Most of XML DB vendors have DOM modification support today before similar support got standardized in upcoming XQuery-Update (aka XUpdate) and SQL/XML (aka SQLX) standards. The future functions in those standards do NOT invalidate in the usage experience of DOM API today.

Thanks for reading the email again!

Alex Yiu

Yaron Y. Goland wrote:
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?


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

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!

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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]