[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue - 157 - Proposal For Vote
While I agree that the XSLT approach w/b a potentially novel use, I feel a) we have enough resources and experience in the TC to make this not nearly as onerous a task as the XPATH exercise, b) the scope of copy limits the time-intensity of pursuing the XSLT approach, and c) XSLT's addressing of this problem set will save us a lot of the cycles we would otherwise spend on the current copy approach. In short, I still feel that XSLT+BPEL is the smoother path and that we should pursue it in place of the current copy approach. -Charlton. -- Adobe Systems, Inc. Server Products Group mailto:cbarreto@adobe.com +1.408.536.4496p -----Original Message----- From: Yaron Y. Goland [mailto:ygoland@bea.com] Sent: Tuesday, June 07, 2005 9:06 AM To: Alex Yiu Cc: Satish Thatte; Yuzo Fujishima; wsbpeltc; Assaf Arkin; Danny van der Rijn; Charlton Barreto Subject: Re: [wsbpel] Issue - 157 - Proposal For Vote Executive Summary: We shouldn't go for a XSLT approach without formally re-opening issue 48. We also shouldn't kid ourselves (as I did to myself yesterday), we don't know what we don't know about XSLT+BPEL and we will be using XSLT in a potentially novel way. This is a huge ship risk to the spec. Upon reflection I believe the least awful option is to just finish copy as is. Long Winded Version: I find myself having to agree with Alex on a number of points. 1 - We did consider exactly this suggestion in issue 48 and it was rejected. Of late we have made a big deal of not undoing previous decisions without due process. I would therefore argue that we shouldn't close issue 157 using a XSLT based solution without some kind of formal decision to re-open 48. 2 - Yesterday I was really happy to use the XSLT solution because it gets me out of the copy business and would make issue 11 go away. But I now realize that I was kidding myself. We don't know what we don't know about XSLT where as we know a lot about the current copy proposal. In terms of 'time to completion' the best choice was to get rid of copy but the group soundly rejected that. So we can either adopt XSLT or finish copy. Adopting XSLT sounds nice (to me at least) because we can inherit a bunch of functionality but the reality is that we would be using XSLT in a potentially novel way and in general we as a group don't have a deep understanding of all the gotchas in embedding XSLT in BPEL. I would remind the group that it took us a full year to embed XPATH into BPEL and that was a much simpler challenge. What took all that time wasn't just figuring out how to represent WSDL messages, that was more a political than technical issue. What really took all the time was figuring out every possible connection point and how to deal with it. Right now we know a lot about XPATH, the infoset and Copy, therefore we are in a reasonably good position to define Copy using those technologies. We don't know what we don't know about XSLT+BPEL and I suspect as we learn we will find many issues and problems that will take us quite some time to figure out. If our goal is to ship this spec I suspect there is much less risk in copy than in XSLT. So I find myself having to reverse my position from yesterday, I propose we stick with the current copy approach. Yaron Alex Yiu wrote: > Yaron, > > *[A]* > This is NOT an implementation issue. > But, this is a _language semantics and specification issue_. > > I add a reply to explain this with an example later. > > *[B]* > BTW, can someone show me an XSLT implementation that will actually > modify the source tree without generating a seperate result tree? > (Please read my quotation from XSLT spec: "_The result tree is > *separate* from the source tree_."). If that XSLT implementation does > not violate the spec, I don't know what implementation will violate > the spec. :-) > > *[C]* > To clarify, I don't mind ADDING an optional "stylesheet" attribute to > the from-spec. I think that is a good feature, _as long as current > <copy> functionalities are kept_. > > BTW, I am curious who voted to close Issue 48 without changes. :-) If > the group really likes the transform features, let us EITHER open a > new issue similar which is somewhat equivalent to Issue 48 OR > re-group the XSLT feature under Issue 11. > > > Thanks! > > > Regards, > Alex Yiu > > > > Yaron Y. Goland wrote: > >> I don't see any of Alex's issues as being show stoppers. >> >> Yes, XSLT is a replace. So what? A dump implementation will be >> expensive and a smart implementation will be cheap. What else is new? >> >> As for the vote, the group agreed to keep assign and copy semantics, >> I would argue that XSLT provides those copy semantics so I don't see >> this action as violating the word or spirit of the motion. >> >> Using XSLT would drastically simplify the specification, allow us to >> avoid re-inventing a whole stack of wheels, provide all the >> functionality we wanted from copy and resolve issue 11. Using XSLT seems like a winner to me. >> >> Yaron >> >> Alex Yiu wrote: >> >>> >>> Hi all, >>> >>> Yuzo, thank you for the sample example also. >>> >>> _*[A] Nature of XSLT*_ >>> >>> The same old reminder to people: XSLT and XQuery are used to _create >>> *NEW* documents or XML fragments based on an existing piece of XML data_. >>> >>> Quotation--1: from the Introduction of XSLT 1.0 Spec: >>> -------------------------------------- >>> A transformation expressed in XSLT describes rules for _transforming >>> a source tree into a result tree_. The transformation is achieved by >>> associating patterns with templates. A pattern is matched against >>> elements in the source tree. A template is instantiated to _*create* >>> part of the result tree_. _The result tree is *separate* from the >>> source tree_. The structure of the result tree can be completely different from the structure of the source tree. ... >>> ... >>> _A template is *instantiated* for a particular source element_ to >>> _*create* part of the result tree_. A template can contain elements >>> that specify literal result element structure. A template can also >>> contain elements from the XSLT namespace that are _instructions for >>> *creating* result tree_ fragments. When a template is instantiated, >>> each instruction is executed and replaced by the result tree fragment that it creates. >>> -------------------------------------- >>> >>> [Note: "replace" here does NOT mean replace the source-tree. It means: >>> replace the instructions in the template with execution result. >>> Think of any web-page-template engine. e.g.: ASP, JSP, PHP.] >>> >>> Typically, an XSLT has a default "catch-all-else" copy rule similar >>> to below to do a copy any nodes from source tree to result tree >>> without any >>> transformation: >>> ----------------------------- >>> >>> <xsl:template match="@*|node()"> >>> <xsl:copy> >>> <xsl:apply-templates select="@*|node()"/> >>> </xsl:copy> >>> </xsl:template> >>> >>> ----------------------------- >>> >>> Quotation--2: [ http://www.w3.org/TR/xslt#copying ] >>> ------------------------------- >>> The xsl:copy element provides an easy way of _*copying* the current node_. >>> _Instantiating the xsl:copy element creates a copy of the current node_. >>> ------------------------------- >>> >>> If the result tree was NOT a distinct copy from the source tree, the >>> above <xsl:copy> would not be needed. In fact, if the above >>> "catch-all-else" copy rule are _NOT used in XSLT_, most of nodes (if >>> not all) in the _source tree will NOT be present in / copied to the result tree_. >>> >>> I hope the above quotations are good enough to prove that XSLT >>> creates NEW documents but NOT replacing any existing docs. If not, >>> we just need to cross reference to our W3C rep in XPath, XSLT, and XQuery WG - TRIO in W3C. >>> >>> Furthermore, XSLT is a non-procedural language. If executation of >>> XSLT were allowed to modify any source or existing XML Document, its >>> semantics can be extremely difficult to be defined. E.g. Will rules >>> in XSLT be re-fired, if the source document got changed? (very hairy >>> business there. Will it result in infinite loop?) >>> >>> In short, XSLT is used to create new documents. _When the base >>> document is large and delta is small, the runtime efficiencies of >>> such an XSLT will be inheritly low. _ >>> >>> >>> _*[B] How to apply XSLT in BPEL *_ >>> >>> Yuzo's example illustrates one of the possible ways to interprete >>> Assaf's original suggestion to apply XSLT in BPEL [i.e. (1b) below]. >>> >>> *(1)* _Using XSLT to transform a variable or a variable part:_ >>> >>> *(1a)* Refering to a variable or a variable part as the source document: >>> -------------------------------- >>> <assign> >>> ... >>> <transform variable="var1" part="part1" >>> stylesheet="http://foo.com/my.xslt"; /> >>> outputVariable="var2" outputPart="part1" /> >>> ... >>> </assign> >>> -------------------------------- >>> Or alternatively using a syntax closer to existing <copy>: >>> -------------------------------- >>> <assign> >>> ... >>> <copy> >>> <from variable="var1" part="part1" >>> stylesheet="http://foo.com/my.xslt"; /> >>> <to variable="var2" part="part1" /> >>> </copy> >>> ... >>> </assign> >>> -------------------------------- >>> >>> *(1b)* Embedding XSLT into BPEL with variable bindings: >>> Examples would be very similar to what Yuzo has provided. >>> >>> (1a) and (1b) are not that different. One allows multiple input variables, >>> while the other allows one variable only. One uses embedded XSLT, one refers >>> the XSLT by a URI. >>> >>> _*(2)* Still using 100% of current <assign>/<copy> syntax._ >>> >>> E.g.: >>> --------------------------- >>> <assign> >>> <copy> >>> <from>$var/p:abc/p:def</from> >>> <to>$var/p:ghi/p:def</to> >>> </copy> >>> </assign> >>> --------------------------- >>> However, when one try to define its semantics of syntax, one may reuse >>> fragments of definitions from XSLT (e.g. "xslt:copy", "xslt:copy-of", >>> "xslt:value-of") >>> >>> >>> _*KEY POINTS to analysis about XSLT facilities:*_ >>> >>> * The biggest difference between (1) and (2) is: the granularity >>> of >>> replacement: >>> ==> _variable or msg-part *VS* any node within a variable or >>> a msg-part >>> >>> _ >>> * I would emphasize that the _replacement of any node is a big part of >>> <assign>/<copy> logic in BPEL 1.1_. Since we passed to keep >>> <assign>/<copy> functionalities, we MUST/SHOULD keep this part of >>> functionality as well. And, 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). >>> >>> * And, leveraging XSLT can be _a totally orthogonal add-on feature to the >>> current <assign>/<copy>_. For example: XSLT features in (1a) and (1b) can >>> be _extended and blended with existing <copy> features_: >>> >>> -------------------------------- >>> <assign> >>> ... >>> <copy> >>> <from> >>> _<transform>_ >>> <!-- embedded XSLT code ... >>> similar to Yuzo's example --> >>> _<transform>_ >>> </from> >>> <to> *$var2.part1/p:lineItem[10]* </to> >>> </copy> >>> ... >>> </assign> >>> -------------------------------- >>> >>> -------------------------------- >>> <assign> >>> ... >>> <copy> >>> <from variable="var1" part="part1" >>> _stylesheet="http://foo.com/my.xslt"_ /> >>> <to> *$var2.part1/p:lineItem[10]* </to> >>> </copy> >>> ... >>> </assign> >>> -------------------------------- >>> >>> * The "xslt:copy", "xslt:copy-of", "xslt:value-of" are used to _*append*_ >>> the execution result of "xslt:*" into the current result tree, which is >>> being created brand-new. It _has NO definition on how to do node >>> replacement_ for an existing doc tree. Regardless whether we go (1a), (1b) >>> or (2), we still need to define a table very similar to the table in my >>> previous Issue 157 email. E.g.: >>> >>> Src\Dest >>> EII >>> AII/TII >>> EII with >>> Complex-Content >>> RE >>> F >>> EII with >>> Simple-Content >>> RE >>> RC >>> AII/TII >>> RC >>> RC >>> >>> >>> Because, we need to define the semantics on how to replace the value >>> pointed by the to-spec withe result of the XSLT transformation. E.g. there >>> should be a fault, if one tries to fill in a simple-typed variable with an >>> element of complex content. (i.e. the Fault caseas denoted by "F" above). >>> >>> Even if somebody tries to cut the corner by removing the capabilties to >>> replace a smaller granularity of variable tree, it will NOT make the >>> definition simplier. Because, the copy/replacement behavior on Attribute >>> (AII) and Text (TII - from simple-typed variable) are virtually the same. >>> (See the table above) >>> >>> In short, _attempt to leverage XSLT concept to simplify Issue 157_ is just >>> a _*"false hope of economy"*_. On the other hand, adding XSLT to BPEL >>> (under Issue 48 or Issue 11) does have its merits in a sense. >>> >>> * To define an XSLT to just do simple-type manipulation is just awkard and >>> anti-ease-of-use. Think of about the case that one needs to increase an >>> counter value. With current <copy>, it is straight forward and easy: >>> <assign> >>> <copy> <from>$count + 1 </from> <to> $count </to> </copy> >>> </assign> >>> >>> Try to do that with an XSLT. ;-) ... Possible but clumsy. >>> >>> * Currently, <assign>/<copy> and Issue 103 are _data-model independent_. >>> That is, we have no bias to any expression language. If BPEL's only >>> operation under <assign> has such a strong dependency on XSLT1.0, the >>> BPEL's expression language independence would be destroyed. (If BPEL spec >>> ever enforces any data model in future, we should enforce XPath 2.0 data >>> model, because of its schemaful nature, instead of >>> XPath1.0/XSLT1.0.) >>> >>> >>> [Side note: Between (1a) and (1b), I prefer (1a), because I am >>> afraid that we would go through another issue 103 exercise, even >>> though we may be able to reuse a number of definitions from Issue >>> 103. ] >>> >>> >>> >>> _*[C] Summary*_ >>> >>> Main goals for Issue 157: >>> >>> * _to clarify the semantics of <copy>_ >>> o The typical and trivial cases in the table <copy> logic are quite >>> clear already. That's why there are more than 3 companies coming up >>> with interpretation in those cases. All we need to clarify those >>> corner cases (e.g. when a standard runtime fault would happen). >>> * _NOT to re-define <copy>_ into a completely different animal and causing >>> all sorts of un-resolvable backward compatibility problems. >>> o We have passed a binding resolution to keep <assign>/<copy>. _If we >>> defined XSLT transform as the only operation under <assign>_, that >>> is virtually getting rid of <copy>. I would argue that is a _direct >>> violation to our binding resolution_ in the F2F in Palo Alto. >>> * Let us focus finish the clarification of <copy> in Issue 157 and call it a >>> day. :-) >>> o I am happy to see a standardized XSLT transform construct also, if >>> we want to _*add *XSLT stylesheet attribute on top of from-spec_. >>> But, _let's put it into Issue 48 or Issue 11_. >>> >>> >>> >>> Thank you for reading such a long email! >>> >>> >>> >>> >>> Regards, >>> Alex Yiu >>> >>> >>> >>> >>> Satish Thatte wrote: >>> >>>> Yuzo, >>>> >>>> Thanks for the example. I will study it. It seems to me that you >>>> have used XPath variable binding in the template, which assumes >>>> that our current Xpath variable binding mechanism would carry over >>>> without additional work. Is that your understanding? >>>> >>>> Satish >>>> >>>> ________________________________ >>>> >>>> From: Yuzo Fujishima [mailto:fujishima@bc.jp.nec.com] >>>> Sent: Sat 6/4/2005 8:11 AM >>>> To: Satish Thatte; wsbpeltc >>>> Cc: Assaf Arkin; Danny van der Rijn; Charlton Barreto >>>> Subject: Re: [wsbpel] Issue - 157 - Proposal For Vote >>>> >>>> >>>> >>>> I don't quite see what are the problems. >>>> >>>> I've written an example and attached the files used. >>>> (Apply assign.xsl to var1.xml. Then you'll get newVar1.xml.) >>>> >>>> Suppose we want to assign from var2 and var3 to var1. >>>> >>>> In that case, we write something similar to assign.xsl (excluding >>>> the variable binding part) within an assign activity. >>>> Perhaps we should rename the activity to "transform". >>>> >>>> The activity should look like below: >>>> >>>> <transform variable="var1"> >>>> <xsl:stylesheet version="1.0" >>>> xmlns:xsl="http://www.w3.org/1999/XSL/Transform";> >>>> <xsl:template match="orderNumber"> >>>> <xsl:element name="orderNumber"> >>>> <xsl:value-of select="$var2/purchaseOrder/orderNumber"/> >>>> </xsl:element> >>>> </xsl:template> >>>> <xsl:template match="billingAddress"> >>>> <xsl:element name="billingAddress"> >>>> <xsl:copy-of select="$var3/customers/customer[ >>>> @id=$var2/purchaseOrder/buyerId]/address/*"/> >>>> </xsl:element> >>>> </xsl:template> >>>> <xsl:template match="@*|node()"> >>>> <xsl:copy> >>>> <xsl:apply-templates select="@*|node()"/> >>>> </xsl:copy> >>>> </xsl:template> >>>> </xsl:stylesheet> >>>> </transform> >>>> >>>> Those parts of var1 that need not be modified are copied by >>>> <xsl:template match="@*|node()"> template. Pretty simple and >>>> idiomatic. >>>> >>>> I noticed that the use of XSLT may sometimes result in more >>>> efficient (rather than inefficient) processing because multiple >>>> assigns can be bunched together to form one transformation. >>>> >>>> How do you like above? >>>> >>>> Yuzo Fujishima >>>> NEC Corporation >>>> >>>> Satish Thatte wrote: >>>> >>>> >>>>> Alex has pointed out various technical difficulties he sees with >>>>> using XSLT to resolve 157, privately to some of us at the F2F. >>>>> The principal one being that XSLT templates costruct new XML >>>>> documents rather than update existing ones. According to Alex, >>>>> doing anything else requires non-standard usage of XSLT. I am no >>>>> XSLT expert so I am looking for confirmation or otherwise of >>>>> Alex's position. If he is right then we are stuck with doing 157 >>>>> as far as I can see. I would much prefer not to add features to >>>>> BPEL for any XML data manipulation, but we have assignment/copy >>>>> today and we have voted not to remove them so the only other >>>>> option is to find a way to use some existing XML data manipulation >>>>> spec as normative with the usual extensibility. XPath is what we have used in copy but that seems to require the sort of xII rules that the current 157 proposals specify. >>>>> >>>>> If someone has a simpler way to resolve this I am all ears. >>>>> >>>>> Satish >>>>> >>>>> ________________________________ >>>>> >>>>> From: Assaf Arkin [mailto:arkin@intalio.com] >>>>> Sent: Fri 6/3/2005 9:28 AM >>>>> To: Danny van der Rijn >>>>> Cc: Satish Thatte; Charlton Barreto; wsbpeltc >>>>> Subject: Re: [wsbpel] Issue - 157 - Proposal For Vote >>>>> >>>>> >>>>> >>>>> I wouldn't rule out that we closed issue 48 because the scope was >>>>> a bit more generic, and from the issue list, apparently because 13 >>>>> solves the problem. So given issue 13 you can incorporate XSLT >>>>> into BPEL as a proprietary extension. >>>>> >>>>> The problem we're facing is how to handle simple assignments as a >>>>> normalized part of the spec, which 48/13 do not cover. I, for one, >>>>> am not interested in re-inventing the wheel, so in this particular >>>>> context I have no problem revisiting issue 48 or resolving this as >>>>> part of issue 157, whichever is more convenient. >>>>> >>>>> Assaf >>>>> >>>>> >>>>> Danny van der Rijn wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> What you're proposing, Satish, sounds like Issue 48, which was >>>>>> rejected in April of 2004. I'd be happy to revisit it, but I'm >>>>>> not sure how others feel. >>>>>> >>>>>> Danny >>>>>> >>>>>> Satish Thatte wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Wonderful. I didn't see this mail before sending mine. >>>>>>> >>>>>>> +1 >>>>>>> >>>>>>> ________________________________ >>>>>>> >>>>>>> From: Charlton Barreto [mailto:cbarreto@adobe.com] >>>>>>> Sent: Thu 6/2/2005 9:29 AM >>>>>>> To: Assaf Arkin >>>>>>> Cc: wsbpeltc >>>>>>> Subject: Re: [wsbpel] Issue - 157 - Proposal For Vote >>>>>>> >>>>>>> >>>>>>> I second this proposal. I feel that we should delegate the >>>>>>> problem scoped by issue 157 by leveraging another spec which is >>>>>>> actually focussed on it, rather than attempting to invest the >>>>>>> considerable amount of time and energy necessary to address it in BPEL. >>>>>>> On 01/06/2005, at 16:08, Assaf Arkin wrote: >>>>>>> >>>>>>> >>>>>>> I want to propose an alternative way to solve issue 157, >>>>>>> without introducing significant complexity to the language. >>>>>>> >>>>>>> The XSLT specification has been dealing with the exact same >>>>>>> problem of evaluating an expression and placing the results in a >>>>>>> target context. XSLT provides two separate mechanisms: copy-of >>>>>>> and value-of. I would propose using these two XSLT elements as a >>>>>>> normative part of the BPEL specification, instead of inventing >>>>>>> yet another copy mechanism. >>>>>>> >>>>>>> http://www.w3.org/TR/xslt#copy-of >>>>>>> http://www.w3.org/TR/xslt#value-of >>>>>>> >>>>>>> Assaf >>>>>>> || >>>>>>> >>>>>>> >>>>>>> <arkin.vcf> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Charlton Barreto >>>>>>> >>>>>>> P 1.408.536.4496 >>>>>>> >>>>>>> cbarreto@adobe.com >>>>>>> >>>>>>> >>>>>>> www.adobe.com <http://www.adobe.com/> logo.gif >>>>>>> >>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe from this mail list, you must leave the OASIS TC that >>>>>>> generates this mail. You may a link to this group and all your TCs >>>>>>> in OASIS >>>>>>> at: >>>>>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe from this mail list, you must leave the OASIS TC that >>>>> generates this mail. You may a link to this group and all your TCs in OASIS >>>>> at: >>>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe from this mail list, you must leave the OASIS TC that >>>> generates this mail. You may a link to this group and all your TCs in OASIS >>>> at: >>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >>>> >>>> >>> >> > --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]