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

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

Hi all,

Since quite a few people would be interested in this Issue 157, I guess it would be a good idea to make this discussion back to the main list.

Thanks!


Regards,
Alex Yiu



Alex Yiu wrote:

Hi all, (Chris, Frank, Maciej, Ron, Yaron and Dieter)

I have identified the people on the list are interested to wrap up Issue 157 to clarify the semantics of <copy>. (More people may be added later)

See more inline below  ...

Chris Keller wrote:

Hi Alex,

 

Sorry for the slow response.  Its ok with me if put this discussion back on the general TC mailing list.  Here is some feedback on your response.

 

AII/TII to EII copy: I understand your argument.  The one thing I would say is that if you copy to an EII, some may expect that the EII is cleared of all content (attributes included) and only contains the source information (as it does in an EII to EII copy).  Otherwise to clear the attributes you must clear them individually after the AII/TII copy (also clear may be difficult as a blank attribute is not the same as an empty attribute).  

 

That said as long as we are clear on how it works I can live with it.

 

 

[AYIU]:
Good to hear that you are flexible on this sub-topic. :-)

If people want to clear attributes of an element, I would expect one would do copy an empty element to replace the whole target element. (i.e. the first <copy> below).

Example:
--------------------------------
<assign>
    <copy>
          <from>
                <literal>
                    <foo:bar />
                </iteral>
          </from>
          <to>$var2/foo:bar</to>
    </copy>
    <copy>
          <from> $var1/@attr </from>
          <to> $var2/foo:bar</to>
    </copy>
</assign>
--------------------------------

If we always remove all the attributes of target EII (during a copy from an AII/TII to an EII), I would say that removal is not reversible and is not always what users want. Having a finer grain of replacement would give users a greater flexibility.

Does it make sense?

Using copy to initialize variables:  I have to think more about the substitution group use case.  My first reaction is why is SG only an issue for initialization.  Using your example and adding a second SG and copy:

 

<xsd:element name="myBarPoDoc" substitutionGroup="foo:poDoc>
   ...
</xsd:element>
<xsd:element name="myOtherPoDoc" substitutionGroup="foo:poDoc>
   ...
</xsd:element>
<assign>
    <copy>
       <from> something which returns myBarPoDoc </from>
       <to variable="poVar" />
    </copy>
    <copy>
       <from> something which returns myOtherPoDoc </from>
       <to variable="poVar" />
    </copy>
</assign>

I think this type of example points out my concern about the difference between <copy> for initialization vs. <copy> to initialized.  Also as an implementer it seems that one has to look at the target before the copy to see if you are to perform a replace vs. replace contents, which seems strange.

 

[AYIU]:

After more thinking, I actually agree with your concern of asymmetry here.

I would like to introduce a new attribute called substituteElementName to <copy>, which is applicable to the copy from EII to EII. And, the default value is "no"

(I hope people would not accuse us of adding a new feature. :-) To me, it is more like a semantic clarification results into a minor syntax addition.)

Let me illustrate its semantics by two examples:

Example #1:
---------------------------
<assign>
    <copy substituteElementName="no">
          <from> $var1/p:shippingAddress </from>
          <to> $var2/p:billingAddress </to>
    </copy>
</assign>
---------------------------

All the attribute and children of "shippingAddress" will be copied to "billingAddress", while the element name of "billingAddress" is retained.

Example #2:
---------------------------
<assign>
    <copy substituteElementName="yes">
          <from> $var1/p2:myExtendedPO </from>
          <to> $var2/p:myPO </to>
    </copy>
</assign>
---------------------------

"p2:myExtendPO" is defined with "p:myPO" as a substiutionGroup. All the attribute and children of "p2:myExtendPO" will be copied to "p:myPO", while the element name is also changed.

Please note:

• <copy> is still non-schema-aware (during runtime), after introducing this attribute
• It will remove asymmetry between "variable-initialization" and "element-copy".  Variable-initaization would be greatly simplified by just always initialized with the element name used in the variable declaration. 
• I think the copy table matrix would be streamlined a bit as well.
  

 

Extra Consideration for XML Data Models:  I still have some concerns here.

<from> $amt*$discount </from>
      => returns a float object (NOT a string) from XPath expression evaluation.
<to> $po/@amt</to>
      => points the Text (TII) of attribute of "amt" under PO document
I think the <to> will point to an AII not a TII.  That said I think I understand the gist of what you are saying.  Which is if XPath returns a number (float) or boolean how do we turn that into a TII to move into an AII or EII? And should that conversion be aware of the target schema type?  I think we do need to say something about this for the XPath binding, but I am not sure we should be schema type aware for the target in only this case.

 

[AYIU]:
Yes, my mistake. :-) ... The above <to> points to an AII, not TII. On the other hand, treatment of AII and TII are very similar in our copy table matrix.

And, yes, again this is XPath 1.0 data-model specific consideration. T

The general statement that we want to make in the spec text is: when a different data model is used, some extra semantics of <copy> will be added just like other extensions we have in BPEL. Then, we move on to say we need to pay attention to what specific consideration for XPath 1.0.

To clarify: this feature is not schema-type aware. This is merely XPath 1.0 data model aware.

Use the similar example again:
--------------------------
<assign>
    <copy>
        <from> $amt*$discount </from>
        <to> $po/@amt </to>
    <copy>
</assign>
--------------------------

The from-spec returns a float object, not a TII. And, the to-spec returns an attribute node, of which we don't know the schema type the <copy> context of BPEL 2.0 with XPath 1.0 binding. But, we do know that to-spec is pointing an AII. Therefore, we do know that we need to convert the float object to an TII and use the TII to replace the content at that attribute.


Thanks!



Regards,
Alex Yiu

Regards,

Chris

---

From: Alex Yiu [mailto:alex.yiu@oracle.com]
Sent: Thursday, June 09, 2005 9:03 PM
To: chris.keller@active-endpoints.com; frank.ryan@active-endpoints.com
Cc: Alex Yiu
Subject: Re: [wsbpel] Issue - 157 - (Chris and Frank)

 

Hi Chris and Frank,

I have not heard from you on this email thread.
Does my explanation make sense to you? :-)

Is it OK to forward parts of my reply to back to the public TC mailing list?
(Particularly, the part about SG usage concern)

Thanks!


Regards,
Alex Yiu


Alex Yiu wrote:

Hi Chris,

Would it be OK to add Maciej and Yaron to this cc list?

BTW, this draft was made after the dinner and mid-nite conversion with Yaron. My structuring, wordings and presentation in that rough draft is a bit poor. Please bear with it. :-)

See more inline comment in GREEN.


Chris Keller wrote:

Hi Alex,

Here is some questions/feedback on 157.

Section: Copy to an initialized value

1) Why does an AII to EII clear children only and not attributes?

[AYIU]:

Let me use an example to illustrate the rationale behind this design:

Data before the assign:
--------------------------
<b:billing priority="high">
    <b:amt currency="USD">3456.00</b:amt>
</b:billing>
--------------------------

The assign activity:
--------------------------
<assign>
    <copy>
       <from>$po/@amt</from> <!-- AII -->
       <to>$bill/b:amt</to> <!-- EII -->
    </copy>
</assign>
--------------------------

Data fter the assign, would it better to look like this (i.e. keeping the current attribute)?
--------------------------
<b:billing priority="high">
    <b:amt currency="USD">4567.00</b:amt>
</b:billing>
--------------------------

If we drop the currency attribute, that could be somewhat counter-intuitive.
Would you agree ?

Section: Using <copy> to initialize variables

1) For element type variables I'd rather it say:

For element type variables, a skeleton structure, composed of a DII and an

EII (Document Element), with the element type QName 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.

[AYIU]:
I do understand your concerns. Maybe, I can take some of your wording suggestion with some additional sentences:
-------------------------------------
For element type variables, a skeleton structure, composed of a DII and an EII (Document Element), with QName from the EII returned by the from-spec 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. Since the QName of the EII is determined by the from-spec, the source of <copy> MUST be an EII during variable initialization. This restriction is enforced by either static analysis or a standard runtime "bpws:mismatchedAssignmentFailure" fault MUST be thrown.
-------------------------------------

This extra requirement on the from-spec returning an EII during element variable initialization was raised by Yaron. He expressed concern about the support of SubstitutionGroup during the element varaible initialization.
 
Again, let me use an example to illustrate Yaron's concern: Say, one element <foo:poDoc> is declared in XML Schema. And, another element <bar:myBarPoDoc> is declared as a subsitutionGroup of <foo:poDoc>. That is:
---------------------
<xsd:element name="myBarPoDoc" substitutionGroup="foo:poDoc>
   ...
</xsd:element>
---------------------
And, we have a BPEL element variable is declared based on "foo:poDoc". That is:
---------------------
<bpel:variable name="poVar" element="foo:poDoc" />
---------------------

If we want to support substitutionGroup during element initialization, we cannot "hardcode" the element name of the skeleton structure always as the element name associated with the variable declaration. That is, for the following <assign> activity, one cannot always initialize "poVar" with "foo:poDoc" as doc element name without considering the EII returned by the from-spec, which may return an element of "bar:myBarPoDoc":

---------------------
<assign>
    <copy>
       <from> ... </from>
       <to variable="poVar" />
    </copy>
</assign>
---------------------

I understand that is an advanced / corner case of XSD. But, I guess it is still justified to add this minor extra requirement in the element variable initialization to support XSD pattern.

What do you think?

I think it is confusing having 2 different copy semantics.  By the time the

copy happens it should do the same thing all the time.  The initialization

is separate in my view.

[AYIU]:
I agree with you. :-) ... There is only ONE copy semantics. Yes, variable-initialization and data-replacement are seperate aspects.

Maybe ...  my wordings were not that clear in this rough draft. There are actually two steps:

Step 1: how to initialize a variable with a data skeleton:
Step 2: how to perform "copy" on the initialized data / skeleton

After variable is initialized with a data skeleton, every logic in step (2) can be reused. I believe ... we would incorporate your suggestion similar to above and these 2-step description in our actual proposal draft. That would help nailing down the concept much clearly ... in a less confusing way.

Section: Extra Consideration for XML Data Models

I don't like this section. Do we need it? Calling out boolean/string/float

is too XPath centric.  For example XQuery allows deadlines for example what

if it was your primary expression language.

[AYIU]:
That section has two parts:

• first part: we try to actually declare that different data model can change the behavior of <copy>. This part is XPath 1.0 independent.
• second part: we try to add address some XPath 1.0 specific concern, since XPath 1.0 is the default expression language. The second part is effective, only when XPath 1.0 is used as the expression language.
  [Note: in this version of BPEL spec, we shall try to avoid directly dependencies on XQuery for now. In future version of BPEL spec, I would agree with you that we should add normative text to clarify the relationship between BPEL and XQuery and its data model ]

E.g.:
--------------------------
<assign>
    <copy>
          <from> $amt*$discount </from>
          <to> $po/@amt </to>
    </copy>
</assign>
--------------------------

<from> $amt*$discount </from>
      => returns a float object (NOT a string) from XPath expression evaluation.

<to> $po/@amt</to>
      => points the Text (TII) of attribute of "amt" under PO document

So some conversion needs to happen. Here, we are just merely saying those conversion can happen under our framework.

Similarly, we want to allow manifesting an "xsd:boolean" variable as a boolean object instead of a piece of Text for processing efficiency. The reverse direction of conversion would happen also.



Does all the above make sense?

Thanks!



Regards,
Alex Yiu

- Chris

-----Original Message-----

From: Alex Yiu [mailto:alex.yiu@oracle.com] 

Sent: Thursday, June 02, 2005 12:06 PM

To: wsbpeltc

Cc: ygoland@bea.com; Alex Yiu

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

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