RE: [wsbpel] Issue - 48 - XML Transform Support

The letter discusses the scenario that motivated this issue, why 
this scenario cannot be properly addressed in BPEL today and five proposed requirements to be met by a solution 
to this issue. 

Issue to be 
resolved

How should BPEL support XML 
transformations?

Scenario

One of the key scenarios in business 
processes is gluing together systems with complementary semantics but different 
syntaxes. For example, one can imagine a purchasing system in one part of a 
company wanting to speak with an ordering system in another part of the company. 
The problem being that the two systems use different XML schemas and have 
slightly different semantics. This is a classic job for a business process. A 
key part of the business process's job is to transform the purchasing system's 
purchase message into a form that the ordering system understands. This 
transformation is typically achieved using a XML transformation 
technology.

Technical 
Issue

BPEL's limitations in the area of 
XML manipulation are discussed to some extent in issue 11. But this issue, issue 
48, isn't so much about XML manipulation as it is about XML transformation. This 
is an area that has a rich history and wide spread support. The first 
standardized XML transformation technology was XSLT that was standardized in 
1999 but already in wide use a few years before that. XQUERY is slated to be 
standardized in the coming months, has been five years in the making and already 
has implementations from 26 different organizations. Even newer efforts such as 
OASIS's CAM are just now getting started.

            
It would clearly behoove BPEL to allow its user community to leverage the 
massive industry wide investment in these technologies. Therefore the crux of 
this issue is how to best enable BPEL to provide support for these standardized 
XML transformation technologies.

Requirements

Please note that the examples are non-normative and only 
intended to illustrate possible ways in which the requirement could be met in 
order to better clarify the meaning of a requirement.

Hosted

Requirement: BPEL MUST provide a 
standard mechanism to host XML transformation technologies directly inside of a 
BPEL program. 

 

Motivation: Transformations are 
intimately connected to the details of a particular BPEL program and the 
specific inputs it is receiving and outputs it is generating. Therefore one 
wants to be able to put the transformation definition directly inside of the 
BPEL program so as to establish as close a connection as possible.

 

Example: One could imagine either a 
new transformation activity or perhaps an extension to copy (the actual choice 
is an implementation decision and not something that appears appropriate for 
specification in a requirement) which would contain, in the case of XSLT, a 
<xsl:stylesheet> element.

Extensible

Requirement: BPEL's solution for 
hosting XML transformation technologies MUST be extensible so that it will be 
possible for the BPEL processor to discover statically what transformation 
technology is being used such that a processor can reject the specified 
technology if it does not support that particular type of 
transformation.

 

Motivation: While today there is 
only one standard XML transformation technology, XSLT, it is clear that more, 
such as XQUERY and CAM, are coming. Therefore the solution BPEL selects needs to 
be extensible so that there will be a clear means for using these newer 
technology in BPEL. It is also necessary to clearly define when these newer 
technologies are being used so the BPEL processor can detect when it has been 
asked to execute a technology it does not support.

 

Example: An attribute or other 
switch on the XML element used to host the transformation definition can specify 
what type of transformation technology is being used.

Flexible

Requirement: BPEL's solution for hosting XML transformation 
technologies MUST allow for each instance of a XML transformation specification 
to potentially use a different transformation technology.

 

Motivation: Different types of XML transformation 
technologies will be good at different things so a single global setting for the 
type of transformation technology used would be counter productive.

 

Example: The same as in the 'Extensible' requirement, each 
instance of a XML transformation definition could have its own attribute or 
element defining a switch specifying which XML transformation technology that 
instance was using.

Connected

Requirement: BPEL's solution for 
hosting XML transformation technologies MUST provide a mechanism to specify 
multiple sources of BPEL content as input to the transformation and specify the 
destination of the output. 

 

Motivation: This is mostly a house 
cleaning requirement, it means that our transformation hosting mechanism has to 
provide syntax that allows one to specify multiple sources of BPEL content such 
as properties, service types, variables, etc. as well as multiple instances of 
those sources. It also requires us to provide a way to specify where the output 
of the transform will go.

 

Example: One could imagine 
specifying multiple 'from' elements as used in Assign/Copy to identify sources 
and a 'to' element to identify the destination.

XSLT

Requirement: The BPEL specification 
MUST include a fully defined solution for hosting XSLT in BPEL.

 

Motivation: The only way to know if 
the hosting solution actually works is to use it. Since XSLT is by far the most 
common XML transformation technology available it seems the more reasonable 
candidate to require BPEL to specify support for. There is, however, no 
requirement that BPEL implementations support XSLT, only that the BPEL spec 
tells them how to do it if they want to.

 

Example: Not only would the text 
specify where to place the <xsl:stylesheet> element but it would also 
define things such as what name should be used in the document function to allow 
for selection of different data sources in the 
transform.

  
-----Original Message-----
From: ws-bpel issues list editor 
  [mailto:]
Sent: Tuesday, August 12, 2003 
  4:15 AM
To: 
Subject: [wsbpel] 
  Issue - 48 - XML Transform Support

  
This issue has been added to the wsbpel issue list. The issues list is 
  posted as a Technical Committee document to the OASIS WSBPEL TC 
  pages on a regular basis. The current edition, as a TC document, is the 
  most recent document with the title in the "Issues" folder of the WSBPEL 
  TC document list - the next posting will include this issue. The list 
  editor's working copy, which will normally include an issue when it is 
  announced, is available at this 
  constant URL. 
  Issue - 48 - XML Transform SupportStatus: open
Date 
  added: 12 Aug 2003
Submitter: Yaron Goland
Date submitted: 12 
  August 2003
Document: BPEL Spec
Description: How should 
  BPEL support XML transformations? For example, we could make it possible to 
  include a XSLT or XQUERY transform in a BPEL.
Changes: 12 Aug 2003 - 
  new issue

  

  
To comment on this issue, please follow-up to this announcement on the 
   list (replying to this message should 
  automatically send your message to that list), or ensure the subject line as 
  you send it starts "Issue - 48 - [anything]" or is a reply to such a 
  message. 
  
To add a new issue, see the issues procedures document. 
  
--------------------------------------------------------------------- To 
  unsubscribe, e-mail:  For additional 
  commands, e-mail: