Alex,
Just to make sure I
am following this, which source document are you saying gets modified with
Ugo’s suggestion?
From: Alex Yiu
[mailto:alex.yiu@oracle.com]
Sent: Monday, June 06, 2005 7: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:
> 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?