RE: [wsbpel] Issue - 11 Your opinion requested

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

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.