OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel-spec-edit message

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

Subject: Issue 103: preview of proposal to vote

Hi, all,

After weeks and months of crafting and drafting, here is the preview of 
proposal to vote for Issue 103 ($var syntax) to the editing sub group.

If you guys got any questions, please feel free to send email to me and 
We are aiming at making this proposal available to the TC list few days 
down the road, if you guys feel comfortable with this proposal in general.


Alex Yiu

Title: Issue 103 Proposed Resolution

Issue 103 Proposed Resolution

Subject: Standardizing $varName syntax for XPath to refer to a BPEL variable

By Alex Yiu and Yaron Goland

Draft Version #8
    [V8: Breaking the document into 3 notes: this note, issue103_terms_and_examples.html, xpath_bpel_part_1.html ]
    [V4-V7: Incorporating comments from Kevin and Yaron]

Aug 02, 2004  - 1pm PDT

(1) Adding $var syntax and simplifying from-spec and to-spec

The value of a BPEL variable appears as Variable-Reference in XPath 1.0:
After introducing $var syntax, we can simplify assign by eliminating some variation of from-spec and to-spec. Here is a list of from-spec and to-spec:

<from expressionLanguage="anyURI"?>expression</from>
<from partnerLink="ncname" endpointReference="myRole|partnerRole"/>
<from variable="ncname" property="qname"/>
<from literal="yes"> ... literal value ... </from>

<to queryLanguage="anyURI"?>$varRef/locationPath</to>
<to partnerLink="ncname"/>
<to variable="ncname" property="qname"/>

<from opaque="true" />
for abstract BPEL remains the same.

(For more details please see:

(2) Manifesting WSDL Messages as XML-Schema Elements

We propose using $var syntax to represent WSDL message variables in XPath. In order to enable the use of the $var syntax we need to provide an infoset representation of WSDL 1.1 messages (i.e. manifest WSDL 1.1 message instances as XML Schema Element instances).

The details will be provided below for how WSDL 1.1 messages will be represented by the infoset but first we provide some simple examples of how this mapping would be used to motivate the discussion.

<from variable="myMsg" part="part01" query="/some_x_path" />
will become:

<to variable="myMsg" part="part01" query="/some_x_path" />
will become:

(The psuedo-template is intended for ILLUSTRATION ONLY on how to map a WSDL 1.1 message type to an XML Schema Element in the usage context of BPEL 1.1. It has limited formal semantics associated with notation.)

<xsd:schema targetNamespace="{an_impl_NS_URI}"

   <!-- [2A] -->
   <xsd:element name="{bpelimpl:genUniqueID()} form="qualified">
              <!-- [2B] if wsdl:part[@type] is used -->
              <xsd:element name="{@name}" type="{@type}"
                           form="unqualified" />* |

              <!-- OR, [2C] if wsdl:part[@element] is used -->
              <xsd:element name="{@name}" form="unqualified" >*
                       <xsd:element ref="{@element}" />

(2A) A "wsdl:message" element is mapped to "xsd:element" element. The "xsd:element" is a globally qualified element. The namespace name of the qualified element is a namespace reserved by the BPEL vendor.  The local name of the qualified element is an ID generated by the BPEL implementation that is unique across all such IDs across all BPEL implementations for all time. Note that: The "xsd:element" is defined based on an anonymous complex type of which contains a sequence.   The content of sequence will be mapped from "wsdl:part" to a series of "xsd:element" based on the rules (2B) and (2C) below.

(2B) A "wsdl:part" element which has a "type" attribute is mapped to a "xsd:element" that shares the same "name" and "type" attribute values. The "xsd:element" has both minOccurs and maxOccus set to 1. The "xsd:element" is a local unqualified element  (i.e. has no namespace)

(2C) A "wsdl:part" element which has an "element" attribute is mapped to an "xsd:element" (outter) which share the same "name" attribute value with "wsdl:part". The "xsd:element" is based on an anonymous complex type, which has a sequence of one "xsd:element" (inner). The inner "xsd:element" has a "ref" attribute referring to the element in "wsdl:part" and has minOccurs=1 and maxOccurs=1. The outter "xsd:element" is a local unqualified element (i.e. having no namespace)

More examples are available at  issue103_terms_and_examples.html#wsdl_examples.

(3) Removing some bpws:getVariableData() and etc

(3A) About bpws:getVariableData():
After adding $var syntax and providing XML-Schema-Element emulation over WSDL message variables, we do not need bpws:getVariableData() function any more.

(3B) About bpws:getVariableProperty()
We suggest to keep bpws:getVariableProperty('variable_name','property_name') and its semantics unchanged.

(3C) About bpws:getLinkStatus('a_LinkName'), we do not need this function any more. Please see details below.

(4) Manifesting linkStatus with $var syntax

Only link-status can be used within join-conditions and only join-conditions can make use of link-status. (Please refer to these restrictions in section 12.5.1 and 9.1). Therefore, we can refer the status of control links directly as variable-reference in the XPath expression used in join-conditions. e.g.:

<joinCondition>bpws:getLinkStatus('buyToSettle') and bpws:getLinkStatus('sellToSettle')</joinCondition>


<joinCondition>$buyToSettle and $sellToSettle</joinCondition>

Therefore, we can remove bpws:getLinkStatus().

If the restrictions in section 12.5.1 and 9.1 do not hold true anymore in future versions of BPEL, we can re-introduce bpws:getLinkStatus(...) to disambiguate between references to BPEL variable and BPEL control link.

(5) Syntax of propertyAlias

We do NOT need to change the syntax of propertyAlias. <propertyAlias> is defined on query-language. Hence, it implies this kind of message property is both readable and writeable (a.k.a a L-value). That is, we can use both from-spec and to-spec to a message property.


Title: Issue 103 Proposed Resolution -Terminologies, Examples and Other Details

Issue 103 Proposed Resolution -Terminologies, Examples and Other Details

By Alex Yiu and Yaron Goland
Aug 02, 2004  - 1pm PDT

References and Terminologies:

[XPDM] :- XPath 1.0 Data Model
[XIS] :- XML Information Set
Since XPath 1.0 is the default query and expression language of BPEL, we will use both [XPDM]  and [XIS] terminologies to describe concepts here.

WSDL 1.1 XML Schema: http://schemas.xmlsoap.org/wsdl/2003-02-11.xsd 


To simplify the XPath syntax to access BPEL variable, including both simple type, schema element of complex type, WSDL Message type, and control link status.

This proposed resolution consists of:
(1) Adding $var syntax and simplifying from-spec and to-spec
(2) Manifesting WSDL Messages as XML-Schema Elements
(3) Removing bpws:getVariableData() and etc
(4) Manifesting linkStatus with $var syntax
(5) Syntax of propertyAlias

(1) Examples and Detailed Explanation of from-spec and to-spec Changes

<from variable="ncname" part="ncname"? />
    will be eliminated and merged into the expression form of from-spec,
    which has the new syntax as follow:
         <from expressionLanguage="anyURI"?>general-expr</from>

          e.g.: <from>$po/lineItem/unitPrice</from>

from-spec: <from variable="ncname" property="qname"/> remains unchanged

For example:
    <from variable="myVar" />
        will become: <from>$myVar</from>
    <from variable="myWSDLMsg" part="part1" /> 
        will become: <from>$myWSDLMsg/part1</from>

For executable BPEL,
    <variable name="myVar" element="some:elem" />
    <from variable="myVar" query="/some:elem/some:more_xpath" />
        will become: <from>$myVar/some:more_xpath</from>
[*** NOTE: the "some:elem" NameTest part of XPath is dropped, because $myVar of "some:elem" type is now pointing to an element, instead of a document. One more detailed example here:

<variable name="myPO" element="p:po" />
<variable name="myLine" element="p:lineItem />
       <from literal="yes">
       <!-- note we are copying the second line item here.
            $myPO is relatively to <p:po>.
            Hence we use "$myPO/lineItem[2]" here,
            NOT "$myPO/p:po/lineItem[2]".  -->


    <from variable="myWSDLMsg" part="part1" query="/some_query_path" />
        will become:

Adding a new boolean attribute to distinguish between the literal form of from-spec and other forms of from-spec.

<from literal="yes|no"?> ... literal here ... </from>

<from literal="yes">

[Side note:

to-spec: <to variable="ncname" part="ncname"? query="xpath"? /> :
will be simplified into the following form of to-spec:
<to queryLanguage="anyURI"?> ... some xpath ... </to>


The partnerLink from-spec and to-spec regarding forms are unchanged.

to-spec: <to variable="ncname" property="qname" />
will be kept unchanged.

For core part of BPEL spec:
<to variable="foo" />
will become:

<to variable="myWSDLVar" part="part01" />
will become:

For executable part of BPEL spec:
<to variable="foo" query="some_xpath" />
will become:

<to variable="myWSDLVar" part="part01" query="some_xpath" />
will become:

(2) Examples for Manifesting WSDL Messages as XML-Schema Elements

Goals of Manifestion
This can potentially help migration of BPEL programs from WSDL 1.1 to WSDL 2.0 (e.g. a straight forward global search-and-replace may do). However, a completely effortless migration is a NON-GOAL, since WSDL 2.0 specification is still in progress and its related WS-I activities have not been bootstrapped yet.

The definition serves as a logical structure for XML-based language (e.g. XPath) to access different parts of WSDL 1.1 message. The physical message format can vary a lot depending on the related bindings, styles, deployment options, and platforms of the web services. The logical message is only for the purpose of accessibility via XPath, and actually it may not match the on-the-wire message format.

[EX-2.1] (from Kevin)
For example, for the following WSDL 1.1 message definition:
<message name="GetLastTradePriceInput">
        <part name="body" element="foo:TradePriceRequest"/>

will be mapped to the following XML Schema Element:

<xsd:element xmlns:xsd="http://www.w3.org/2001/XMLSchema" 

            <xsd:element name="body">
                        <xsd:element ref="foo:TradePriceRequest" minOccurs="1" maxOccurs="1"/>

A from-spec of the following:
<from variable="msgVar" part="body" query="/foo:TradePriceRequest" />
will become:

[EX-2.2] (from Danny)
By mapping a WSDL message to an XML Element, BPEL developers now can write XPath expression to query against all parts of WSDL message more easily.

For example, if a "foo" message has two parts: partA and partB, and we want to check whether a "bar" element exists in these two message parts, we used to write like this:

exists(getVariableData('foo','partA')//bar) or exists(getVariableData('foo','partB')//bar)

We can now write:


This mapping gives us the ability to operate on the variable as a whole, rather than multiple parts

Title: General XPath Semantics as Query and Expression Languages in BPEL - Part 1

General XPath Semantics as Query and Expression Languages in BPEL - Part 1

By Alex Yiu and Yaron Goland
Aug 02, 2004  - 1pm PDT

[IMPORTANT NOTE: Most of the semantics described in this section is needed for the clarification of the general XPath application in BPEL, regardless whether we accept the syntax changes of $variable or we stay with getVariableData(). ]

(XP-A) Definition of Enclosing Element of Query and Expression language: Whenever an query language or expression language is used in BPEL (e.g. XPath 1.0), the Enclosing Element is defined as the parent element in the BPEL process definition that contains the Query or Expression. For example, in the following from specification example:


The "from" element of BPEL namespace is the Enclosing Element.

(XP-B) When XPATH is used for Query Language and Expression Language: The context of the XPath evaluation is: [NOTE: The following is NOT applicable to propertyAlias. For semantics of query language used in propertyAlias, please see see in (XP-F) ]

Syntax Restrictions:

(XP-C) When XPath is used as Query Language for propertyAlias
The context of the XPath evaluation is:
The XPath MUST be a RelativeLocationPath (http://www.w3.org/TR/xpath#NT-RelativeLocationPath).

The XPath MUST NOT be an AbsoluteLocationPath (http://www.w3.org/TR/xpath#NT-AbsoluteLocationPath).

<propertyAlias propertyName="poId" messageType="my:POMsg">

(XP-D) More details about Conditions of bpws:selectionFailure
The cardinality of nodes yielded from an XPath expression is either ZERO, ONE, OR MULTIPLE. The exact ONE node semantics checking remains the same at the boundary of from-spec and to-spec and bpws:getVariableProperty(). The bpws:selectionFailure will be thrown if NOT exactly one node is returned. Two additional notes:

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