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 - 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:
  • the additional syntax already exists in XPath 1.0, 2.0 and XQuery spec for a while. Its semantics and syntax are very stable and clear to existing XPath users (and future XQuery users)
  • Its advantage:
    • simple, less typing :-)
    • easier and better type checking analysis in XPath (and future XQuery): a variable reference can have a more specific type, instead of a generic getVariableData which essentually returns xsd:any
References:
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]