OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsbpel] Issue - 11 Your opinion requested




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

likewise for my proposal.  again, it is meant to solve a different class of
problems than XSLT.

> I believe the main issue Danny had was around passing
> in multiple messages into XSLT to be merged.

not really.  it was one of my issues, but certainly not the biggest one.  my
big issue with this current proposal is, again, that XSLT is horribly
inefficient in making small changes.  additionally, the <assign> activity
requires that each of its "clauses" has the ability to be "rolled back" if
any of them fails.  trying to do that with external engines (even XPath)
seems problematic.  if you want to use external engines, that's fine, just
don't use them from within the <assign> - create a new activity type for
that.

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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]