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

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]