Re: [wsbpel] Issue - 157 - Proposal For Vote

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

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 Complex-Content	RE	F	F
EII with Simple-Content	RE	RC	RC
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