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?