RE: [wsbpel] Issue - 11 Your opinion requested

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

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

Chris



-----Original Message-----
From: David RR Webber - XML ebusiness [mailto:Gnosis_@compuserve.com] 
Sent: Monday, September 01, 2003 1:09 PM
To: Ron Ten-Hove
Cc: wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Issue - 11 Your opinion requested

Ron,

Definately my thinking as well.   You asked some good questions - 
see my notes below.

Thanks, DW.

Message text written by Ron Ten-Hove
> 
David,

    +1, especially on externalising the mapping. We already attempt to 
loosely couple the process definition to the document types, via
properties.

>>> Concur

    Is the CAM ExternalMapping solution sufficiently stand-alone that we

could adopt it for use in BPEL? (I suspect not, but optimism springs 
eternal.)

>>> Interesting thoughts.  The CAM structure is modular with sections -
so
there is nothing to stop you just having the minimal set of the
Structures
section and the Mappings section.  We'd have to add this to the spec'
as a lightweight extension usage case - but technically I don't see
too many issues to doing this.  We already have the notion of Levels
to control the feature set we expect in an implementation.  And we
already
have the notion of an <import> of a sub-assembly - so infact using
CAM in this way would just be like doing an <import> into a BPEL script
of the Mapping section only - plus whatever additional pieces you felt
necessary to complete enough of the semantics to make the map of
content work.
<<<

    With an extensible mechanism, we will have to establish which 
particular mapping types MUST be supported in order to assure 
portability of definitions. It shouldn't be too difficult to come up 
with such a list; I'd suggest XSLT 1.0 and XPath 1.0 for starters. The 
list can be expanded in future versions of BPEL as things like XQuery 
and XSLT/XPath 2.0 are adopted, but not lock implementors into a 
restricted universe of options.

>>> Agreed.  We use the Level approach in CAM to document 
 what implementations need to do at each level to be conformant.

<<<

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.