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] An amendment to the proposal for issue 103


The nodeset proposal needs to address the possibility of message parts
that are not XML.  I am not saying it cannot be done, but the proposal
is not complete without that.

I disagree that this proposal treats messages as we would in WSDL 2.0
based on the current WSDL 2.0 drafts.  WSDL 2.0 represents messages as
single infosets which is what the current 103 proposal tries to do,
again without addressing non-XML parts.  What we are both proposing here
are workarounds that avoid creating a single infoset.  Therefore I would
say your model creates an alternative to the WSDL 2.0 infoset model, and
does not anticipate it.

As I wrote in response to Ugo, the only way to anticipate the WSDL 2.0
model would be to add an MTOM-like interpretation of WSDL 1.1 messages
as single WSDL 2.0-style infosets to BPEL.  This is work that the WSDL
WG ought to do as a migration guideline for WSDL 1.1 based services.  It
is not in scope for the BPEL TC in my opinion.


-----Original Message-----
From: Assaf Arkin [mailto:arkin@intalio.com] 
Sent: Friday, September 24, 2004 10:13 AM
To: Satish Thatte
Cc: wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] An amendment to the proposal for issue 103

The alternative proposal is to represent WSDL messages with parts as an 
XPath node-set. An XPath node-set is simply a collection of nodes, and 
in this proposal we let each node be an element who's unqualified name 
is identical to the WSDL message part name. We can use XPath (1.0 or 
2.0) axis to retrieve specific message parts.

For example, given a variable 'msg' that holds a WSDL 1.1 message with 
two parts 'foo' and 'bar', we would access both parts individually with 
the XPath expression:
we can access both parts collectively using other XPath axis functions. 
For example to access the entire message:
to access all 'address' elements contained in both 'foo' and 'bar' 
message parts:

The benefit of this proposal is that it treats messages as we would if 
we were to use WSDL 2.0. Since WSDL 2.0 does not use message parts, but 
represents messages as infosets, we will use a single XPath variable to 
access the entire message, and traverse its contents in the same manner.

We therefore have to start thinking and designing processes in terms of 
WSDL 2.0.


Satish Thatte wrote:

>There are two primary motivations for the excellent work Yaron and Alex
have done on issue 103.  One is the desire to clarify the usage of XPath
in BPEL including a precise definition of the environment provided for
the XPath processor within a BPEL process definition.  The other is the
idea of using the native XPath variable syntax as a binding mechanism
for XML data held by a BPEL process.  The current proposal for 103
creates a pseudo-binding for WSDL messages that allows the content of
the entire message to be viewed as a single XML infoset.  During the F2F
meeting, many concerns were expressed about the consequences of creating
such a pseudo-binding, and there were two proposals made to preserve the
bulk of the work done in the present proposal for 103 while avoiding the
pitfalls of the pseudo-binding.  I made one of the two proposals, and
this note explains the proposal and the reasons why I prefer it.
>The issue at hand is the exact nature of the binding for WSDL messages
with parts.  My proposal is simply to invent a naming convention for
message parts that allows parts to be named directly in XPath variable
bindings.  Assume for the moment that we reserve "_" as a special
delimiter that is not allowed to be used in BPEL variable names.  Assume
further that "PO" is a BPEL variable with a part named "product".  Then
we would permit the use of the form "$PO_product" in XPath to signify
the (presumably XML) content of the product part of the message stored
in the variable "PO".  This proposal is extremely simple and invents
nothing beyond what WSDL 1.1 provides as a content model for message
types.  There are other considerations in favor of this proposal that I
list below.
>The first thing to note is that at present, BPEL itself has no native
feature for processing XML, nor does BPEL have any native notion of
message content models.  All message and XML types, content models and
handling in BPEL rely exclusively on external standards such as XML
schema, WSDL 1.1 and XPath 1.0, and BPEL permits the integration of new
standards through its mechanisms for specifying query and expression
languages.  This proposal preserves the principle of keeping the BPEL
specification out of the business of defining message content models. 
>The second point to note is that WSDL allows parts to be based on type
systems other than XML, for instance arbitrary MIME content types.  It
is possible to have a part that carries a JPEG image, and it is
perfectly reasonable for a BPEL process to assign the content of such a
part from one message variable to a corresponding part in another
message variable without ever concerning itself with the content type.
We assume that the process knows its message types and will bind only
XML parts into XPath expressions.  Any proposal that attempts to create
an XML-based content model for arbitrary WSDL 1.1 messages will run into
trouble with these issues.
>It may be argued that WSDL 2.0 has moved to a pure XML infoset model
for messages, as indeed it has.  However, the WSDL 2.0 WG has not
provided a "migration story" for rendering WSDL 1.1 messages in WSDL 2.0
infoset form, apart from the fact that the BPEL TC has explicitly
declined to take a dependency on any WSDL 2.0 feature.  It hardly seems
our place to provide an XML-based content model for WSDL 1.1 messages
when the WSDL 2.0 WG has not done so.
>All these considerations lead me to believe that we should be
absolutely minimalist in binding the content of WSDL 1.1 message types
to XPath expressions, and the proposal outlined here is exactly such a
minimalist proposal.  The benefits of any proposal based on creating an
XML-based content model for all WSDL 1.1 mesages must be weighed
carefully against the cost and difficulties of specifying such a model,
and the pitfalls implied by the considerations outlined above and others
that will occur to you.
>To unsubscribe from this mailing list (and be removed from the roster
of the OASIS TC), go to

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