wsbpel message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Issue - 103 - Draft of a proposal
- From: Alex Yiu <alex.yiu@oracle.com>
- To: wsbpel@lists.oasis-open.org
- Date: Tue, 24 Aug 2004 23:05:15 -0700
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 253 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:
(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
[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:
(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.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]