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


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?  
2. What does it mean to be valid? (schema association?)
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?

++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]