[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 11 - It's Baaaack -*-*- other XML syntax issues
Hi, Danny and others, Besides digging deeper into Issue 11, we may also want to follow up 2 other (maybe orthogonal) syntax issues about referencing a variable in XPath in BPEL. (1) Right now, there are three BPWS (XPath) functions defined in BPEL. bpws:getVariableProperty ('variableName', 'propertyName') bpws:getVariableData ('variableName', 'partName'?, 'locationPath'?) bpws:getLinkStatus('linkName')For refering to a variable data, if data is of an XSD complex type or XSD simple type (not WSDL 1.1 type), do we want to add another way to refer to a variable on top of getVariableData Function Call? That is using "$varName" syntax. Currently, we have: "bpws:getVariableData(orderDetails) > 100"The additional way: "$orderDetails > 100"Note that:
http://www.w3.org/TR/xpath#NT-FunctionCall http://www.w3.org/TR/xpath#NT-VariableReference (2) There are typo in our BPEL examples "bpws:getVariableProperty(stockResult,level) > 100" "bpws:getVariableProperty(stockResult,level) >= 0" "bpws:getVariableData(orderDetails) > 100"I guess we need to put quotations on function parameters. It becomes: "bpws:getVariableProperty('stockResult','level') > 100" "bpws:getVariableProperty('stockResult','level') >= 0" "bpws:getVariableData('orderDetails') > 100" Do we want to open 2 issues for the above need? Thanks for reading the email. Regards, Alex Yiu [P.S.: I definitely have viewpoints on Issue 11. :-) Before I voice my concrete opinions, I need to discuss more with other Oracle internal folks first. Meanwhile, I will stay tune with the ongoing Issue 11 discussion. Thanks! ] Danny van der Rijn wrote: during today's conference call, we took a straw poll, where approximately 2/3 voted to attempt to resolve issue 11. (i'll leave the exact count to the minutes). i would like to resurrect a large part of my previous proposal (i'll drop "rename"). to me, this is a viable proposal, and i would be satisifed if it ended up being adopted into the spec. however, maybe in the months since we last thought about it, someone else has a reasonable alternative. danny My proposal: under the <assign> element, there will be 6 possible elements, where now there is only 1. <copy> <from/> <to/> </copy> as current. ----------------------------- <insertBefore> <from/> <to select="XPath Expression evaluates to one node"/> </insertBefore> creates a sibling before the select expression ----------------------------- <insertAfter> <from/> <to select="XPath Expression evaluates to one node"/> </insertAfter> creates a sibling after the select expression ----------------------------- <append> <from/> <to select="XPath Expression evaluates to one node" child="integer XPath expression"? /> <append> creates a child of select expression at the child-th position. child defaults to last(). ----------------------------- <remove select="XPath expression evaluates to one node"> removes a node 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]