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 103 - Proposed amendmants


Satish Thatte wrote:

>Assaf,
>
>You wrote:
>______
>
>The proposal for issue 103 decides to take the long route and force 
>implementations to create fake documents and elements, which creates 
>unnecessary complexity.
>
>I propose that we use the available mechanisms in XPath/XQuery to handle
>
>BPEL variable content.
>
>______
>
>I like the spirit of what you are saying.  But what exact modification
>to the proposal are you suggesting?
>
>Satish
>  
>
Section 9 that deals with data handling. In brief:

The value of a BPEL variable declared as a simple type is represented as 
a single text node. An XPath variable or function that returns the value 
of that variable, returns that text node. An assignment to the variable 
must provide a single text node, or a value that can be converted to a 
text node (e.g. a boolean value, integer value, string value).

The value of a BPEL variable declared as an element is represented as an 
element node. An XPath variable or function that returns the value of 
that variable, returns that element node. An assignment to the variable 
must provide a single element node of the same or compatible type.

The value of a BPEL variable declared as a complex type is represented 
as a sequence of elements. An XPath variable or function that returns 
the value of that variable, returns a root node. The elements that make 
up the variable value are the children of that root node. An assignment 
to the variable must provide a root node, the child nodes of which must 
match the content model of the complex type. For example, the root node 
of another complex type variable, or an element variable with the a 
compatible content model.

The same treatment is given to message parts when accessed individually 
(variable, function, assignment), when they are a simple type, complex 
type or element. When accessing the entire message content, treat the 
variable as a complex type, consisting of all the nodes that make up the 
individual message parts.

Assaf


>-----Original Message-----
>From: Assaf Arkin [mailto:arkin@intalio.com] 
>Sent: Tuesday, March 08, 2005 3:49 AM
>To: Alex Yiu
>Cc: wsbpeltc; Yaron Y. Goland; Diane Jordan
>Subject: Re: [wsbpel] Issue 103 - Proposed amendmants
>
>I) Back in the days I raised an issue (Issue 29) with the use of XPath 
>functions to access BPEL variables. In order to perform static analysis,
>
>it is helpful to know which variables are accessed in the expressions 
>used by the process. Since variable names are passed by value to 
>functions, some fancy XPath parsing is required to identify all the 
>variable names. And that is, assuming variable names can be determined 
>at design-time.
>
>For example:
>
>getVariableData( getVariableData( 'varname' ) )
>
>The actual variable being accessed will depend on the value of the 
>variable 'varname' at run-time. Such an expression cannot be statically 
>analyzed to determine which variables are being used.
>
>However, if we decide to use XPath variables to access BPEL variables, 
>life becomes simpler. One can easily determine which variables will be 
>accessed in a given expression by asking the XPath engine, and there are
>
>no run-time surprises.
>
>The current proposal for 103 solves this problem when accessing 
>variables directly. However, properties are still accessed using 
>functions, and since properties are derived from variables, by extension
>
>variables are still accessed using functions. Satish proposed before 
>that we use a naming scheme to create XPath variables that access 
>message parts. I suggest we extend this proposal to cover properties, 
>and devise a naming scheme to access properties using XPath variables, 
>thereby solving the static analysis problem.
>
>
>II) One of the issues XPath had to deal with (from back when it was part
>
>of XSLT) was the fact that you can't always use complete XML documents. 
>Well-formed XML documents are great for sending and storing data, but 
>for data manipulation you need to work with individual nodes, or 
>document fragments. So XPath 1.0 came up with the notion of a 'root 
>node', which XPath 2.0/XQuery 1.0 renamed to 'document node', but kept 
>the same semantics.
>
>The root/document node has two interesting properties:
>
>1. True to its name, it's the top-most node and there's nothing above 
>it. Which means you can always get back to it with a '/'.
>2. It can contain any number of child nodes and they can be any type.
>
>When you use the root/document node to access BPEL variables, you end up
>
>with three cases:
>
>1. The BPEL variable is a simple type. The rood/document node contains 
>the value of that variable in the form of a text node (a valid 
>root/document node).
>
>2. The BPEL variable is an element. The root/document node contains the 
>value of that variable in the form of an element (a valid root/document 
>node).
>
>3. The BPEL variable is a complex type, a sequence of zero or more 
>elements. The root/document node contains the value of that variable in 
>the form of a node that contains these elements. For example, the 
>root/document node can be a DOM Level 1 DocumentFragment.
>
>It seems that XPath/XQuery and DOM (as most other XML APIs) are well 
>equipped to deal with these three BPEL variable types. As well as 
>message types, which happen to be a combination of these three variable 
>types. There is no need to devise new mechanisms, since we already have 
>specifications and available implementations to support our use cases. 
>The proposal for issue 103 decides to take the long route and force 
>implementations to create fake documents and elements, which creates 
>unnecessary complexity.
>
>I propose that we use the available mechanisms in XPath/XQuery to handle
>
>BPEL variable content.
>
>
>III) Another issue I raised (Issue 28) deal with join conditions. As 
>with other expressions, I wanted join conditions to yield to static 
>analysis, and one way to achieve that is by replacing XPath functions 
>with XPath variables. The proposal for issue 103 does exactly that.
>
>However, it mandates that join conditions derive the full power of 
>XPath, which enables us to support "interesting" join conditions, for 
>example:
>
>joinCondition=" floor( 2.4 )"
>joinCondition=" string-length( $myLink ) > 4"
>
>I don't feel a compelling need to support these use cases. In fact, the 
>restrictions we have in the current spec support all the valid use cases
>
>for join conditions, effectively allowing all boolean tests on any 
>combination of link status. With such restrictions one doesn't have to 
>wonder what kind of link status would lead to the activity being 
>executed. In addition, it is possible for a smart implementation to 
>easily determine the truth value of a join condition even before all 
>link status have been determined.
>
>For example, if the join condition is '$X and $Y' and the status of link
>
>X is known to be false, then an XPath expression cannot evaluate the 
>condition, but a smarter implementation can easily determine it will 
>never evaluate to true.
>
>I propose that we retain the current restrictions we have in the spec, 
>which are ment to limit join conditions to boolean tests on link status,
>
>and simply replace the use of XPath functions with XPath variables.
>
>assaf
>
>
>Alex Yiu wrote:
>
>  
>
>>Hi, all,
>>
>>Here is the updated version of Issue 103 proposal from Yaron and I.
>>Thanks!
>>
>>
>>Regards,
>>Alex Yiu
>>
>>
>>-----------------------------------------------------------------------
>>    
>>
>-
>  
>
>>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_workgr
>oup.php.
>  
>
>
>
>  
>

begin:vcard
fn:Assaf Arkin
n:Arkin;Assaf
org:Intalio
adr;dom:;;1000 Bridge Parkway Ste 210;Redwood City;CA;94065
email;internet:arkin@intalio.com
title:Chief Architect
tel;work:(650) 596-1800
x-mozilla-html:TRUE
url:http://www.intalio.com
version:2.1
end:vcard

S/MIME Cryptographic Signature



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