[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue - 157 - Proposal For Vote
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
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]