[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue - 199 - Retrofiting Issue 103 proposal to address Issue 199and 203
Hi all, (resend due to the size limitation of email attachement in BPEL email list) Per Satish's amendment on Issue 103, Yuzo followed it up by filing two tracking issues: 199 and 203. Yuzo, Yaron and I worked together to create the delta/diff part text to retrofit Issue 103 to accommodate Satish's amendment and to address both Issue 199 and 203. Summary of our proposal: For Issue 199
Highlight of Key Delta ======================================== After the sentence of “The name of a variable should be unique within its own scope”, add the following sentences: Variable names are NCNames (as defined in XML Schema specification) but in addition they MUST NOT contain the “.” character. This restriction is necessary because the “.” character is used as a delimiter in variable names in BPEL's default binding to XPath 1.0 (i.e. the binding identified by "urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"). The delimiter separates the WS-BPEL message type variable name and the name of one of its WSDL message parts. The concatenation of the WSDL message variable name, the delimiter and the WSDL part name is used as an XPath variable reference which manifests the XML Infoset of the corresponding WSDL message part. ======================================== ======================================== For each part in the WSDL message definition: Step 1 – Create a synthetic DII which has no children other than as specified below. Step 2 - Create an EII as a child of the document element whose namespace name is null and whose local name is the same as the WSDL message part's name. Step 32a - If the WSDL message part is defined using the type attribute then create an EII as a child of the document element. The local name and namespace name of the newly created EII are determined by the WS-BPEL 2.0 engine and are not specified by this document. The handling of this EII is similar to how WS-BPEL 2.0 handles the containers for complex and simple type XML variables. The contents of the new EII are required to conform to the contents defined by the referenced type definition. Step 3b2b - If the WSDL message part is defined using the element attribute then the new EII will itself contain create an EII as a child of the document element which manifests the element defined by the referenced type definition. The previous models are conceptual; they define how WS-BPEL 2.0 submits and retrieves XML variable values using infoset definitions. But these models are not intended to require that WS-BPEL 2.0 implementations actually implement an infoset model, only that however variable binding is handled the end result duplicates the behaviors defined using the infoset model. For example, a WS-BPEL 2.0 implementation may choose to bind a simple type BPEL variable of type xs:string directly to a String object in XPath 1.0. The choice of mapping MUST be consistently applied to variables and WSDL message part values of the same XML schema type. E.g. if a xs:string variable is manifested as a string object, a xs:string message part MUST be manifested as a string object also. For detailed definition of manifestation of BPEL variables in XPath 1.0, please see “Binding BPEL Variables In XPath 1.0” section. ======================================== ======================================== WS-BPEL 2.0 messageType variables are manifested in XPath 1.0 as a series of variables, one variable per part in the messageType. Each variable is named by concatenating the message variable's name, the "." character and the local name of the part. The data in a BPEL messageType variable is NOT made available as one single XPath variable to general XPath processing under the default query and expression language binding. For example, if a messageType variable was named "myMessageTypeVar" and it contained two parts, "msgPart1" and "msgPart2" then XPath 1.0 binding that had "myMessageTypeVar" in scope would manifest two XPath 1.0 variables, $myMessageTypeVar.msgPart1 and $myMessageTypeVar.msgPart2. Please note that section 2.3 of [WSDL 1.1] requires that all part names within the same WSDL message definition must be unique. WSDL message parts are always defined using either an XSD element, an XSD complex type or a XSD simple type. As such the manifestation of these message parts in XPath can be handled in the same manner as specified herein for element, complex type and simple type WS-BPEL 2.0 variables. ======================================== ======================================== When
XPath 1.0 is used as Query Language for a propertyAlias, the XPath
context is
initialized as follows: ·
Context node = ·
When messageType/part attributes are used: o
If the message part is based on a complex
type or an
element, the context node will point to node-list containing a single
node
which is the EII for the referenced part where the EII is defined as
specified
in section 9.2.2. o
If the message part is based on a simple
type, the
context node will point to the XPath object specified for the
particular
variable type in section 9.2.2. ·
When type attribute is used: o
If the type is a complex type, the context
node will
point to node-list containing a single node which is the EII for the
referenced
part where the EII is defined as specified in section 9.2.2. o
If the type is a simple type, the context
node will
point to the XPath object specified for the particular variable type in
section
9.2.2. ·
When element attribute is used, the context
node will
point to node-list containing a single node which is the EII for the
referenced
part where the EII is defined as specified in section 9.2.2. ======================================== In
the fourth from-spec variant, an expression language, identified by the
optional expression language attribute, is used to return a value. In
the
fourth to-spec variant, a query language, identified by the optional
query
language attribute, is used to return a value. Both from-spec and
to-spec allow
processes to perform simple computations on properties and variables
(for
example, increment a sequence number). This computed value MUST be one
of the
followings: ·
a single XML information item other than a character information
item
(CharII): examples are element information item (EII) and attribute
information item (AII) ·
a sequence of one or more character information items: this is
mapped to
a Text Node in the data model of XPath 1.0 In
the case of to-spec, the computed value MUST be a lvalue. Please
note that it is possible to use either the first form of
from-spec/to-spec or
the fourth form of from-spec/to-spec to perform copy on
non-message-variables
and parts of message variables, as this specification defines how to
manifest
non-message variables and parts of message variables as XML Infoset
information
items. However, only the first form of from-spec/to-spec is able to
copy an
entire message variable including all of its parts. Other from and
to-spec
forms are only able to refer to a single part in a WSDL message type
variable
and so cannot copy all of the parts at once. ========================================
For detail changes, please see the attached PDF file:
Thanks! Regards, Alex Yiu |
Issue_199_203_delta_on_103_take_11_for_diff.pdf
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]