|
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.yiu@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
|