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


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]