[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]