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

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

Title: Message

Hi Ugo,


Ugo wrote:
"... we just modify the original source tree ..."

It seems to me that you are still suggesting the XSLT processor would modify the source tree during XSLT processing. Is my understanding right??

As for case (1) vs case (2), could I paraphrase a little bit for clarity?
------------------------------------
Case (1) - the result tree is a real new tree and the original source tree stay unmodified for a short time (during the XSLT transformation executation). The result tree is as a tree distinct from the source tree, but after <assign>/<copy> is completed, the original source tree is gone and replaced.
------------------------------------

Then, you ask whether "XSLT could distinguish case 1 from case 2".
I would say yes it can.

Instead of discussing in vaccum without context, let me give an example:

-----------------------------
<assign>
    <copy>
          <from variable="var1" stylesheet="dummy.xslt" />
          <to variable="var1" />
    </copy>
</assign>
-----------------------------

dummy.xslt:
-------------------------
 <xsl:stylesheet version="1.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    <xsl:template match="foo[./../bar[@attr='abc']">
        <xsl:element name="foo2">
            <xsl:attribute name="attr><xsl:value-of select="@attr" /></xsl:attribute>
        </xsl:element>
    </xsl:template>
    <xsl:template match="bar[./../foo[@attr='def']">
        <xsl:element name="bar2">
            <xsl:attribute name="attr><xsl:value-of select="@attr" /></xsl:attribute>
        </xsl:element>
    </xsl:template>
    <xsl:template match="@*|node()">
        <xsl:copy>
            <xsl:apply-templates select="@*|node()"/>
        </xsl:copy>
    </xsl:template>
 </xsl:stylesheet>
-------------------------

After executing the transformation and <assign>/<copy> above, "var1" is supposed to change from:
-------------------------
<myDoc>
    <segment>
        <foo attr="def" />
        <bar attr="abc" />
    </segment>
    <segment>
        <foo attr="123" />
        <bar attr="456" />
    </segment>
</myDoc>
-------------------------

to:
-------------------------
<myDoc>
    <segment>
        <foo2 attr="def" />
        <bar2 attr="abc" />
    </segment>
    <segment>
        <foo attr="123" />
        <bar attr="456" />
    </segment>
</myDoc>
-------------------------

For case (1), the result tree (being copied into "var1" pointed by to-spec by <copy>) is a real new tree and the original source tree (in "var1" pointed by from-spec) stay unmodified for a short time (during the XSLT transformation executation). The result tree is as a tree distinct from the source tree, but after <assign>/<copy> is completed, now the original source tree is gone.


For case (2), the result tree is actually a modification of the original source tree. (That is no distinct copies between source tree and the result tree for "var1".) Actually above XSLT logic will fail, because "foo" is replaced by "foo2". And, the condition related to replacing "bar" with "bar2" is NO LONGER VALID, because the sibiling checking predicate fails.


This example illustrate it is important to keep the source tree unmodified during the execution of XSLT.

Summary

• XSLT does NOT modify data. It creates only new data.
  
• <assign>/<copy> is the BPEL construct that modify data - replacing old data with new data.
  

Thanks!


Regards,
Alex Yiu




Ugo Corda wrote:

Hi Alex,

 

I was not suggesting to modify the original source tree while in the process of executing the XSLT transform. (As you explain below, that could cause infinite loops).

 

What I am suggesting is that, *instead* of executing the whole XSLT transform, we take a short cut: we just modify the original source tree and we say that it is the new tree created by the XSLT transform. If XSLT tries to complain and say "show me the original source tree and demonstrate to me that it was not modified", I would simply say "sorry, the original source tree got destroyed and all that is left is the new tree". In other words, how would XSLT be able to distinguish between these two cases:

 

1- the result tree is a real new tree and the original source tree existed for a short time as a tree distinct from the source tree, but now the source tree is gone

 

2- the result tree is actually a modification of the original source tree, and that is all that is left

 

If XSLT was allowed to look at the tree only after the assignment (i.e. assignment is atomic from the point of view of XSLT in a BPEL context), XSLT could not distinguish case 1 from case 2 (sort of the Turing test for AI ;-).

 

Ugo