Re: [wsbpel] Issue - 201 - Proposal For Vote

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

Hi, Yaron,

Thanks for agreeing that embedding a QName as variable reference in XPath could be pretty ugly.


However, I would like to mention an alternative proposal:
----------------------------------------------
Summary:
The occurrence of:
bpws:getVariableProperty('myVar','p:myProp')
can be replaced by:
[A]  p:myProp($myVar)      ... or ...    
[B]  p:myProp('myVar')

(We need to make a choice above. I prefer [A] so far.)

Rationale:
As BPEL 2.0 progresses, our definition of BPEL variable property is becoming almost identical to an XPath function: data-input => data-output (of a particular data type)

Syntax-wise, a BPEL variable property is a QName,  while an XPath function symbol is also a QName.

Hence, we should reduce our footprint into XPath world by eliminating this getVariableProperty() "meta" function, similar to what we did to getVariableData(). Again, making the variable property as an XPath function enables us doing better and easier static type analysis.

Details:
WS-BPEL Variable Properties are manifested in XPath expression as a XPath function. As a variable property is named with a QName, the XPath function manifested for the variable property MUST share the same QName. The return value of XPath function MUST match the type/element associated with the variable property definition. The return value is a node set containing the single node representing the property.

There is ONLY ONE input argument to the XPath function.

[A]
The input argument MUST be a variable reference which matches the source variable for the data. The string MUST be a static variable reference, instead of the result of another function or expression. The static variable reference restriction MUST be enforced during static analysis.

When a variable property is defined based on a WSDL message type, the variable reference to a message variable MUST be used ONLY within XPath function manifested from BPEL variable properties. Any other usages MUST be considered illegal. The message variable variable reference restriction MUST be enforced during static analysis.

[B]
The input argument MUST be a string which names the source variable for the data. The string MUST be a static value, instead of the result of another function or expression. The static value restriction MUST be enforced during static analysis.

(Note: the restriction in [B] is already enforced as we passed Issue 29. And, [A] just mirrors similar restriction.)
----------------------------------------------

If TC members show interests, I would submit the above proposal draft (enriching it, if needed) to the actual proposal for vote.


Thanks!



Regards,
Alex Yiu






Yaron Y. Goland wrote:

I propose we close without action. Trying to embed a QNAME into a XPATH variable name is certainly possible but likely to be deeply ugly.

    Yaron


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php