Re: [wsbpel] Issue 11 - Call for Discussion

[Danny van der Rijn <dannyv@tibco.com>]

david -

as i have said before, if you would like to propose a CAM binding, please do
so.

of course this was a lightweight PO structure - it was an example.  that is
NOT to say that the real world doesn't use lightweight PO structures.  or
other lightweight structures.  i'm trying to fix the deficiency wherein BPEL
needs to call out to CAM or XSLT or other engines for *simple* things that
should be able to be handled internally.

as i said in the most recent conference call, it is an interesting position
to think about removing assign altogether.  but if we're not going to do
that, our mickey mouse set of tools should at least be consistent.

danny

----- Original Message ----- 
From: "David RR Webber" <david@drrw.info>
To: "Danny van der Rijn" <dannyv@tibco.com>; <wsbpel@lists.oasis-open.org>
Cc: "Rob Bartel" <Rob.Bartel@igrafx.com>
Sent: Monday, February 23, 2004 2:41 PM
Subject: Re: [wsbpel] Issue 11 - Call for Discussion


> Danny,
>
> All I can say is that IMHO your example may work for a mickey mouse
> PO structure like yours - but for real industrial strength PO processing
> this set of 6 or 7 functions in BPEL is laughable.
>
> Go look at the OAGi PO schema for an example or even the UBL
> OP70 one - which is relatively "simple".  There's just too many
> interdependencies - and then the kicker is - what do you do
> if when the output XML is supposed to look does not exactly
> match the chunks you have in memory....?
>
> I've said all along here that the real answer is to call a proper
> transaction assembly process like OASIS CAM that has
> all the predicates and functions to handle this.
>
> You still have an issue of how you pass the external process
> the information that BPEL has garnered into memory in its
> simple chunk XML structure variables from its various
> <receive> actions.
>
> At least the six or seven functions may suffice to get you
> a raw block of XML that you can then pipe to that
> external assembly process - so it can complete the
> job for you - but that again still feels clumsy.
>
> On the other hand - if you had a neater way - say via
> the linkage section - to already group these together
> as you get them - then it would be trivial to simply
> pipe that memory collection out - to the assembly
> service for completion.
>
> CAM has the means for you to describe that
> BPEL input layout to it - and then map that
> with a bunch of rules - to the required output
> layout(s) - yes there may be more than one
> depending on who the trading partner is....
>
> I'm seeing the CAM processor being a web service
> itself - so you'd just call it via WSDL, pass the linkage
> and then the reply back would be the completed
> transaction ready for dispatch.
>
> The V1.0 RC of CAM is now available BTW
> on Kavi.
>
> DW
> Chair OASIS CAM TC.
>
> ----- Original Message ----- 
> From: "Danny van der Rijn" <dannyv@tibco.com>
> To: <wsbpel@lists.oasis-open.org>
> Cc: "Rob Bartel" <Rob.Bartel@igrafx.com>
> Sent: Monday, February 23, 2004 5:15 PM
> Subject: Re: [wsbpel] Issue 11 - Call for Discussion
>
>
> > rob -
> >
> > here's a very common example.  i have a PO.  i need to go through it
line
> by
> > line to construct a PO Response.
> >
> > Variable: PO
> > Part: PO
> > Schema:
> > <PurchaseOrder>
> >    <LineItem/>
> > </foo>
> >
> > Variable: POResponse
> > Part: POResponse
> > Schema:
> > <PurchaseOrderResponse>
> >    <LineItemResponse/>
> > </foo>
> >
> > <while "there are line items, loop over them">
> >
> >   <assign>
> >     <append>
> >       <from variable="PO" part="PO"
> > query="/PurchaseOrder/LineItem[loopIndex]" />
> >       <to variable="LineIn"/>
> >     </copy>
> >   </assign>
> >
> >   <invoke operation="ProcessOrderLine" inputVariable="LineIn"
> > outputVariable="LineOut"/>
> >
> >   <assign name="AssignResponseLine">
> >     <append>
> >       <from variable="LineOut"/>
> >       <to variable="POResponse" part="POResponse"
> > query="/PurchaseOrderResponse/LineItemResponse"/>
> >     </append>
> >   </assign>
> >
> > </while>
> >
> >
> > ----- Original Message ----- 
> > From: "Rob Bartel" <Rob.Bartel@igrafx.com>
> > To: "Danny van der Rijn" <dannyv@tibco.com>
> > Sent: Monday, February 23, 2004 12:30 PM
> > Subject: RE: [wsbpel] Issue 11 - Call for Discussion
> >
> >
> > Danny, I think it may be because my return email address is
> > rob.bartel@igrafx.com instead of (in addition to) rob.bartel@corel.com,
> > and Corel (our parent company) is the member, but I tried to post a
> > question last week and it apparently isn't going to come through.
> >
> > I still feel a bit XPATH challenged, and would appreciate an example or
> > two of use. I think I understand what's going on, but an example would
> > help cement it for me.
> >
> > Note, I mean syntax of the use rather than use case. I think you (or
> > someone) made a decent argument for *why* we'd want to do this a few
> > weeks ago.
> >
> > Please feel free to post this to the group if you feel it appropriate.
> >
> > Rob
> >
> > -----Original Message-----
> > From: Danny van der Rijn [mailto:dannyv@tibco.com]
> > Sent: Monday, February 23, 2004 10:29 AM
> > To: 'Wsbpel@Lists. Oasis-Open. Org (E-mail)'
> > Subject: [wsbpel] Issue 11 - Call for Discussion
> >
> >
> > maybe people are as tired of discussing issue 11 as I am, but if it
> > stays this quiet, I may just have to put up a proposal for vote.  Here's
> > the current proposal, which includes additions inspired by Glenn Mi.
> >
> >
> > under the <assign> element, there will be 6 possible
> > elements, where now there is only 1.
> >
> > <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
> >
> > ----- Original Message ----- 
> > From: "Danny van der Rijn" <dannyv@tibco.com>
> > To: "'Wsbpel@Lists. Oasis-Open. Org (E-mail)'"
> > <wsbpel@lists.oasis-open.org>
> > Sent: Wednesday, February 18, 2004 5:10 PM
> > Subject: Re: [wsbpel] Issue 11 - It's Baaaack
> >
> >
> > >
> > > ----- Original Message -----
> > > From: "Glenn Mi" <gmi@collaxa.com>
> > > To: "Danny van der Rijn" <dannyv@tibco.com>; "'Wsbpel@Lists.
> > Oasis-Open.
> > Org
> > > (E-mail)'" <wsbpel@lists.oasis-open.org>
> > > Sent: Wednesday, February 18, 2004 4:54 PM
> > > Subject: RE: [wsbpel] Issue 11 - It's Baaaack
> > >
> > >
> > > > Danny:
> > > >
> > > > I start to like your proposal more now. Two points I want to add:
> > > >
> > > > 1) In your <to> construct, it seems that we can just use one of
> > > >
> > > > <to variable="ncname" property="qname"/> and
> > > > <to variable="ncname" part="ncname"? query="queryString"?/>
> > > >
> > > > Or does your select="XPath Expression evaluates to one node"
> > > > actually mean the normal to-spec construct ?
> > >
> > > yes.  the normal to-spec, but restricted to variables, and their
> > > parts. i.e. not partnerlinks, etc.  in the spec, this is the "first"
> > > form of the to-spec referred to in 9.3, and extended for executable
> > > processes in 14.3
> > >
> > > >
> > > > 2) And there are cases to insert and remove part of a message
> > > > variable (varable defined as <variable name="abc"
> > > > messageType="ns:xyz"/>). In
> > those
> > > > cases you don't need query string and you don't care about the
> > > > order. So it make sense to have something like:
> > > >
> > > > <insert>
> > > > <from .../>
> > > > <to variable="abc" part="def"/>
> > > > </insert>
> > >
> > > unless i'm mistaken, <copy> can be used here.
> > >
> > > >
> > > > and
> > > >
> > > > <remove variable="abc" part="def"/>.
> > >
> > > you are correct.  this should be added.  i believe that this is the
> > > only
> > one
> > > of the new 4, though, that should have "select" be optional.
> > >
> > >
> > > >
> > > >
> > > > Glenn
> > > >
> > > > -----Original Message-----
> > > > From: Danny van der Rijn [mailto:dannyv@tibco.com]
> > > > Sent: Wednesday, February 18, 2004 3:19 PM
> > > > To: 'Wsbpel@Lists. Oasis-Open. Org (E-mail)'
> > > > Subject: Re: [wsbpel] Issue 11 - It's Baaaack
> > > >
> > > >
> > > > to preempt the pedantic among us, there's a copy/paste error in the
> > > > proposal.  it should read: "under the <assign> element, there will
> > > > be 5 possible elements, where
> > now
> > > > there is only 1."
> > > >
> > > > ----- Original Message -----
> > > > From: "Danny van der Rijn" <dannyv@tibco.com>
> > > > To: "'Wsbpel@Lists. Oasis-Open. Org (E-mail)'"
> > > <wsbpel@lists.oasis-open.org>
> > > > Sent: Wednesday, February 18, 2004 3:16 PM
> > > > Subject: [wsbpel] Issue 11 - It's Baaaack
> > > >
> > > >
> > > > > during today's conference call, we took a straw poll, where
> > > approximately
> > > > > 2/3 voted to attempt to resolve issue 11.  (i'll leave the exact
> > > > > count
> > > to
> > > > > the minutes).  i would like to resurrect a large part of my
> > > > > previous proposal (i'll drop "rename").  to me, this is a viable
> > > > > proposal, and
> > i
> > > > > would be satisifed if it ended up being adopted into the spec.
> > however,
> > > > > maybe in the months since we last thought about it, someone else
> > > > > has a reasonable alternative.
> > > > >
> > > > > danny
> > > > >
> > > > > My proposal:  under the <assign> element, there will be 6 possible
> >
> > > > > elements, where now there is only 1.
> > > > >
> > > > > <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
> > > > >
> > > > >
> > > > > To unsubscribe from this mailing list (and be removed from the
> > > > > roster
> > of
> > > > the OASIS TC), go to
> > > >
> > >
> > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgr
> > oup.
> > > > php.
> > > > >
> > > >
> > > >
> > > > To unsubscribe from this mailing list (and be removed from the
> > > > roster of
> > > the
> > > > OASIS TC), go to
> > > >
> > >
> > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgr
> > oup.
> > > > php.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > To unsubscribe from this mailing list (and be removed from the
> > > > roster of
> > > the OASIS TC), go to
> > >
> > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgr
> > oup.php.
> > > >
> > >
> > >
> > > To unsubscribe from this mailing list (and be removed from the roster
> > > of
> > the OASIS TC), go to
> > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgr
> > oup.php.
> > >
> >
> >
> > To unsubscribe from this mailing list (and be removed from the roster of
> > the OASIS TC), go to
> > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgr
> > oup.php.
> >
> >
> > To unsubscribe from this mailing list (and be removed from the roster of
> the OASIS TC), go to
>
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php.
> >
> >
>