[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 157 - Proposal For Vote
I agree that we should vote on re-opening 48. We're certainly discussing it already. That discussion will be fruitless without re-opening 48. Conversely, if we don't have the stomach to re-open it, then we shouldn't be bothering to discuss it. Yaron Y. Goland wrote: > 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 >>>>> >>>>> >>>> >>> >> > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]