Re: [wsbpel] Issue 157 - updated and simplified replacement table

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

Hi all,

Upon the discussion of July 12 conf call, I have updated and simplified the replacement table from the version that we sent out during the last F2F.

Please see the attached HTML file.

Thanks!


Regards,
Alex Yiu



Charlton Barreto wrote:

At the July 12 call we:

1) discussed the validity and usefulness of the EII for simple-type semantics, given concerns over handling of attributes between cases. A compromise of merging the EII for complex-type semantics and EII for simple-type semantics was discussed, and deemed acceptable to the group given a decision of whether we should always allow coercion of an element to text/TII, or always fault in this case. This decision was further discussed and polled, and it was agreed that we would give ourselves until July 22nd to converge on it via email. Barring that, we would hold an Issue 157 conference call on July 26 (08.00 PDT). In any case we will bring this issue to the TC on the July 27th conference call.

2) discussed concerns over expression language independence. It was generally agreed that we protect such independence with Alex's Issue 157 proposal.

3) questioned if we used a variable typed as XSD complex type, whether it would apply to the EII for complex-type or EII for simple-type semantics (as opposed to AII or TII). It was agreed that, as complex type will always be an element, and the content either complex or simple, it would apply to these semantics.  
4) questioned that, given the lack of schema awareness, whether there was any way to distinguish between null and empty string, because of the lack of schema awareness? It was agreed that we don't distinguish between these two cases, as the runtime is not schema aware (if we'd want to distinguish it, we'd need to use XPath 2.0 instead of 1.0).

As a result of 1), the existing proposal was amended to accomodate recommendations from others in the Issue 157 group:

• The first and second rows of the copy/replace semantics table (from the Palo Alto F2F) would be merged into one row for EII
• EII-to-AII and EII-to-TII copy would be defined as copying the string-value of EII, instead of fault (except in the case of xsi:nil="true")
• When xsi:nil="true" on an element, an EII-to-AII or EII-to-TII copy would trigger a selectionFailure

Title: Issue 157 - Discussion - Replacement Table

Issue 157 -  Discussion - Replacement Table

Last modified: July 18, 2005 - 6 pm PDT


Per conf call discussion on July 12, here is refined and consolided
version of the Replacement Table evolved from the F2F discussion.

Refinement and Consolidation of Replacement Table for <bpel:copy>

Replacement Table:

Src\Target	EII	AII	TII
EII	RE	RC	RC
AII	RC	RC	RC
TII	RC	RC	RC

Definition

• 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
• If replaceElementName attribute at <bpel:copy> is set to "yes", an extra replacement step will be performed to replace the target element-name with the source element-name. (i.e. [namespace name] and [local name] properties).
  
  (Note: for this "replaceElementName", please see the syntax example below. This attribute is optional. The default will be "no" - not replacing target element name. This attribute is added to support XSD's subsitutionGroup pattern.)
  
  
• RC (Replace-Content):
  
• How to obtain the source content
  
• The source (from-spec) MUST yield one and only one node. Otherwise, selectionFailure fault MUST be thrown. (That is, "selectionFailure" checking from BPEL 1.1 is retained.)
  
• After the node is yielded from the source, the "string()" function will be applied to the node to obtain its string-value as the source content, if the default XPath 1.0 binding is used in the from-spec. If the other expression language is used, a function other than "string()" may be applied to the node to obtain the source content
  
• How to replace:
  
• If the destination is an EII, remove all [children] properties (if any) and add the source content TII  as the child of the EII.
  
• If the destination is an AII, replace the value of AII will be replaced by the TII from the source.
• If the destination is a TII, replace the TII in the destination with the TII from the source.
  

Foot-note to the "Replacement-Table":

• Note: the above table does not describe the message-variable-to-message-variable copy.
• Information items referenced by the to-spec MUST be a Lvalue. (As stated in Issue 103)
• In XPath 1.0 data model, only Text Node can constitute a LValue of TII.

Clarified Definition of TII: 



TII is a sequence of zero or more CII. When it is mapped to
XPath 1.0 model, it is a generalization of String-Value (which has zero
or more characters) and Text Node (which has one or more characters).
RValue of a TII can be mapped to a String-Value or a Text Node in XPath
1.0, while LValue of a TII can be only mapped to a Text node. 


Syntax Example of <copy> with "replaceElementName" attribute: 
---------------------------
<assign>
   <copy replaceElementName="yes|no">
         <from> ... </from>
         <to> ... </to>
   </copy>
</assign>
---------------------------