OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [wsbpel] Issue - 157 - Proposal For Vote


Title: Message
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]