Re: [wsbpel] Issue 103 - draft proposal

["Yaron Y. Goland" <ygoland@bea.com>]

I want to thank Alex and the folks at Oracle for taking the time to 
think this through and especially for coming up with the simplified 
proposal. It really helped me out. This is a complex issue that is going 
to take a few rounds to get right but I think it's worth the effort. The 
benefits of the $ syntax are high in my opinion. Below I address a 
specific issue I found with the current proposal and suggest how it 
might be dealt with.

		Yaron

EXECUTIVE SUMMARY

Alex's proposal for how to translate WSDL messages to XML Schema has a 
small problem - naming collisions. The namespace for WSDL messages and 
Parts is not separate from the namespace for defining XML Schema element 
names. To deal with this problem I propose two changes to Alex's proposal:

1) Enable BPEL variables to be defined using both simpleTypes and 
complexTypes (I have been meaning to propose this anyway). Then require 
that XML schemas auto-generated from WSDL messages be anonymous so that 
the value of a WSDL message variable is the list of part elements. Since 
WSDL message names are no longer used in the translation it doesn't 
matter if the WSDL message name collides with a XML component definition.

2) Introduce the bpel:partName attribute for use on the part element in 
WSDL message definitions whose qname collides with another XML element's 
qname. The value of bpel:partName will provide the qname to be used 
within BPEL for referring to the part. I also propose introducing the 
bpel:originalName attribute for use on the part elements in the XML 
serialization of the message content presented within BPEL so as to make 
the original name available.

Finally, I have an appendix explaining why the proposal to get rid of 
part names won't work due to limitations in XML schema.

EXAMPLE

definition xmlns:a="http://example.com";
    message name="Order"
       part name="Details" *bpel:partName="a:UniqueName"*
            element="a:Details"
       part name="MoreDetails" element="a:Details"

    types
       xsd:schema targetNamespace="http://example.com";
          element name="Details"
             ...

Variables
    variable name="Whatever" messageType="a:Order"

Then the 'virtual' XSD that would represent the variable would be:

xsd:schema targetNamespace="http://example.com";
    complexType
       sequence
          element name="UniqueName" *bpel:originalName="a:Details"*
             complexType
                sequence
                   element ref="a:Details"
          element name="MoreDetails" *bpel:originalName="a:MoreDetails"*
             complexType
                sequence
                   element ref="a:Details"

Note that bpel:partName is only used on the part named "Details" since 
that is the only part that has a name collision. bpel:originalName is 
made available on every part inside of BPEL, even when it is redundant, 
to make queries easier.

LONG WINDED VERSION

    THE PROBLEM

In WSDL, as I understand it, there is no requirement that the qnames for 
XML elements, message types and parts be unique from each other. That 
is, one could legally give a XML element, message type and part the 
exact same qname.

In the current proposal for issue 103 WSDL message type and part qnames 
would be turned into XML element qnames. But if there already exists an 
XML element with the qname used for the message type or part then a 
collision will occur. Such a collision will result in an illegal schema 
definition.

    WHY WE SHOULD CARE

The simple solution to this problem is - rename the offending message 
type, part or element. But in many cases BPEL processes will be 
implementing WSDLs given to them by 3rd parties and the BPEL will need 
to advertise the WSDL it implemented. If it changes a name of a message 
type, part or element then it will cause problems with working with 
others who are expecting the original WSDL definition. Also, names tend 
to leak. They can show up in things like policy statements and RPC 
processing. So, in general, it's not possible to change a name without 
breaking interoperability.

An equally simple solution is to just ignore the problem. But in our 
experience it is common for users to re-use the same name in every 
possible place they legally can. So abandoning all those WSDLs isn't 
workable solution. Besides, in general the onus should be on us to fully 
support WSDL whenever possible and reasonable. WSDL's naming rules are 
of long standing so we need to support them.

    INTRODUCING COMPLEXTYPES & REMOVING MESSAGE TYPES

In the current 103 proposal the root element of the virtual XML schema 
definition is the message type's name. This actually introduces a fairly 
nasty problem since any XPATH based on the content must include the root 
element's name in order to get direct access to the children. For 
example, let's imagine I have a message type called a:MT with one part 
called a:Part with one element called a:Element. Now imagine I have a 
BPEL variable called BV of type a:MT. In that case the XPATH to get to 
the element should be $BV/a:MT/a:Part/a:Element. But in the current 103 
proposal the XPATH that would be specified is 
$variable/a:Part/a:Element. The message type element, which is the root 
of the message value, has disappeared. In other words, to the best of my 
understanding, the proposal for the schema definition of a WSDL message 
type in the 103 proposal is not consistent with the proposed XPATH $ 
syntax.

We could, of course, specify a special XPATH behavior for messageType 
variables and use the standard XPATH behavior for other variables but I 
think an inconsistency on that scale is hostile to programmers 
understanding the spec.

Therefore I propose that we change BPEL to allow for an additional way 
to define a BPEL variable, using a complexType.

With this changed we can define the virtual XML schema definition of 
WSDL message types as anonymous complexTypes whose children are WSDL 
message part elements per the current 103 proposal with additional 
modifications discussed in the next section. Scroll up to the example to 
see what I mean.

    HANDLING PART NAME COLLISIONS

I propose we introduce a new attribute called bpel:partName. This 
attribute MUST be used on a message definition that contains a part that 
contains elements, either directly or indirectly via a type, which 
collide with the part qname. The value of the bpel:partName attribute 
would be a new qname that is unique in both the WSDL Part namespace and 
the XML Schema Element namespace and would be used to provide an 
alternate name for the part in the context of BPEL.

We would then introduce a second attribute, bpel:originalName that would 
be used on the XML realizations of WSDL messages. bpel:originalName 
provides the original name of the part. In order to simplify queries it 
would make sense to always require that the bpel:originalName appears. 
In cases where bpel:partName wasn't used the value of bpel:originalName 
will match the element's name.

Please see the example at the start of the article to see how this would 
work.

The bpel:originalName attribute SHOULD be removed before handing a BPEL 
WSDL message type variable to the WSDL processing layer.

If, after processing the bpel:partName attribute, there is still a 
namespace collision between XML Element qnames then the BPEL process 
definition MUST be rejected as invalid.

APPENDIX - WHY WE CAN'T GET RID OF PART NAMES

It is tempting to simplify things even further by getting rid of part 
names. Combined with the proposal to get rid of message type names this 
would avoid all namespace collisions. But getting rid of part names 
brings up its own problems. For example:

definition xmlns:a="http://example.com";
    message name="Order"
       part name="P1" type="a:choice"
       part name="P2" type="a:choice"

    types
       xsd:schema targetNamespace="http://example.com";
          complexType name="choice"
             sequence
                element name="bar" type="int"
                any

Variables
    variable name="Whatever" messageType="a:Order"

If we got rid of part names then the XML representation of the WSDL 
message type in BPEL would be:

element name="Whatever"
    complexType
       sequence
          element name="bar" type="int"
          any
          element name="bar" type="int"
          any

This schema is illegal under XML Schema because it is ambiguous.

Alex Yiu wrote:

> 
> Hi Yaron and all others,
> 
> Here is the simpified version. 
> I trimmed all the open options and some descriptive text. I cut off 25% 
> of content.
> I hope that is easier for people to follow the proposal now.
> 
> But, you guys got questions in the simplified version. You may be able 
> to find the answers and justification of the proposal in the original 
> version.
> 
> Thanks!
> 
> 
> 
> Regards,
> Alex Yiu
> 
> 
> Yaron Y. Goland wrote:
> 
>> I long ago accepted that I'm not smarter than your average bear so 
>> perhaps I'm the only one who finds it impossible to read the proposal 
>> because of all the interlocking options. When I got to the point where 
>> I felt the need to draw a graph to try and understand the relationship 
>> between the various options I knew it was time to stop.
>>
>> May I humbly request that you repost your proposal without any options 
>> what so ever? Just specify how you think this should all work and 
>> leave out the choices. If you want to have a separate section at the 
>> end that explores different options and why you didn't pursue them 
>> that would be great but it isn't necessary.
>>
>> Since you are doing the work you get to suggest how things should 
>> work. If people don't like what you propose then let them suggest 
>> options and do the work to flesh those options out. But having a 
>> document that seems to be arguing with itself is just too confusing 
>> for me.
>>
>> I think there are really important and very cool ideas in the proposal 
>> but the proposal itself needs to be simplified in order to let me, at 
>> least, get to them.
>>
>>     Thanks,
>>
>>         Yaron
>>
>> Alex Yiu wrote:
>>
>>>
>>>
>>> Hi all,
>>>
>>> As promised in the conf call last week, here is the draft proposal for
>>> Issue 103.
>>>
>>> Please note that is a draft version of the proposal, NOT the final
>>> version that will be used for voting yet. Especially, there are some
>>> options listed in the proposal for item (1B) and (2C) and (3B) (with
>>> some preferences expressed).
>>>
>>> Please voice your opinions so that we know that we are solving Issue 103
>>> in a right way.
>>>
>>> Thanks!
>>>
>>>
>>>
>>> Regards,
>>> Alex Yiu
>>>
> 
> 
> ------------------------------------------------------------------------
> 
> 
>     Issue 103 Proposed Resolution
> 
> Subject: Standardizing $varName syntax for XPath to refer to a BPEL 
> variable
> 
> Draft Version #5
>     [V5: Summarized version with options chopped out at the request of 
> Yaron]
>     [V4: Kevin Liu has kindly reviewed WSDL part of the proposal. 
> Factoring in some feedback from Kevin into V4.]
> 
> May 04, 2004  - 4pm PDT
> 
> 
>     Goals:
> 
> To simplify the XPath syntax to access BPEL variable, including both 
> simple type, schema element of complex type, and WSDL Message type.
> 
> This proposed resolution consists of:
> (1) Adding $var syntax and simplifying from-spec and to-spec
> (2) Representing WSDL Message Types as if XML-Schema Element
> (3) Removing bpws:getVariableData() and etc
> (4) Terminology change in variable declaration
> 
> 
>       (1) Adding $var syntax and simplifying from-spec and to-spec
> 
> The value of a BPEL variable, which appears as Variable-Reference in 
> XPath 1.0, corresponds to a node-set of exactly one XML node in XPath 
> 1.0 semantics. The XML node corresponds to the element node (not 
> document node) of related BPEL variable, when the variable is declared 
> with  "element"  attribute or  "messageElement" attribute. 
> ["messageElement" is an attribute renamed from "messageType" in part (4) 
> below.]
> 
> After introducing $var syntax, we can simplify assign by eliminating 
> some variation of from-spec and to-spec.
> 
> (1A)
> <from variable="ncname" part="ncname"? />
>     will be eliminated and merged into:
>          <from>
>         <expression>general-expr</expression>
>      </from>
>           [Here we use the post-Issue-13 syntax.]
> 
> (1B) About from-spec: <from variable="ncname" property="qname"/>
> from-spec: <from variable="ncname" property="qname"/> remains unchanged
> 
> For example:
>     [EX-1]
>     <from variable="myVar" />
>         => <from> <expression>$myVar</expression </from>
>     [EX-2]
>     <from variable="myWSDLMsg" part="part1" /> 
>         => <from> <expression>$myWSDLMsg/part1</expression> </from>
> 
> For executable BPEL,
>     [EX-3]
>     <from variable="myVar" query="/some:elem/some:more_xpath" />
>         => <from> <expression>$myVar/some:more_xpath</expression> </from>
> [*** NOTE: the "some:elem" NameTest part of XPath is dropped, because 
> $myVar of "some:elem" type is now pointing to an element, instead of a 
> document. The XPath is now relative to the element, instead of the 
> document. ***]
> 
>     [EX-4]
>     <from variable="myWSDLMsg" part="part1" query="/some_query_path" />
>         =>
>         <from>
>             <expression>$myWSDLMsg/part1/some_query_path</expression>   
>         </from>
> 
> 
> (1C)
> to-spec: <to variable="ncname" part="ncname"? /> : the part attributed 
> will be dropped:
> 
> For core part of BPEL spec:
> <to variable="ncname" />
> 
> For executable part of BPEL spec:
> <to variable="ncname">
>     <query>some_query_path</query>
> </to>
> [Again, using post-issue-13 syntax here]
> 
> [EX-5]
> <to variable="myWSDLVar" part="part01" />
> will becomes:
> <to variable="myWSDLVar">
>     <query>/part01</query>
> </to>
> 
> The part semantics is moved into and encapsulated in the query path 
> (e.g. XPath).
> 
> (1D)
> to-spec: <to variable="ncname" property="qname" />
> will be kept unchanged.
> 
> (1E)
> That implies that we would still have two sub-language used in BPEL: one 
> is query language; one is expression language.  [For example, expression 
> language may be XQuery, while query may be XPath.]
> 
> All other from-specs and to-specs remain unchanged (including <from 
> opaque="true" /> for abstract BPEL).
> 
> 
>       (2) Representing WSDL Message Types into XML-Schema Element
> 
> We suggest to use $var syntax to represent WSDL message variables in 
> XPath and etc. In order to achieve that, we need to apply a logical 
> mapping to WSDL 1.1 message types to emulate XML Schema Elements. Given 
> a WSDL 1.1 message type, there will be a XML Schema Element definition 
> mapped out.
> 
> This can potentially help migration of BPEL programs from WSDL 1.1 to 
> WSDL 2.0 (e.g. a straight forward global search-and-replace may do). 
> However, a completely effortless migration is a NON-GOAL, since WSDL 2.0 
> specification is still in progress and its related WS-I activities have 
> not been bootstrapped yet.
> 
> The definition serves as a logical structure for XML-based language 
> (e.g. XPath) to access different parts of WSDL 1.1 message. The physical 
> message format can vary a lot depending on the related bindings, styles, 
> deployment options, and platforms of the web services. The logical 
> message is only for the purpose of accessibility via XPath, and actually 
> it will never match the wired message format.
> 
> The mapping will be done by BPEL engine (static analysis and runtime) 
> automatically.  The mapping and XPath usage for existing BPEL users is 
> actually very obvious. Before going into details of mappings, here are 
> some more examples of from-spec and to-spec:  (additional to [EX-2] and 
> [EX-4] above)
> 
> <from variable="myMsg" part="part01" query="/some_x_path" />
> is changed into:
> <from expression="$myMsg/part01/some_x_path" />
> 
> <to variable="myMsg" part="part01" query="/some_x_path" />
> is changed into:
> <to variable="myMsg" query=/part01/some_x_path" />
>  
> Please note: the current spec is quite silent on how the "/some_x_path" 
> should look like regarding to differences between wsdl:part@type and 
> wsdl:part@element. After passing Issue 103, what the "/some_x_path" 
> should look like will be much more clear.
> 
> 
> Rules to do the mapping WSDL 1.1 type to XML Schema Element:
> 
> (The XSLT stylesheet fragments are intended for ILLUSTRATION ONLY on how 
> to map a WSDL 1.1 message type to an XML Schema Element in the usage 
> context of BPEL4WS 1.1. They are NEVER intended to be any normative part 
> of the BPEL4WS spec or other specifications or a part of programming 
> components.)
> 
> Reference:
> WSDL 1.1 XML Schema: http://schemas.xmlsoap.org/wsdl/2003-02-11.xsd  
> 
>        
> (2A) A "wsdl:message" element is mapped to "xsd:element" element which 
> shares the same "name" attribute value. The "xsd:element" is defined 
> based on an anonymous complex type of which contains a sequence. The 
> content of sequence will be mapped from "wsdl:part" to a series of 
> "xsd:element" based on the rules (2B) and (2C) below.
> 
>     <xsl:template match="wsdl:message">
>         <xsd:element name="{@name}" >
>             <xsd:complexType>
>                 <xsd:sequence>
>                     <xsl:apply-templates/>
>                 </xsd:sequence>
>             </xsd:complexType>
>         </xsd:element>
>     </xsl:template>
> 
> (2B) A "wsdl:part" element which has an "type" attribute is mapped to 
> "xsd:element", which shares the same "name" and "type" attribute values. 
> The "xsd:element" has both minOccurs and maxOccus set to 1.
> 
>     <xsl:template match="wsdl:part[@type]">
>         <xsd:element name="{@name}" type="{@type}" minOccurs="1"
>             maxOccurs="1" />
>     </xsl:template>
> 
> 
> (2C) A "wsdl:part" element which has an "element" attribute is mapped to 
> an "xsd:element" which share the same "name" attribute value with 
> "wsdl:part". The "xsd:element" is based on an anonymous complex type, 
> which has a sequence of one "xsd:element. The "xsd:element" has a "ref" 
> attribute referring to the element in "wsdl:part" and has minOccurs=1 
> and maxOccurs=1.
> 
>     <xsl:template match="wsdl:part[@element]">
>         <xsd:element name="{@name}">
>             <xsd:complexType>
>                 <xsd:sequence>
>                     <xsd:element ref="{@element}" minOccurs="1"
>                         maxOccurs="1" />
>                 </xsd:sequence>
>             </xsd:complexType>
>         </xsd:element>
>     </xsl:template>
> 
> 
> [EX-6] 
> For a variable declared similar to the following:
> <variable name="myVar" messageElement="myWSDL:POMsgType" />
> 
> The XPath for a part (no matter it is declared with type or element 
> attribute) would be: "$myVar/partName"
> 
> Again, the QNAME of "myWSDL:POMsgType" does not present in the XPath, 
> because the variable is refering to the element node, instead of 
> document node.
> 
> [EX-7]
> For example, for the following WSDL 1.1 message definition:
> <message name="GetLastTradePriceInput">
>         <part name="body" element="foo:TradePriceRequest"/>
> </message>
> 
> will be mapped to the following XML Schema Element:
> 
> <xsd:element xmlns:xsd="http://www.w3.org/2001/XMLSchema"; 
>     name="GetLastTradePriceInput">
>     <xsd:complexType>
>         <xsd:sequence>
>             <xsd:element name="body">
>                 <xsd:complexType>
>                     <xsd:sequence>
>                         <xsd:element ref="foo:TradePriceRequest" 
> minOccurs="0" maxOccurs="1"/>
>                     </xsd:sequence>
>                 </xsd:complexType>
>             </xsd:element>
>         </xsd:sequence>
>     </xsd:complexType>
> </xsd:element>
> 
> 
>       (3) Removing some bpws:getVariableData() and etc
> 
> (3A) About bpws:getVariableData():
> After adding $var syntax and providing XML-Schema-Element emulation over 
> WSDL message variables, we do not need bpws:getVariableData() function 
> any more.
> 
> (3B) About bpws:getVariableProperty()
> We suggest to keep 
> bpws:getVariableProperty('variable_name','property_name') unchanged.
> 
> (3C) About bpws:getLinkStatus('a_LinkName')
> As we cannot be sure that restrictions in section 12.5.1 and 9.1 hold 
> true in future, then we suggest to keep bpws:getLinkStatus(...). Because 
> this is just a pure syntax shortcut without much semantic advantages.
> 
> 
>       (4) Terminology change in variable declaration
> 
> Currently, there are 3 attributes related to type declaration in 
> <variable> element: "messageType", "type" and "element".
> 
> We suggest to have a minor change: from "messageType" to 
> "messageElement". The new attribute match better with semantics of 
> emulating / representing WSDL 1.1 message type as XML Schema Element.
> 
> 
> 
>       END
> 
> 
> 
> 
>