[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 11 - Ambiguous insertion points
sounds good. i'm out the rest of the week, but i'll try to get mine in soon. danny ----- Original Message ----- From: "Chris Keller" <chris.keller@active-endpoints.com> To: "'Danny van der Rijn'" <dannyv@tibco.com>; <> Sent: Wednesday, August 13, 2003 4:09 PM Subject: RE: [wsbpel] Issue - 11 - Ambiguous insertion points > Danny, > > Yes that is your proposal. Should we each reformulate our proposals and > submit them to the list. All the running commentary and evolving > thoughts make it difficult to follow the thread. > > BTW - I am not against the new assign operations types (beyond copy) > being introduced. My thinking was the expression (with new bpws: > functions) based approach would allow us to use copy to/from for most of > the use cases and would introduce very little changes in the current > specification. I think the outcome is the same either way. We > introduce a more functional mapping capability to assign. > > Chris > > -----Original Message----- > From: Danny van der Rijn [mailto:dannyv@tibco.com] > Sent: Wednesday, August 13, 2003 5:45 PM > To: wsbpel@lists.oasis-open.org > Subject: Re: [wsbpel] Issue - 11 - Ambiguous insertion points > > edwin - > > this is pretty much my proposal. read down about 25 included messages > ;-) > > danny > ----- Original Message ----- > From: "Edwin Khodabakchian" <edwink@collaxa.com> > To: <chris.keller@active-endpoints.com>; "'Danny van der Rijn'" > <dannyv@tibco.com>; <wsbpel@lists.oasis-open.org> > Sent: Wednesday, August 13, 2003 2:39 PM > Subject: RE: [wsbpel] Issue - 11 - Ambiguous insertion points > > > > Chris, > > > > Do you think that it would be possible to transpose > > > > <assign> > > <copy> > > <from expression="'blah'"/> > > <to expression="bpws:insertVariableNode('variable', > > 'part', > > 'bar, > > '/foo', > > blah') > > /> > > </copy> > > </assign> > > > > To a more data driven approach > > > > <assign> > > <insert position=".."> > > <from...> > > <to...> > > </insert> > > </assign> > > ? > > > > Thoughts? > > > > > > > -----Original Message----- > > > From: Chris Keller [mailto:chris.keller@active-endpoints.com] > > > Sent: Wednesday, August 13, 2003 2:18 PM > > > To: 'Danny van der Rijn'; wsbpel@lists.oasis-open.org > > > Subject: RE: [wsbpel] Issue - 11 - Ambiguous insertion points > > > > > > Danny, > > > > > > I agree that we need to develop one of these into a > > > reasonable proposal. > > > Perhaps if some of the other active discussers of this issue > > > could chime in then we can decide on how to move forward. > > > > > > In response to your last set of questions/clarifications: > > > > > > <DV> no, it's due to the fact that the function inserts a > > > node (empty i assume. validation?) whose sole purpose is to > > > be <copy>d over. so the node needs to be created, and then > > > immediately it's garbage. </DV> > > > > > > Perhaps, but in my thinking it is the empty content being > > > replaced not the node itself. And I assume validation is at > > > the end of the activity and during the execution of any > > > activity the content is more volatile. > > > > > > <DV> i think i understand. is it right that if you want to > > > cause this to do "my" append, you leave off the child > > > expression? if so, how do you choose which child of the > > > parent the new expression will become? </DV> > > > > > > You are right. The child is specified by the childQName (the > > > third parameter). Also we have some mistakes in the document > > > fragments resulting from the examples (the blah text was not shown): > > > > > > <copy> > > > <from expression="'blah'"/> > > > <to expression="bpws:insertVariableNode('variable', 'part', > > > 'bar, '/foo', blah')/> </copy> > > > > > > It would create the following fragment: > > > > > > <foo> > > > <bar>blah</bar> > > > <blah/> > > > </foo> > > > > > > The same goes for the other fragments. > > > > > > Chris > > > > > > -----Original Message----- > > > From: Danny van der Rijn [mailto:dannyv@tibco.com] > > > Sent: Wednesday, August 13, 2003 4:33 PM > > > To: wsbpel@lists.oasis-open.org > > > Subject: Re: [wsbpel] Issue - 11 - Ambiguous insertion points > > > > > > i'm starting to understand your syntax some more. my > > > question is where do we go from here? we're going to have to > > > develop one of these into a reasonable proposal. i'd prefer > > > not to do both. > > > > > > additional comments inline with <DV>. > > > > > > ----- Original Message ----- > > > From: "Chris Keller" <chris.keller@active-endpoints.com> > > > To: "'Danny van der Rijn'" <dannyv@tibco.com>; > > > <wsbpel@lists.oasis-open.org> > > > Sent: Wednesday, August 13, 2003 12:27 PM > > > Subject: RE: [wsbpel] Issue - 11 - Ambiguous insertion points > > > > > > > > > > Danny - > > > > > > > > See clarifications below (marked with CK>>>) > > > > > > > > Also got your note on remove and rename, agreed still an open > issue > > > > using my syntax. > > > > > > > > Chris > > > > > > > > -----Original Message----- > > > > From: Danny van der Rijn [mailto:dannyv@tibco.com] > > > > Sent: Wednesday, August 13, 2003 3:10 PM > > > > To: wsbpel@lists.oasis-open.org > > > > Subject: Re: [wsbpel] Issue - 11 - Ambiguous insertion points > > > > > > > > ahh. i got confused by the 'bar' in the to expression from > before. > > > > > > > > > <copy> > > > > > <from .../> > > > > > <to expression="bpws:insertVariableNode('variable', 'part', > > > > > 'bar','/foo', > > > 'blah')/> > > > > > </copy> > > > > > > > > in your latest clarification it goes to the <from> element > > > if i'm not > > > > mistaken. > > > > > > > > so now we're down to the nitty gritty details. thank goodness ;-) > > > i'm > > > > perfectly happy with the overall format of your suggestion. > > > however, > > > i > > > > have > > > > some objections to parts of it. > > > > > > > > objection #1: i don't like the idea of a function creating > > > a node that > > > > is > > > > about to be changed by the <copy> element. that's extra overhead. > > > > > > > > CK>>> Unsure if there is much overhead, this could be caused by > > > > CK>>> the confusion that the child path(s) is relative to the > > > > CK>>> parent path which I point out more below. > > > > > > > > > > <DV> no, it's due to the fact that the function inserts a > > > node (empty i > > > assume. validation?) whose sole purpose is to be <copy>d > > > over. so the > > > node > > > needs to be created, and then immediately it's garbage. </DV> > > > > > > > objection #2: you still don't differentiate between inserting > before > > > and > > > > after. when operating on yaron's now canonical > > > > > > > > <foo> > > > > <blah/> > > > > </foo> > > > > > > > > and the function is > > > > <copy> > > > > <from expression="'blah'"/> > > > > <to expression="bpws:insertVariableNode('variable', 'part', > > > '/foo/bar, > > > > '/foo', /foo/blah')/> > > > > </copy> > > > > > > > > do you get > > > > <foo> > > > > <bar> > > > > <blah> > > > > </foo> > > > > (insert before) > > > > > > > > or > > > > > > > > <foo> > > > > <blah> > > > > <bar> > > > > </foo> > > > > (insert after) > > > > > > > > just to be clear, my proposed append operation would yield > > > > <foo> > > > > <blah> > > > > <bar/> > > > > </blah> > > > > </foo> > > > > with the optional parameter determining between which siblings bar > > > would > > > > get > > > > placed. in this case, there were no siblings, so the parameter > was > > > > moot. > > > > > > > > CK>>> I believe the confusion is caused by the fact that my > > > childPath > > > > CK>>> is relative to the parent path so it should read: > > > > CK>>> <copy> > > > > CK>>> <from expression="'blah'"/> > > > > CK>>> <to expression="bpws:insertVariableNode('variable', 'part', > > > > 'bar', > > > > CK>>> '/foo', blah')/> > > > > CK>> </copy> > > > > CK>>> > > > > CK>>> which would produce: > > > > CK>>> <foo> > > > > CK>>> <bar> > > > > CK>>> <blah> > > > > CK>>> </foo> > > > > CK>>> > > > > CK>>> and the flip side would be > > > > CK>>> <copy> > > > > CK>>> <from expression="'blah'"/> > > > > CK>>> <to expression="bpws:appendVariableNode('variable', 'part', > > > > 'bar', > > > > CK>>> '/foo', blah')/> > > > > CK>> </copy> > > > > CK>>> > > > > CK>>> which would produce: > > > > CK>>> <foo> > > > > CK>>> <blah> > > > > CK>>> <bar> > > > > CK>>> </foo> > > > > CK>>> > > > > > > > > > > <DV> i think i understand. is it right that if you want to cause > this > > > to do > > > "my" append, you leave off the child expression? if so, how do you > > > choose > > > which child of the parent the new expression will become? </DV> > > > > > > > objection #3: i'm not thrilled with the overloading (optional > > > parameter > > > > changes function from append to insert). > > > > > > > > CK>>> ok, but there is precedent in the specification with the > > > > CK>>> bpws:getVariableData function. > > > > > > > > > > <DV> it's not overloading in general that i'm opposed to. i think > that > > > the > > > current overloading is a bit more clear. </DV> > > > > > > > > > > > objection #4: might not be an objection, but it looks to me > > > like some > > > of > > > > the > > > > parameters are redundant. > > > > > > > > CK>>> I think this is caused by the misunderstanding on the > relative > > > > nature > > > > CK>>> of the child paths and nodes. > > > > > > > > > > <DV> got it. </DV> > > > > > > > feeling like a lot of progress is being made (even if it's > > > just the 2 > > > of > > > > us > > > > reading...) > > > > > > > > CK>>> Agreed > > > > > > > > danny > > > > > > > > ----- Original Message ----- > > > > From: "Chris Keller" <chris.keller@active-endpoints.com> > > > > To: "'Danny van der Rijn'" <dannyv@tibco.com>; > > > > <wsbpel@lists.oasis-open.org> > > > > Sent: Wednesday, August 13, 2003 11:39 AM > > > > Subject: RE: [wsbpel] Issue - 11 - Ambiguous insertion points > > > > > > > > > > > > > Understood, the xupdate usage was functionality not > > > syntax. Thanks > > > > for > > > > > clarifying. In that case I think we are in heated agreement. > We > > > only > > > > > deviate in the style in which it should be implemented. In the > > > style > > > > of > > > > > copy I suggested the <from> contains the data to be copied to > the > > > > newly > > > > > created node which the function created and placed (as dictated > by > > > the > > > > > parameters) in the XML fragment. Here is a proposed > > > syntax for your > > > > use > > > > > cases. > > > > > > > > > > Case 1: > > > > > <insertBefore> > > > > > <from/> > > > > > <to select="XPath Expression evaluates to one node"/> > > > > > </insertBefore> > > > > > creates a sibling before the select expression > > > > > > > > > > becomes: > > > > > <copy> > > > > > <from/> > > > > > <to expression="bpws:insertVariableNode('variable', > > > 'part', 'qname > > > > of > > > > > new element, 'parentPath part of your xpath expression > > > evaluates to > > > > one > > > > > node', 'path of sibling to insert before evaluate to one > node')/> > > > > > </copy> > > > > > > > > > > The reason for splitting the parent and sibling paths in > > > my function > > > > is > > > > > that the sibling path is optional, which is a reasonable use > case. > > > > > > > > > > Case 2 > > > > > <insertAfter> > > > > > <from/> > > > > > <to select="XPath Expression evaluates to one node"/> > > > > > </insertAfter> > > > > > creates a sibling after the select expression > > > > > > > > > > Becomes: > > > > > <copy> > > > > > <from/> > > > > > <to expression="bpws:appendVariableNode('variable', > > > 'part', 'qname > > > > of > > > > > new element, 'parentPath part of your xpath expression > > > evaluates to > > > > one > > > > > node', 'path of sibling to append after evaluates to one > node')/> > > > > > </copy> > > > > > > > > > > Case 3: > > > > > <append> > > > > > <from/> > > > > > <to select="XPath Expression evaluates to one node" > > > child="integer > > > > > XPath > > > > > expression"? /> > > > > > <append> > > > > > creates a child of select expression at the child-th position. > > > child > > > > > defaults to last(). > > > > > > > > > > Becomes: > > > > > <copy> > > > > > <from/> > > > > > <to expression="bpws:appendVariableNode('variable', > > > 'part', 'qname > > > > of > > > > > new element, 'parentPath xpath expression evaluates to > > > one node')/> > > > > > </copy> > > > > > Just remove optional sibling path and it defaults to last(). > > > > > > > > > > Case 4: > > > > > <remove select="XPath expression evaluates to one node"> > > > > > removes a node > > > > > > > > > > Becomes: > > > > > Sorry didn't introduce a remove, but I agree this could have > some > > > > value. > > > > > > > > > > Case 5: > > > > > <rename select="XPath expression evaluates to one node" > > > > > newName="ncname"/> > > > > > for completeness, don't have strong feelings about its inclusion > > > > > > > > > > Becomes: > > > > > Sorry didn't introduce a rename. > > > > > > > > > > > > > > > > > > > > I hope this helps clarify the proposal. > > > > > > > > > > Chris > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Danny van der Rijn [mailto:dannyv@tibco.com] > > > > > Sent: Wednesday, August 13, 2003 2:10 PM > > > > > To: wsbpel@lists.oasis-open.org > > > > > Subject: Re: [wsbpel] Issue - 11 - Ambiguous insertion points > > > > > > > > > > > The main reason for the XPath route was in response to Yaron's > > > > comment > > > > > > on finishing the standard on time. And this seemed like an > > > > acceptable > > > > > > compromise since it deviates very little from the current > > > > > specification. > > > > > > Introducing the xupdate syntax seemed like a bigger nut to > crack > > > and > > > > > it > > > > > > also introduces a dependency on another specification, which > > > people > > > > > > would need to digest. > > > > > > > > > > i'm not suggesting a dependency on XUpdate, just the concepts > from > > > it, > > > > > which > > > > > we're already bandying around. i'm simply using XUpdate as > > > shorthand > > > > > for > > > > > the functionality that we're talking about, in whatever > syntactic > > > form > > > > > it > > > > > comes in. > > > > > > > > > > > <copy> > > > > > > <from .../> > > > > > > <to expression="bpws:insertVariableNode('variable', > 'part', > > > > > > 'bar','/foo', > > > 'blah')/> > > > > > > </copy> > > > > > > > > > > so what's the point of the <from> clause here? > > > > > > > > > > i'm not sure why changing BPEL syntax is different from > > > adding XPath > > > > > functions, but i realize that i haven't been too explicit > either. > > > > what > > > > > i'm > > > > > looking at is the following possible elements under <assign>: > > > > > > > > > > <copy> > > > > > <from/> > > > > > <to/> > > > > > </copy> > > > > > as current. > > > > > > > > > > <insertBefore> > > > > > <from/> > > > > > <to select="XPath Expression evaluates to one node"/> > > > > > </insertBefore> > > > > > creates a sibling before the select expression > > > > > > > > > > <insertAfter> > > > > > <from/> > > > > > <to select="XPath Expression evaluates to one node"/> > > > > > </insertAfter> > > > > > creates a sibling after the select expression > > > > > > > > > > <append> > > > > > <from/> > > > > > <to select="XPath Expression evaluates to one node" > > > child="integer > > > > > XPath > > > > > expression"? /> > > > > > <append> > > > > > creates a child of select expression at the child-th position. > > > child > > > > > defaults to last(). > > > > > > > > > > <remove select="XPath expression evaluates to one node"> > > > > > removes a node > > > > > > > > > > <rename select="XPath expression evaluates to one node" > > > > > newName="ncname"/> > > > > > for completeness, don't have strong feelings about its inclusion > > > > > > > > > > end result: nice clean syntax; nothing too major added; > hopefully > > > > > doesn't > > > > > require a lot more work, spec can go forward. > > > > > > > > > > ----- Original Message ----- > > > > > From: "Chris Keller" <chris.keller@active-endpoints.com> > > > > > To: "'Danny van der Rijn'" <dannyv@tibco.com>; > > > > > <wsbpel@lists.oasis-open.org> > > > > > Sent: Wednesday, August 13, 2003 10:37 AM > > > > > Subject: RE: [wsbpel] Issue - 11 - Ambiguous insertion points > > > > > > > > > > > > > > > > Danny - > > > > > > > > > > > > Sorry, I should have been more explicit with the example. > Let's > > > > take > > > > > > the case Yaron had brought up of /foo/blah and we would like > to > > > > insert > > > > > > bar as a child of foo before blah. > > > > > > > > > > > > So before the copy the document fragment looks like: > > > > > > <foo> > > > > > > <blah/> > > > > > > </foo> > > > > > > > > > > > > We execute the following copy: > > > > > > > > > > > > <copy> > > > > > > <from .../> > > > > > > <to expression="bpws:insertVariableNode('variable', > 'part', > > > > > > 'bar','/foo', > > > 'blah')/> > > > > > > </copy> > > > > > > > > > > > > The result would be: > > > > > > > > > > > > <foo> > > > > > > <bar>...</bar> > > > > > > <blah/> > > > > > > </foo> > > > > > > > > > > > > If instead we had executed the following copy: > > > > > > > > > > > > <copy> > > > > > > <from .../> > > > > > > <to expression="bpws:appendVariableNode('variable', > 'part', > > > > > > 'bar','/foo', > > > 'blah')/> > > > > > > </copy> > > > > > > > > > > > > The result would be: > > > > > > > > > > > > <foo> > > > > > > <blah/> > > > > > > <bar>...</bar> > > > > > > </foo> > > > > > > > > > > > > The "append" versus "insert" would be used to decide whether > you > > > are > > > > > > appending the new child or inserting the new child. If the > > > sibling > > > > > name > > > > > > is not specified then this results in putting the new > > > child at the > > > > end > > > > > > of the list or beginning of the list of children respectively. > > > > > > > > > > > > I don't know if we need more than these two for > > > positioning, but I > > > > > could > > > > > > be wrong. If we want rename and remove functionality > (although > > > > rename > > > > > > is less of an issue it is hard to make a case for when that is > > > > needed) > > > > > > we could do that by adding the functions that you > > > mentioned. Also > > > I > > > > > > think we can leave the <copy><to...> as an update and let the > > > > > functions > > > > > > handle the node creation and return of the new single node > list. > > > > > > > > > > > > The main reason for the XPath route was in response to Yaron's > > > > comment > > > > > > on finishing the standard on time. And this seemed like an > > > > acceptable > > > > > > compromise since it deviates very little from the current > > > > > specification. > > > > > > Introducing the xupdate syntax seemed like a bigger nut to > crack > > > and > > > > > it > > > > > > also introduces a dependency on another specification, which > > > people > > > > > > would need to digest. > > > > > > > > > > > > Chris > > > > > > > > > > > > -----Original Message----- > > > > > > From: Danny van der Rijn [mailto:dannyv@tibco.com] > > > > > > Sent: Wednesday, August 13, 2003 1:07 PM > > > > > > To: wsbpel@lists.oasis-open.org > > > > > > Subject: Re: [wsbpel] Issue - 11 - Ambiguous insertion points > > > > > > > > > > > > chris - > > > > > > > > > > > > i'm not sure i see how the new functions would be used. > > > could you > > > > > give > > > > > > an > > > > > > example? also, the insertVariableNode is ambiguous, as > > > yaron has > > > > > > pointed > > > > > > out - you'd need an insertVariableNodeBefore, and an > > > > > > insertVariableNodeAfter. > > > > > > > > > > > > after you do that, you could include a removeVariableNode and > a > > > > > > renameVariableNode. if you do that, you've got all the > > > > functionality > > > > > of > > > > > > my > > > > > > previous suggestion. > > > > > > > > > > > > i don't have particularly strong feelings about the > > > syntax for the > > > > > > provided > > > > > > functionality, although i have a mild bias against XPath > > > functions. > > > > > > > > > > > > one thing i would like to do, however, is reconcile whatever > > > syntax > > > > we > > > > > > come > > > > > > up with with the <copy><to> syntax, as it's really just an > > > > > > updateVariableNode XPath function, and i think that it would > be > > > ugly > > > > > to > > > > > > have > > > > > > different syntax for update than the others. > > > > > > > > > > > > danny > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Chris Keller" <chris.keller@active-endpoints.com> > > > > > > To: <wsbpel@lists.oasis-open.org> > > > > > > Cc: "'Danny van der Rijn'" <dannyv@tibco.com>; > > > <ygoland@bea.com>; > > > > > > <Gnosis_@compuserve.com> > > > > > > Sent: Wednesday, August 13, 2003 6:34 AM > > > > > > Subject: RE: [wsbpel] Issue - 11 - Ambiguous insertion points > > > > > > > > > > > > > > > > > > > Here is another idea for solving this issue. > > > > > > > > > > > > > > Allow the <to> element to contain an expression with the > > > following > > > > > > > restrictions. > > > > > > > - It must evaluate to exactly one node like the query > > > > > > > restriction. > > > > > > > - It must not be in an abstract process (same rationale as > > > > > > > query). > > > > > > > > > > > > > > Then we introduce new XPath functions which are mandatory > for > > > BPEL > > > > > > > implementations. > > > > > > > bpws:appendVariableNode('variable', 'part', 'childQname', > > > > > > > 'parentPath'[, 'siblingQname']) > > > > > > > bpws:insertVariableNode('variable', 'part', 'childQname', > > > > > > > 'parentPath'[, 'siblingQname']) > > > > > > > > > > > > > > These methods could be used to create specific children at > the > > > > right > > > > > > > levels. We may need to have a few more functions. But > anyone > > > > > > > implementing a BPEL engine must already make new functions > > > > available > > > > > > to > > > > > > > the XPath processor. And this seems like the least > deviation > > > from > > > > > the > > > > > > > current specification and allows some great flexibility. > > > Although > > > > > we > > > > > > > may need a few more functions (TBD). > > > > > > > > > > > > > > The user could theoretically use the current copy <to > > > > > variable='...'> > > > > > > > for example: > > > > > > > <to variable='varname' part='partname' query='querypath'/> > > > > > > > > > > > > > > Or an equivalent: > > > > > > > <to expression="bpws:getVariableData('varname', 'part', > > > > > > 'querypath')"/> > > > > > > > > > > > > > > This particular case is a little redundant, but we have that > > > > > somewhat > > > > > > > already with literal and expression, since an > > > expression can be > > > > just > > > > > a > > > > > > > quoted string. > > > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > > > - Chris > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Danny van der Rijn [mailto:dannyv@tibco.com] > > > > > > > Sent: Tuesday, August 12, 2003 2:05 PM > > > > > > > To: wsbpel@lists.oasis-open.org > > > > > > > Subject: Re: [wsbpel] Issue - 11 - Ambiguous insertion > points > > > > > > > > > > > > > > david- > > > > > > > > > > > > > > without allowing XSLT multiple inputs, you have the choice > of > > > > either > > > > > > > creating some new data, or rebuilding some variable based > only > > > on > > > > > > > itself. i > > > > > > > submit that if we don't want to deal with multiple inputs > for > > > XSLT > > > > > > (and > > > > > > > i > > > > > > > don't say that we do), then we absolutely need something > like > > > > > XUpdate, > > > > > > > since > > > > > > > the current spec doesn't have enough data manipulation > > > > capabilities. > > > > > > > > > > > > > > even if we do want to deal with XSLT with multiple inputs, i > > > still > > > > > > think > > > > > > > we > > > > > > > need an XUpdate analog, since simple updates are far too > > > > heavyweight > > > > > > in > > > > > > > XSLT. > > > > > > > > > > > > > > i'm interested to know if satish thinks the ocean is getting > > > warm > > > > > ;-) > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "David RR Webber - XML ebusiness" > > > <Gnosis_@compuserve.com> > > > > > > > To: <ygoland@bea.com> > > > > > > > Cc: <wsbpel@lists.oasis-open.org> > > > > > > > Sent: Monday, August 11, 2003 6:55 PM > > > > > > > Subject: RE: [wsbpel] Issue - 11 - Ambiguous insertion > points > > > > > > > > > > > > > > > > > > > > > Yaron, > > > > > > > > > > > > > > I'm glad you are filing this issue. > > > > > > > > > > > > > > Once you cross-over into the territory of multiple inputs, > > > > > > > and merging, sorting, filtering - you get beyond XSLT and > > > > > > > into the land of traditional data mappers. > > > > > > > > > > > > > > Why are you thinking the W3C will care about this?!? > > > > > > > > > > > > > > My 0.2cents on this - take a linear approach - > > > > > > > > > > > > > > 1) Simple transactions - a la current spec'. > > > > > > > > > > > > > > 2) More complex needs - but still relatively light - XSLT > > > > > > > > > > > > > > 3) Heavy lifting - provide a call-out mechanism and let > > > > > > > people choose their own toolset. > > > > > > > > > > > > > > Implementers needing this will agree amongst themselves > > > > > > > on what to use - we certainly do not need to start > > > re-inventing > > > > > > > wheels here within BPEL - we've enough other work to > > > > > > > look at. > > > > > > > > > > > > > > Pass the baton - and move on. > > > > > > > > > > > > > > DW. > > > > > > > ================================================== > > > > > > > Message text written by INTERNET:ygoland@bea.com > > > > > > > > > > > > > > > Actually Chris nailed the missing feature for the > > > XSLT proposal, > > > > the > > > > > > > ability > > > > > > > to submit multiple inputs. Once one can specify multiple > input > > > > > > documents > > > > > > > into the transform then there is no limit to what the > > > output can > > > > > look > > > > > > > like. > > > > > > > For example XSLT(foo, bar) = bar. In other words, bar > > > is both an > > > > > input > > > > > > > and > > > > > > > an output of the transform. > > > > > > > > > > > > > > In any case I think there are two separate issues here. One > > > issue > > > > is > > > > > - > > > > > > > we > > > > > > > need support for transforms. This is true regardless > > > of any work > > > > we > > > > > do > > > > > > > with > > > > > > > XUPDATE. I will file the issue with Peter. > > > > > > > > > > > > > > The second issue is - what is the best programming model to > > > solve > > > > > the > > > > > > > insert > > > > > > > problem? Clearly something like XUPDATE is going to be a lot > > > > easier > > > > > to > > > > > > > deal > > > > > > > with than XSLT. But I'm concerned that there is no way we > can > > > > finish > > > > > a > > > > > > > fully > > > > > > > spec'd XUPDATE standard in time and it isn't even clear that > > > this > > > > is > > > > > > > something the BPEL TC should work on. XUPDATE sounds > > > like a job > > > > for > > > > > > the > > > > > > > W3C. > > > > > > > < > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > To unsubscribe, e-mail: > > > wsbpel-unsubscribe@lists.oasis-open.org > > > > > > > For additional commands, e-mail: > > > wsbpel-help@lists.oasis-open.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > To unsubscribe, e-mail: > > > wsbpel-unsubscribe@lists.oasis-open.org > > > > > > > For additional commands, e-mail: > > > wsbpel-help@lists.oasis-open.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > To unsubscribe, e-mail: > wsbpel-unsubscribe@lists.oasis-open.org > > > > > > For additional commands, e-mail: > > > wsbpel-help@lists.oasis-open.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org > > > > > For additional commands, e-mail: > wsbpel-help@lists.oasis-open.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org > > > > > For additional commands, e-mail: > wsbpel-help@lists.oasis-open.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org > > > > For additional commands, e-mail: wsbpel-help@lists.oasis-open.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org > > > For additional commands, e-mail: wsbpel-help@lists.oasis-open.org > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org > > > For additional commands, e-mail: wsbpel-help@lists.oasis-open.org > > > > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: wsbpel-help@lists.oasis-open.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: wsbpel-help@lists.oasis-open.org > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]