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

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.



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