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


Alex Yiu wrote:

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

mm1: I think providing sufficient parameters for data manipulation are 
important. Leaving these to unspecified means could impact portability. 
I support Ron and Alex's suggestions.

>> Goland: 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.
>>
>> Ten-Hove: This is why <assign> is atomic. The intermediate states are 
>> never exposed.
>>
>>> Goland: 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.
>>
>> Ten-Hove: 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?
>




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