OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsbpel] Issue - 11 - Ambiguous insertion points


not to discourage a bit of active involvement, but i'd really like to wrap
this conversation before we delve into the other issues.  i truly believe
that they are other issues to be dealt with separately.  i apologize, of
course, for ignoring my own desire.  that being said, my comments are inline
with <DV>

----- Original Message ----- 
From: "Harvey Reed" <hreed@sonicsoftware.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:29 PM
Subject: RE: [wsbpel] Issue - 11 - Ambiguous insertion points


> Ok, I'll chime in again :-)
>
> In addition to the syntax being discussed below, what do we say about the
> state of the node when the 'copy' is complete?
>
> 1. Is it valid when copy is done? Yes, no , maybe?

<DV> my current thinking is that the *smallest* validation boundary is the
<assign> operation itself, and not any individual <copy> </DV>

> 2. What does it mean to be valid? (schema association?)

<DV> validates without error against the schema which defines it </DV>

> 2. Do we say anything about 'copy' relative to operational semantics of
> durability? That is, if a process takes a while, and if state is durable,
> can we always assume it is ok to persist after a 'copy'? and if so what
> about #1,2 above?
>

<DV> i don't think anything is currently said on this topic </DV>

> ++Harvey
>
>
>
> -----Original Message-----
> From: Chris Keller [mailto:chris.keller@active-endpoints.com]
> Sent: Wednesday, August 13, 2003 5: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]