Hi all,

After dinner last nite, I had a late nite 157 conversation with Yaron. Here is the attempt to recap the content that we have discussed so far. (I added some extrapolation of my own. Hopefully, those are reasonable to Yaron)

Thanks!

Regards, Alex Yiu

Title: Issue 157 - Discussion (Cont'd)

Supplementary Note on Issue 157

Last modified: June 2nd, 2005 - 8:45am PDT

Recap / Clarification Issue 157 Context: (1) Before running any <copy>: optional schema-related static analysis is allowed. Not <assign>/<copy> specific; will be handled under subissue 9.1 (2) Actual running of <copy>: * the runtime part of <copy> logic is defined as NON-schema-aware in WS-BPEL 2.0 specification, because the spec relies non-schema-aware data-model and terminologies (namely XPath 1.0 Data Model and XML Infoset Items). * However, extensions to <copy> can be used to indicate the adoption of other data models through extension attributes/elements or expressionLanguage/queryLanguage URI at from-spec/to-spec. Those data-models can be schema-aware (e.g. upcoming XQuery 1.0 data model). If those schema-aware data-models are used, additional schema-aware features would be provided at <copy>. (3) After running of <copy>, optional full blown XML Schema Validation is enabled (See Issue 160).

Copy to an initialized value

Excluding cases: * Using <copy> to initialize a variable * copying msg variables

+------------------------------+ |Src\Dest |EII |AII|TII| |---------------+------+---+---| |EII with |RE |F |F | |Complex-Content| | | | |---------------+------+---+---| |EII with |RE |RC |RC | |Simple-Content | | | | |---------------+------+---+---| |AII |RC [a]|RC |RC | |---------------+------+---+---| |TII |RC [a]|RC |RC | +------------------------------+

Definition * EII with Simple-Content: EII has one child only which is TII. All other cases of EII is EII with Complex-Content * RE (Replace-Element-properties): Remove all [children] and [attributes] properties of the destination EII and add all [children] and [attributes] properties of the source EII to the desitnation EII * RC (Replace-Content):

* If the destination is an EII, remove all [children] properties (if any) and add the TII from the source (e.g. the TII child of EII, the TII value of AII) as the child of the EII. * If the destination is an AII, replace the TII value of AII will be replaced by the TII from the source. * If the destination is a TII, replace the TII in the destination withe the TII from the source.

* F: "bpws:mismatchedAssignmentFailure" fault MUST be thrown Notes: [a]: It is legal to use AII or TII to replace the content of an initialized EII value, while it is illegal to use TII or AII to initialize a not-yet-initialized element-based variable.

Using <copy> to initialize variables

For complex type and simple type variable, a skeleton structure, composed of a DII and an anonymous EII (Document Element), will be created as an integral part of the initialization <assign>/<copy> operation. After the skeleton structure, the above "copy to an initialized value" logic can be reused.

For element type variables, a DII (without Document Element) will be created as an integral part of the initialization <assign>/<copy> and the source of <copy> MUST be an EII which will be copied as the Document Element of destination DII.

Copying msg variables

... [A simple paragraph to describe how to copy the source collection of XML Infoset Items, which represents message parts individually, to the destination collection of XML Infoset Items.]

Extra Consideration for XML Data Models

As stated above, when different XML data models are coupled with WS-BPEL, it MAY affect some details of behavior of <copy> and other data access / manipulation in WS-BPEL. No attempt will be made to cover the universe of data models. Here only the XPath 1.0 Data Model will be addressed.

Simple-Typed Variables for XPath 1.0 Data Model As a part of Issue 103, simple type variables and values are allowed to manifested as non-XML-Infoset-Item objects defined in XPath 1.0: i.e.: boolean, string, float.

Similarily in Issue 157, in order to reuse the "copy-table" semantics, we would define the conversion (when the conversion is needed) between:

boolean / string / float => TII TII => boolean / string / float

The conversion definition is trivial, because we would just refer to existing XPath 1.0 conversion functions.

Since simple type variables can be manifested in those XPath 1.0 data objects, we need to allow the WS-BPEL and Expression-Language implementation to reject data values the data object in the data model CANNOT contain by throwing "bpws:mismatchedAssignmentFailure" fault, when the above conversion logic fails.

Consider the following <copy> example:

<assign> <copy> <from> "abc" <from> <to> $myIntegerVar </to> </copy> </assign>

NOTE: This is NOT XSD Validation. (That is: any extra restriction added during type XSD simple type derivation, such as regular expression, do NOT apply here.) The full blown XSD validation of simple-type variable are facilitated by constructs introduced by Issue 160.

XMLNS Preservation and Consistency

END