Yuzo,

Summary: I would like to add XSLT transformation feature standardized on top of the existing <copy> construct.

See more inline comment in GREEN:

Yuzo Fujishima wrote:

I think we should identify the points in dispute and discuss each. (I don't dare to define sub issues at this moment, though.) Below is my trial:

[P1] How much should we respect the existing assign/copy?

My opinion is that we should NOT stick to assign/copy if there is a much better alternative. Assign/copy has serious problems that we haven't yet solved for more than two years. We might just as well throw assign/copy away. (Possibly except for EPR/literal assignment.)

A promising new way is the XSLT-based transformation activity. It is drastically simpler and clearer. If we succeed in defining the transformation activity, there seems to be no reason to keep assign/copy.

[AYIU]: IMHO, it is very clear that the XSLT feature acts a complement, not a replacement to <assign>/<copy>. Quite a number of <assign>/<copy> would be modeled in a clumpsy way and awkward way in XSLT:

Example #1: <assign> <copy> <from> $counter + 1 </from> <to> $counter </to> </copy> </assign>

Example #2: <assign> <copy> <from> 333 </from> <to> $var/p:abc/@attr </to> </copy> </assign>

Also, typical XSLT usage pattern is too flexible to enable any static type analysis, when compared with <assign>/<copy> with XPath.

IMHO, NO effort has been spent to refine the semantics of <assign>/<copy> until very recently during the last 2 yrs. If we did not get diverted in the F2F, we could have agreed on the bulk text for issue 157 already.

That is exactly what I am going to do - continue to finish the clarification of <copy> semantics.

[P2] Will the XSLT-based transformation activity be unacceptably slow?

My opinion is that we should accept the risk of slow execution for the return of simpler and clearer semantics.

Additional comments: * Although slow, the activity will not be much slower than invoking transformation web services. * In some cases, one transformation activity can be faster than a sequence of assign activities that achieves the same effect.

[AYIU]: "In some cases, one transformation activity can be faster than a sequence of assign activities that achieves the same effect." Any particular examples? or proof?

Apart from data copy-vs-modification concern (see more below), an XSLT processor traverses every single node in the input document with most of typical XSLT design patterns, while the existing <assign>/<copy> would touch the nodes pointed by the from-spec and to-spec only. Yet another computation (CPU, I/O, memory) overhead naturally inherited in XSLT, (That's one of the reason on why XQuery is invented to do certain tasks better, when compared with XSLT.)

[P3] XSLT-based transformation activity will replace the whole node tree of a variable (or its part) with a new node tree. Is it semantically acceptable? (As for the performance implications, we have P2 above.)

My opinion is that it is totally acceptable. Each variable (and its part) is independent from others. Therefore, whether a variable contains a partially replaced old tree or a new tree created from scratch should not matter.

[AYIU]: Yuzo, have you got a chance to read the XSLT example that I sent out earlier? The one which will fail to execute when the input data is being modified on the fly.

Yuzo, I would like to clarify ... Are you advocating that we should enourage people to implement an XSLT processor that modifies the input data on-the-fly during XSLT processing?

If so, we are asking BPEL implementation to ignore the computation model specified by XSLT spec and to create one big short-circuit implementation between BPEL and XSLT to enable this "optimization". I don't think this short-circuit implementation should be sanctioned by the BPEL spec. By replacing <copy> completely with a XSLT feature, it is equivalent of sanctioning such an implementation direction and requiring every BPEL implementation to break the modularity line between BPEL and XSLT and twist its implementation against the XSLT spec to enable this optimization.

Personally, I have a number of doubts on how feasible this optimization is. If one vendor take the risk to create such an implementation, that vendor would be responsible for its own implementation.We should not force every vendors to implement against the natural model specified by XSLT spec.

(I would send out another email for the opinion from other W3C experts on this subject.)

[P4] Should the XSLT-based transformation activity support multiple variables as input?

My opinion is YES. Supporting multiple input variables will be essential for simpler transformation description and better performance (cf. P2). Better yet, we already have that as $variable notation.

[AYIU]: This part I would agree with Yuzo. :-) It's a more feature rich to have multiple variable bindings in XSLT. Let's do it, if everyone loves XSLT and if XSLT is an add-on to <copy>. ;-)

[P5] Should the XSLT-based transformation activity support specifing a subtree of a variable (and its part) as input and output? For example, input = $src.part1/some/XPath output = $dst.part2/another

My opinion is NO. Supporting this will result in the similar sets of isseus that assign/copy has.

[AYIU]: I would disagree with this part. Because, even if we do not support specifying a subtree as the output, we already need to define and support the following data copy pattern: element-to-element, text-to-element, element-to-text, text-to-text.

For the source-part, XSLT can produce either XML element or plain text. For the destination-part, we have simple type variable (text) and element-based / complex-type-based variable (element).

Adding specifying a subtree as the output DO NOT add any complication. (Attribute and Text are treated identically in the context of copy).

[P6] Which should be specified for an XSLT-based transformation activity, input and output variables (parts), or only the variable to be transformed?

My opinion is that only the variable to be transformed should be specified. Any variables in-scope can be the input to the transformation just by refering them by $ notation within the stylesheet. Therefore, I see no points in specifying the input variables as the activity attribute (or subelement).

[AYIU]: Clarification needed. Do you mean the XSLT does not have a root input document? That is not the case in your previous XSLT example, where the root input document is "var1". Even though it is possible to write an XSLT without relying on any root input document, those XSLT usually are counter-intuitive.

However, this is a relative smaller level details of XSLT feature I would add.

[P7] How a variable should be initialized? If a variable is totally uninitialized, we could not apply transformation stylesheet to it.

I am not sure about this yet.

My tentative opinion is that an uninitialized target variable should be automatically initialized to <bpel:uninitializedVariable/> as the first execution step of the XSLT-based transformation activity.

[AYIU]: This is another reason why it make me worry on using XSLT to displace <copy> completely. What about simple-typed variable? Do you mean now that we need to write an XSLT to just do the following?

<assign> <copy> <from>1 </from> <to> $counter </to> </copy> </assign>

Regards, Alex Yiu

Yuzo

NEC Corporation

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

-----Original Message----- *From:* Alex Yiu [mailto:alex...@oracle.com] *Sent:* Monday, June 06, 2005 4:20 PM *To:* Ugo Corda *Cc:* wsbpeltc; Alex Yiu *Subject:* Re: [wsbpel] Issue - 157 - Proposal For Vote

Hi, all,

The quotation Ugo made is under the section of Section 5. "Template Rules" and Section 5.1 "Processing Model": ----------------------------------- A list of source nodes is processed to create a result tree fragment. The result tree is constructed by processing a list containing just the root node. A list of source nodes is processed by appending the result tree structure created by processing each of the members of the list in order ... Implementations are free to process the source document in any way that produces the same result as if it were processed using this processing model. -----------------------------------

The *context* is how an XSLT processor process the source document and match and fire the template rules. The optimization allowed may include:

* indexing of the source document * using different data models: DOM, SAX, XPath, ... * parallelism of template rule application

Modifying the source document is NOT the same result . That is a big semantic change. NOT just an optimization.

If we allow modifying an source document, it will introduce "/von Neumann/" style computation back to XSLT, which is known to have problems with non-procedural languages (e.g. XSLT and XQuery). The modification creates a bunch of problems of current XSLT / XQuery design do no cater for. E.g. whether to re-fire some template rules after the source document is modified.

A detailed example: ------------------------- <xsl:template match="foo"> <xsl:element name="bar"> ... </xsl:element> </xsl:template> <xsl:template match="bar"> <xsl:element name="foo"> ... </xsl:element> </xsl:template> -------------------------

We have a template rule that transforms the "foo" element into the "bar" element. And, we have another rule which transform "bar" element into "foo" element.

If the source document is NOT modified, its semantics is very clear. It is a "flipping" XSLT : all "foo" elements are flipped to "bar", while all "bar" elements are flipped to "foo".

However, if the source document is modified, will we run into an infinite loop?

Also, allowing modification of source document essentially destroy the parallelism of template rule application.

Regards, Alex Yiu

Ugo Corda wrote:

Hi Alex,

not having the capabilities of a smaller granularity of

replacement has a BIG impact on efficiency of <assign> .

For example: in order to replace a small zip code field of a

large PO documents (e.g. 100 line items), we would effectively copy all those 100 line items.

That is NOT an implementation-dependent issue. The XSLT spec

clearly shows its intention (see the quotations above). I am not convinced that XSLT actually imposes those limitations on an implementation optimization. For instance, sec. 5.1 of XSLT 1.0, Processing Model, states: "Implementations are free to process the source document in any way that produces the same result as if it were processed using this processing model". So, suppose that the large PO document is in my target variable, and I want to replace just a zip code field. Evidently I don't care about preserving the original PO document as a separate independent entity, since all I care is that, after the assign, the variable contains the modified PO. If the original PO is in DOM form, what would prevent my implementation from just replacing the zip code field and then pretending that the modified DOM is actually the DOM representing the whole new PO document resulting from the XSLT transform, *as if* the modified PO actually got generated applying the copy/creation semantics as described in the XSLT process model? Ugo

--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php