atom feed41 messages in org.oasis-open.lists.wsbpelRe: [wsbpel] Issue - 157 - Proposal F...
FromSent OnAttachments
Yaron Y. GolandMay 26, 2005 12:54 pm 
Danny van der RijnMay 27, 2005 1:42 pm 
Ugo CordaMay 28, 2005 2:43 pm 
Alex YiuMay 28, 2005 4:39 pm 
Yaron Y. GolandMay 31, 2005 2:27 pm 
Ugo CordaMay 31, 2005 4:27 pm 
Ugo CordaMay 31, 2005 5:53 pm 
Assaf ArkinJun 1, 2005 10:45 pm.bin
Alex YiuJun 2, 2005 9:06 am 
Charlton BarretoJun 2, 2005 9:29 am 
Satish ThatteJun 2, 2005 10:51 pm 
Satish ThatteJun 2, 2005 10:52 pm 
Ugo CordaJun 3, 2005 8:17 am 
Ron Ten-HoveJun 3, 2005 8:23 am.bin
Alex YiuJun 3, 2005 8:33 am 
Danny van der RijnJun 3, 2005 9:03 am 
Assaf ArkinJun 3, 2005 9:29 am.bin
Satish ThatteJun 3, 2005 11:35 pm 
Yuzo FujishimaJun 4, 2005 8:11 am 
Satish ThatteJun 4, 2005 3:49 pm 
Yuzo FujishimaJun 5, 2005 6:22 pm 
Alex YiuJun 5, 2005 10:18 pm 
Ugo CordaJun 6, 2005 1:51 pm 
Yaron Y. GolandJun 6, 2005 3:49 pm 
Alex YiuJun 6, 2005 4:15 pm 
Alex YiuJun 6, 2005 4:20 pm 
Harvey G. ReedJun 6, 2005 4:59 pm 
Ugo CordaJun 6, 2005 5:25 pm 
Ugo CordaJun 6, 2005 5:41 pm 
Ugo CordaJun 6, 2005 7:38 pm 
Alex YiuJun 6, 2005 8:59 pm 
Yuzo FujishimaJun 6, 2005 9:07 pm 
Satish ThatteJun 6, 2005 11:02 pm 
Alex YiuJun 7, 2005 12:18 am 
Alex YiuJun 7, 2005 2:05 am 
Yuzo FujishimaJun 7, 2005 4:54 am 
Yaron Y. GolandJun 7, 2005 9:06 am 
Charlton BarretoJun 7, 2005 9:41 am 
Satish ThatteJun 7, 2005 11:00 am 
Ron Ten-HoveJun 7, 2005 11:54 am 
Danny van der RijnJun 7, 2005 4:01 pm 
Subject:Re: [wsbpel] Issue - 157 - Proposal For Vote
From:Alex Yiu (alex@oracle.com)
Date:Jun 6, 2005 8:59:50 pm
List:org.oasis-open.lists.wsbpel

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=[1]"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

References

Visible links 1. http://www.w3.org/1999/XSL/Transform