Re: [wsbpel] Issue 11 - Call for Discussion

[Alex Yiu <alex.yiu@oracle.com>]

Hi, all,

I think Ron's assignment atomicity is a good point.

Just want to supplement with some data points for consideration:

XQuery actually has 2 facets: (1) one is the data is strongly typed and 
associated with schema type and etc. (2) the other is the data being 
constructed are typeless.

E.g. the following is perfect runnable XQuery expression, which XQuery 
engine does not need get any type information on <foo>
--------------------
<foo>
for $x in $j/somexpath where ... return $x
</foo>
--------------------

Here is the XPath 2.0 and XQuery 1.0 type hierarachy diagram:
http://www.w3.org/TR/2003/WD-xpath-functions-20031112/XPathTypeHierarchySm.jpg

The yellow part in the diagram is handling the type-less situation, 
which is essentally DOM!

I expect XUpdate would try to continue the same type hierachy and try to 
be symmetrical to XQuery in terms of dealing with BOTH type-ful and 
type-less data.

I guess it is over-simplified to say XUpdate is a type-ful update 
language without mentioning the type-less data situation.

It has been always the responsibility of a BPEL implementation to handle 
transition from type-less data to type-ful data on the language 
boundary. (e.g finding out schema type of an XPath 1.0 selection result.)

And, XPath 1.0 is a language without XML Schema Type concept either.
Does it mean we should exclude XPath 1.0 also?

Another data point is: the *first public draft* of W3C XUpdate would not 
be available until the last quarter of 2004.

As long as we restraint ourselves from solving the "world-hunger" 
problem in the XML data manipulation context, I think we are safe to add 
3 new operations.


Regards,
Alex Yiu



Ron Ten-Hove wrote:

> Yaron Y. Goland wrote:
>
>> DOM is a completely untyped API. BPEL is a heavily typed language. 
>> The two don't go well together. As soon as someone needs to perform a 
>> manipulation that requires two or more steps, the intermediate steps 
>> placing the target variable in an inconsistent state, BPEL's typing 
>> rules will be violated. This then leads us to introducing some kind 
>> of magic scope where the validation rules aren't enforced. But that 
>> leads to the problem of what happens if a fault occurs inside of the 
>> magic scope? This then leads us to introduce transactions into BPEL. 
>> Yuck.
>
>
> This is why <assign> is atomic. The intermediate states are never 
> exposed.
>
>>
>> As for XUPDATE, its mandate is to deal with how to perform XML 
>> manipulations in heavily typed environments. Therefore it is a much 
>> better match for BPEL's needs than the DOM and therefore when it is 
>> released it will probably quickly replace DOM usage in BPEL.
>>
>> As for companion languages, for a companion language to BPEL to be 
>> useful it must be able to see and manipulate BPEL variables. So it 
>> seems reasonable to expect to be able to drop down into the companion 
>> language, manipulate the BPEL variables using the companion 
>> language's XML manipulation facilities and then pop back up into BPEL.
>
>
> 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?
>
> -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. 
>
>