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

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