Issue - 103 - Draft of a proposal

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

Hi, all,

After weeks and months of discussion with various people, here are second iteration of Issue 103 proposal. The content is divided into 3 parts:

• issue103_proposal_v8.html : the core part of the proposal
• issue103_terms_and_examples.html : references and detailed examples on how Issue 103 works
• xpath_bpel_part_1.html : details of XPath semantics when used in BPEL. (Note this part is needed, regardless the syntax form of Issue 103. It has been just a underspecified area in the spec.)
  

Special thanks to Yaron (co-author of this proposal) for spending hours to nail down all the details of this proposal.

Hopefully, we can move on to formal voting for this issue between 1 to 3 weeks from now.
Thanks!!!


Regards,
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 24, 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:

• When the variable is declared with  "element" attribute or "messageType" attribute: The value of the BPEL variable is manifested as a node in a node-set. The node will represent an element information item (EII) that is the document element of a synthetic document information item (DII).
  
• When the variable is a simple type (i.e. the variable is declared with "type" attribute or the variable a control-link status): The variable corresponds to a boolean object, a number object or a string object, depending on the original schema simple type associated with the variable.
  
  [Numeric Precision Note: XPATH only has a single numeric object, float. Float is a 64 bit IEEE floating point number. However the resolution of the float object is not sufficient to capture the full value of some XML Schema data types. For example, a XSD decimal number must support at least 18 digits where as a XPATH float only has to support approximately 16 digits (0 to 2⁵³ to be exact). To prevent loss of information XSD numeric values that cannot be expressed without loss of accuracy will be translated into strings. By translating the value to a string one can perform copies without loss of accuracy.  A string value is converted to numeric objects by applying XPATH number() function, which is either explicitly coded by a programmer or implicitly required by XPATH specification. E.g.: the XPATH specification requires that the numeric operators convert their operands to numbers as if by calling the number function.] [Editor Note: Is there any standard for how to translate numbers of one type to another? Or is this implementation specific?]"
  

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:

• issue103_terms_and_examples.html#from_spec_to_spec_changes
  
• Sections of [XP-B] and [XP-C] of "General XPath Semantics as Query and Expression Languages in BPEL - Part 1" :- xpath_bpel_part_1.html)

(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: 
<from>$myMsg/part01/some_x_path</from>

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

(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}"
            elementFormDefault="unqualified">
   <!-- [2A] --> 
   <xsd:element name="{bpelimpl:genUniqueID()} form="qualified">
      <xsd:complexType>
         <xsd:sequence>
            (  
              <!-- [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:complexType>
                   
<xsd:sequence> 
                      
<xsd:element ref="{@element}" />
                   
</xsd:sequene> 
                 </xsd:complexType>
              </xsd:element>
            )
         </xsd:sequence> 
      </xsd:complexType>
   </xsd:element>
</xsd:schema>

(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 syntax to access parts of WSDL message would be like: $myMsgVar/msgPartName. The resulting QNAME is NOT exposed to the BPEL developers, because the WSDL message variable is exposed as an element node (EII).

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>

becomes: 

<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.

END

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 24, 2004  - 11pm PDT

References and Terminologies:

[XPDM] :- XPath 1.0 Data Model

• http://www.w3.org/TR/xpath#data-model Node types: { root nodes, element nodes, text nodes,  attribute nodes, namespace nodes, PI nodes, comment nodes }
  
• http://www.w3.org/TR/xpath#section-Introduction Data Object types: { node-set, boolean,  number, string }

[XIS] :- XML Information Set

• http://www.w3.org/TR/xml-infoset/ { DII, EII AII, PII (Processing Instruction), UERII (Unexpanded Entity Reference), CharII, CII (Comment), DTDII, UEII (Unparsed Entity), NotationII, NII (Namespace) }
  
• Yaron introduced a new derived Information Item type - Text Information Item (TII) to denote an information item equivalent to text node from [XPDM] by combining adjacent CharII together. This is a macro which allows us to model XPATH text nodes using infoset terminology. 

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

Goals:

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

(1A)


<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>




(1B) 


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




For example:


    [EX-1.1]


    <from variable="myVar" />


        will become: <from>$myVar</from>

    [EX-1.2]


    <from variable="myWSDLMsg" part="part1" />  


        will become: <from>$myWSDLMsg/part1</from>




For executable BPEL, 

    [EX-1.3]


    ... 


    <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 />
...
<assign>
    <copy>
       <from literal="yes">
             <p:po>
                <p:lineItem>...</p:lineItem>
                <p:lineItem>...</p:lineItem>
                ...
            </p:po>
       </from>
       <to>$myPO</to>
    </copy>
</assign>
<assign>
    <copy>
       <from>$myPO/lineItem[2]</from>
       <!-- 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]".  -->
       <to>$myLine</to>
    <copy>
</assign>
...

***]

    [EX-1.4]


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


        will become: 
        <from>$myWSDLMsg/part1/some_query_path</from>





(1C) 


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>




E.g.: 


<from literal="yes">


    <foo:bar>abc</foo:bar> 


</from> 




[Side note:

• The effect of the literal form of from-spec can be achieved by using the expression-form of the from-spec, given the right expression language is used. For example, XQuery can be used to express a XML-fragment "constant" very easily.
• It was suggested to introduce an explicit expresion-language for literal and used in expression form of from-spec. So, it may look like:
  <from expressionLanguage="urn:bpel:literal">...</from>
  It is kind of a bit too verbose compared with literal="yes" ]
  

(1D) 


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> 




E.g.:


    <assign>


            <copy>


                    <from>$foo/abc/def</from>


                    <to>$bar/ghi/jkl</to> 


            </copy>


    </assign>


(1E) 


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




(1F)



to-spec: <to variable="ncname" property="qname" /> 



will be kept unchanged. 




[EX-1.5]  

For core part of BPEL spec:


<to variable="foo" />



will become:



<to>$foo</to>


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




[EX-1.6]


For executable part of BPEL spec: 


<!-- foo is an element based variable --> 
<to variable="foo" query="some_xpath" />

will become:


<to>$foo/some_xpath</to> 






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


will become:



<to>$foo/part01/some_xpath</to>

(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"/>


</message>




will be mapped to the following XML Schema Element:




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


    <xsd:complexType>


        <xsd:sequence>


            <xsd:element name="body">


                <xsd:complexType>


                   
<xsd:sequence>


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


                   
</xsd:sequence>


                </xsd:complexType>


            </xsd:element>


        </xsd:sequence>


    </xsd:complexType>


</xsd:element>




A from-spec of the following: 


<from variable="msgVar" part="body" query="/foo:TradePriceRequest" /> 


will become:


<from>$msgVar/body/foo:TradePriceRequest</from> 






[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:




exists($foo//bar)




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


independently.

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 24, 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:


<process>
    ...
    <from>$myVar/abc/def</from> 
    ...
</process> 


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-C) ]

• Context node = none
  
• Context position = none ; Context Size = none
  
• A set of variable bindings = variables visible to the Enclosing Element as defined by the BPEL scope rules 
  
• A function library = core XPath function library + BPWS function library 
• Namespace declaration = inherit in-scope namespace declaration from Enclosing Element, NOT the namespace declaration used in the variable data (similar to rules specified in XSLT) (related to Issue 102). QNAME without prefix must have NO namespace, i.e., no default namespace (as specified in XPath 1.0 specification).
  

Syntax Restrictions:

• It MUST be a general XPath expression "Expr" (http://www.w3.org/TR/xpath#NT-Expr).
  
• However, the "LocationPath" (http://www.w3.org/TR/xpath#NT-LocationPath) choice of production rule of "PathExpr" [19] (http://www.w3.org/TR/xpath#NT-PathExpr) MUST NOT be used.
  
  

  [19]	PathExpr	::=	LocationPath
  			| FilterExpr
  			| FilterExpr '/' RelativeLocationPath
  			| FilterExpr '//' RelativeLocationPath

  
  This restriction essentially disallows direct usage of "LocationPath". It enforces that "PathExpr" start with a "PrimaryExpr" (http://www.w3.org/TR/xpath#NT-PrimaryExpr), which in turns needs to be a variable reference, a literal, a number, or a function call.
  
• This restriction disallows access to the root node and context node, which are intentionally unspecified above. Any access to the root node and context node will results into a fault. (See XP-D for details.)
  
• When XPath is used as a Query Language, there is an extra restriction. The XPath MUST be a "PathExpr". This restriction ensures L-value nature of the XPath. 
• These restrictions MUST be enforced by static analysis.

(XP-C) When XPath is used as Query Language for propertyAlias
The context of the XPath evaluation
is:

• Context node = element (EII) that manifests the WSDL message
  
• Context position = 1 ; Context Size = 1
  
• A set of variable bindings = There are NO variable bindings available when XPath is used as query language in propertyAlias
  
• A function library = none of the BPEL defined XPATH functions are available  when the XPath is used as query language in propertyAlias 
• Namespace declaration = inherit in-scope namespace declaration from Enclosing Element, NOT the namespace declaration used in the variable data (similar to rules specified in XSLT) (related to Issue 102). QNAME without prefix must have NO namespace, i.e., no default namespace (as specified in XPath 1.0 specification)
  

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).

E.g.
<propertyAlias propertyName="poId" messageType="my:POMsg">
    <query>poPart/po/id</query> 
</propertyAlias>



(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:

• (from Ugo) The selectionFailure checking does not occur within an XPath expression / query itself. For example, this XPath expression:
  <expression> count($po/lineitem) > 3 </expression>
  It works without throwing a fault when there is more on than one lineitem.
• (from Yaron) Yaron was considering a relaxation of the cardinality checking at the boundary of from-spec. (e.g. zero-node from-spec may mean removal.) Another issue may be opened to track this down.