Re: Fw: [wsbpel] Issue - 157 - back to main list

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

Hi Rania, Charlton and all others,

Thank you for sending those individual files to me.

Yes, Oracle email server does not accept zip file attachement unfortunately.
If you guys want to send a zip file to an Oracle address in future, please send with an alternative file extension.  E.g. "foo.zip.rename" ... :-)

[A]
I want to remind people that we have sent out a draft during F2F.
http://lists.oasis-open.org/archives/wsbpel/200506/msg00013.html
Actually, we have NEVER held a formal discussion over the design choices listed in the above email.

I would like to suggest to put the replacement-table in the above email in tomorrow conf call agenda.

Rania and Charlton, I would hope you guys can spend some time reading that table up.

[B]
At the same time, I would to remind how <bpel:copy> is defined in BPEL 1.1 and what we have discussed on Issue 157 so far in Palo Alto F2F.

BPEL 1.1 has already given some high-level design guidlines of <bpel:copy>. Unfortunately, some of detailed definition is not present in BPEL 1.1. The goal of Issue 157 is to flesh out and clarify those details.

BPEL 1.1 defines the following so far:

• BPEL (including <bpel:copy>) should be expression language independent generally speaking.
  
• The from-spec and to-spec of <bpel:copy> should yield exactly one node. Otherwise, selectionFailure will be triggered.
  
• mismatchedAssignmentFailure will be thrown, when incompatible types are encountered in an assign activity.
  

In the last F2F, if my memory serves me right, we have voted and agreed on the following:

• "Copy Should Really be a Copy followed by a Replace"
• "Copy Should Only Deal with EIIs, AIIs and TIIs"
  
• "Copy Should Not be Schema Aware" at runtime, because XPath 1.0 is our default language and its data model is not schema aware. Vendors are allowed to do static analysis on <copy> based on schema. If a vendor choose to use a data model which is schema aware, copy can be schema aware at runtime

Based on BPEL 1.1, I would like to lay down more major design principles to guide us to define the behavior for the replace-logic (similar to what we did in the F2F):

• <bpel:assign><bpel:copy> operations SHOULD be modeled after assign statement in typical procedural language. E.g.:
        <assign> <copy>
           <from> $var/foo/bar[2] </from>
           <to> $var2/foo2/bar </to>
        </copy> </assign>
  
  The effect of the above assign should be similar to assignment in C++:
        var.foo.bar[2] = var2.foo2.bar;    
  
  A more real life example that we need to support would be:
       <assign> <copy>
          <from> $poVar/billingAddr </from>
          <to> $poVar2/shippingAddr </to>
       </copy> </assign>
  
  (Think of the above as: poVar.billingAddress = poVar2.shippingAddr;  )
  
  
• The "assign-then-equal" principle: The post condition of <bpel:assign> and <bpel:copy> would be the from-expression would be equal to to-expression. E.g.:
  
  var.foo.bar[2] = var2.foo2.bar; 
        will make
              (var.foo.bar[2] == var2.foo2.bar) becomes true
  

Note: what "equal" means varies from one expression language to another expression language. Since we adopt XPath 1.0 as our default langauge, we should try our best to ensure majority cases (not necessarily all cases) that after execution of :
     <assign> <copy>
        <from> from-expr </from>
        <to> to-expr </to>
     </copy> </assign>

(from-expr = to-expr) evaluates to true in XPath 1.0

Note: there is more than one equal operators in XPath 2.0 to supplement the deficiency in XPath 1.0

• The design of <bpel:copy> should make type analysis easy: Even though we cannot enforce schema-aware at runtime due to adopting XPath 1.0 as our default language, the design of <bpel:copy> should facilitates static analysis schema types. Similarly, if we adopt XPath 2.0 in future, our current design <bpel:copy> should NOT make runtime mismatchedAssignmentFailure fault detection difficult. 

[C]
I will go through your XSLT samples and document attachement in details today. By browsing it quickly, my first responses are:

• High level speaking, I agree with your approach. Splitting the design into two parts: (1) define a replace-semantic table / matrix (this part is outside of XSLT) (2) then  to define the entries in table and try to see whether it is feasible and economical to use XSLT in those definition of those entries.  Coincidentally, that would be my preferred high level approach also. :-)
  
  
• For part (1): the table part, quickie comments:
  
  
1. Could you clarify the distinction in your mind of "node" vs "value"? By going through your examples, I think I can induce by examples what you meant. Can you bind these two concepts to a formal data model? DOM? XPath DM? Anyway, if my induction is correct, your distinction of "node-vs-value" may mismatch XML Schema model. IMHO, the "node" concept should be mapped element/attribute declaration, while "value" concept would be mapped to XSD type definition.
   
   E.g. element-name is the "head" of the "node", while the attributes and all children are the "values" of the "node".
    
   
2. The table in Rania's doc can be related to the table sent out during F2F in the following way: picking the 2x2 square for EII and AII matrix and expand it with by adding element-node and attribute-node columns. The F2F table focus on the value copies and replacement, not the nodes copies and replacments (note: I am using my schema-oriented definition of node-vs-values).
   
   IMHO, I am not sure we want to expand <bpel:copy> to do a bunch of node-copy as Rania has illustrated. I am not sure there is a great need for that.  (e.g. En-Ev, An-En, An-An). And, we have enough entries in the F2F table for us to build consensus on already. Also some of those operations are not in sync with the principles that I lay out above.
   
   Example: The assign-then-equal principle cannot hold for An-to-An operation.
   
   Example: From "$poVar/billingAddr" to "$poVar/shippingAddr" does not seem supported (in EN-to-EN or EV-to-EV operations).
   
   
3. It seems to me that  Rania's table does not address copying to simple-type variable situation. That's a relatively minor issue.
   
   
• For part (2), your XSLT to define entries in the table:
  
• Actually, you don't need to mention anything like:
       select="document('&fromDocument;')&fromNodePath;"
  Because the from-spec can be more complicated that just a simple expression like <from> $var1/some/xpath/here </from>. I guess we can represent a from-spec as a parameter. e.g.:
     select="$theNodeReturnedFromSpec"
  
  
• The flip side of the coin: A to-spec can be non-trivial and refer to multiple variables as well. e.g. <to> ($var1 | $var2)//lineItem[@product='33'] </to>
  
  Given that to-spec, if we use XSLT to describe <bpel:copy> behavior, we may need to generate two result trees. one for var1 and one for var2. However, only XSLT 2.0 can generate multiple result trees, while XSLT 1.0 cannot.
  

[ As of this moment, I am still having doubts on the feasible and economical aspect of using XSLT as a formal definition language to define all entries in replace table for <bpel:copy>. ]


Thanks!



Regards,
Alex Yiu



Rania Khalaf wrote:

Retrying since you don't accept .zip. Please copy all into same dir.

Thanks,
Rania


(See attached file: tev.xsl)(See attached file: 157table.doc)(See attached
file: anan.xsl)(See attached file: anen.xsl)(See attached file: avav.xsl)
(See attached file: avev.xsl)(See attached file: enen.xsl)(See attached
file: enev.xsl)
(See attached file: evav.xsl)(See attached file: evev.xsl)(See attached
file: tav.xsl)

----- Forwarded by Rania Khalaf/Watson/IBM on 06/16/2005 12:58 PM -----

|---------+---------------------------->
|         |           Rania Khalaf     |
|         |                            |
|         |           06/16/2005 12:34 |
|         |           PM               |
|         |           Please respond to|
|         |           rkhalaf          |
|---------+---------------------------->
  >------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                              |
  |       To:      Alex Yiu <alex.yiu@oracle.com>                                                                                |
  |       cc:      Alex Yiu <alex.yiu@oracle.com>, Charlton Barreto <cbarreto@adobe.com>, chris.keller@active-endpoints.com,     |
  |       "'Dieter Koenig1'" <dieterkoenig@de.ibm.com>, Francisco Curbera/Watson/IBM@IBMUS, frank.ryan@active-endpoints.com,     |
  |       Maciej Szefler <mbs@fivesight.com>, Ron Ten-Hove <Ronald.Ten-Hove@Sun.COM>, wsbpeltc <wsbpel@lists.oasis-open.org>,    |
  |       "Yaron Y. Goland" <ygoland@bea.com>                                                                                    |
  |       From:    Rania Khalaf/Watson/IBM@IBMUS                                                                                 |
  |       Subject: Re: [wsbpel] Issue - 157 - back to main list                                                                  |
  |       Importance:    Urgent                                                                                                  |
  |       Importance:    Normal                                                                                                  |
  |                                                                                                                              |
  |                                                                                                                              |
  >------------------------------------------------------------------------------------------------------------------------------|



Hi guiys,

I have been looking at this and the more I do so the more I think that
there is a compromise approach that solves all our problems:
-Does copy as it is today without extending capabilities. How: focus only
on what copy can do today and don't add additional features
-Uses XSLT to define precise semantics but does not require XSLT support or
introduce XSLT to the BPEL process.
      How: define XSLT scripts that perform the copy stated in the cells in
the copy-table, and state that the target  of that particular copy must, at
the end of the copy, have the same XML as the output of having run that
particular script. The scripts we define are a small finite set and we do
not open random XSLT-ing to the public. Hence, this is copy by
"XSLT-analogy" ;)
-Distinguishes properly to the process designer what the intent of the copy
is, without having to do guess work. How:  reuse the idea of value-of vs.
copy-of  to determine whether the designer is trying to copy from/to a
whole node or just the text value child.

I am attaching an explanation. I think this is easy, simple, unambiguous,
does not mangle XSLT, and takes the guess work out of the rest of it.

I would like to use this as one of the inputs to tomorrow's call so would
need to circulate to TC this pm or tomorrow am. Comments welcome.



Regards,
Rania
**** Attachment 157.zip has been removed from this note on June 16, 2005 by
Rania Khalaf ****