[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue - 11 Your opinion requested
That is possible. I have also solved that problem in products through registering global variables ($xxx). However the current specification doesn't state what a message context should look like to an XPath processor. Instead the current specification states what a bpws:getVariableData context would look like to the XPath processor. That is why I was leaning toward using the bpws:getVariableData function even within XSLT. If we can state what the $message context is (probably some sort of nodeset where the nodes are the individual parts) then we can use it instead. If we did this then I think we could drop the bpws:getVariableData function altogether and use the $ notation even within bpel expressions. -----Original Message----- From: Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM] Sent: Tuesday, September 02, 2003 6:00 PM To: chris.keller@active-endpoints.com Cc: wsbpel@lists.oasis-open.org Subject: Re: [wsbpel] Issue - 11 Your opinion requested Chris Keller wrote: >I agree that we may be trying to bite off too much with the proposed >additions to BPEL. My idea for the new XPath functions was more of a >stopgap to allow 80% of what people needed directly within BPEL without >adding too much to the specification. > >The thoughts on externalizing are good. We already had some discussion >of this idea, primarily around using XSLT to perform the >transformations. I believe the main issue Danny had was around passing >in multiple messages into XSLT to be merged. However we could require >access to the bpws:getVariableData functions within the BPEL/XSLT >environment to allow mapping from multiple inputs. > I've had to solve that type of problem in a product. We needed to pass internal state data (of mixed types, rather like BPEL variables) to the XSLT engine. The solution was to pass them in as XSLT global variables, using a suitable naming convention of course. >Does CAM allow >multiple inputs for Mapping? > >Here are some syntax suggestions from previous threads. > >A proposed syntax where transform was added as an optional element under >the assign/copy operation: ><assign> > <copy> > <from> <!-- As specified for assign --> > <to> <!-- As specified for assign --> > <transform xform="bpel:xslt"> > (<import href=""> | <xsl:stylesheet ...> | >xsl:transform...>) > </transform> > </copy> ></assign> > >Or in addition to copy an assign/transform operation: > ><transform xform="bpel:xslt"> > <from> <!-- As specified for assign --> > <to> <!-- As specified for assign --> > <xslt> > (<import href=""> | <xsl:stylesheet ...> | ><xsl:transform >...>) > </xslt> ></transform> > >In either proposals the xform attribute would be used to specify the >engine used to perform the transform. So theoretically we could have >xform="bpel:cam" or xform="bpel:XQuery". > or a "custom" (non-standard / extension) type of transform, from a non-bpel namespace. > >Chris > > > 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]