[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 157 - Proposal For Vote
I think we should identify the points in dispute and discuss each. (I don't dare to define sub issues at this moment, though.) Below is my trial: [P1] How much should we respect the existing assign/copy? My opinion is that we should NOT stick to assign/copy if there is a much better alternative. Assign/copy has serious problems that we haven't yet solved for more than two years. We might just as well throw assign/copy away. (Possibly except for EPR/literal assignment.) A promising new way is the XSLT-based transformation activity. It is drastically simpler and clearer. If we succeed in defining the transformation activity, there seems to be no reason to keep assign/copy. [P2] Will the XSLT-based transformation activity be unacceptably slow? My opinion is that we should accept the risk of slow execution for the return of simpler and clearer semantics. Additional comments: * Although slow, the activity will not be much slower than invoking transformation web services. * In some cases, one transformation activity can be faster than a sequence of assign activities that achieves the same effect. [P3] XSLT-based transformation activity will replace the whole node tree of a variable (or its part) with a new node tree. Is it semantically acceptable? (As for the performance implications, we have P2 above.) My opinion is that it is totally acceptable. Each variable (and its part) is independent from others. Therefore, whether a variable contains a partially replaced old tree or a new tree created from scratch should not matter. [P4] Should the XSLT-based transformation activity support multiple variables as input? My opinion is YES. Supporting multiple input variables will be essential for simpler transformation description and better performance (cf. P2). Better yet, we already have that as $variable notation. [P5] Should the XSLT-based transformation activity support specifing a subtree of a variable (and its part) as input and output? For example, input = $src.part1/some/XPath output = $dst.part2/another My opinion is NO. Supporting this will result in the similar sets of isseus that assign/copy has. [P6] Which should be specified for an XSLT-based transformation activity, input and output variables (parts), or only the variable to be transformed? My opinion is that only the variable to be transformed should be specified. Any variables in-scope can be the input to the transformation just by refering them by $ notation within the stylesheet. Therefore, I see no points in specifying the input variables as the activity attribute (or subelement). [P7] How a variable should be initialized? If a variable is totally uninitialized, we could not apply transformation stylesheet to it. I am not sure about this yet. My tentative opinion is that an uninitialized target variable should be automatically initialized to <bpel:uninitializedVariable/> as the first execution step of the XSLT-based transformation activity. Yuzo NEC Corporation Ugo Corda wrote: > > 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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]