RE: [wsbpel] Issue - 11 - Ambiguous insertion points

["Chris Keller" <chris.keller@active-endpoints.com>]

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.

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

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.


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.

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