Subject: Issue - 199 - Retrofiting Issue 103 proposal to address Issue 199and 203
(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: