RE: [wsbpel] Issue 103 - draft proposal

wsbpel message

Subject: RE: [wsbpel] Issue 103 - draft proposal

From: "Ugo Corda" <UCorda@SeeBeyond.com>

To: "Alex Yiu" <alex.yiu@oracle.com>

Date: Fri, 7 May 2004 10:02:05 -0700

Title: Message

Hi Alex,

Yes, I now see that my proposed change is identical to your original option-I (which I had not read yet).

Let me give you some points that I consider negative when choosing option-II.

- The "element" mapping has a double level element (the part-named element plus the nested element-named element), while the "type" mapping has only one level element (the part-named element - I am not talking about any nested elements coming from the type definition itself, of course).

- Option-II is not consistent with what appears on the wire in the case of a SOAP binding. (Before people start jumping on me saying that SOAP binding is not part of the BPEL language, let me say that I know that very well, but at the same time I think it is important to take into account what happens in the SOAP binding - being it the current most important binding when it comes to actual implementations - and to make sure that BPEL's direction does not seem at odd with the current SOAP binding direction).

Let me elaborate on this point. The SOAP binding of WSDL 1.1 (after WS-I BP 1.0 clarifications) can have two different mappings to WSDL parts, depending on the style:

1) For rpc style (the part has to have a "type" attribute), the element under the operation name element on the wire has the name of the type (see BP 1.0, sec. 5.6.21, the SOAP message in the example). This is consistent with your mapping (2B).

2) For document style (the part has to have an "element" attribute), there is only one element directly under the SOAP body on the wire and it has the name of the "element" attribute of the part (see WS-I BP 1.0, sec. 5.6.9). In other words, no double level element with one element for the part and one nested element for the "element" attribute. This is consistent with mapping (2C), option-I, but inconsistent with (2C), option-II.

For what concerns the case of two parts with same "element" attribute value, that does not happen in the case of SOAP binding with document style, since the message can only have one part. We don't know, of course, about other bindings, but I would not be surprised if they followed the same rule, since it makes sense to be talking about a single document being sent over the wire.

Ugo

-----Original Message-----
From: Alex Yiu [mailto:alex.yiu@oracle.com]
Sent: Friday, May 07, 2004 12:52 AM
To: Ugo Corda
Cc: wsbpeltc; Alex Yiu
Subject: Re: [wsbpel] Issue 103 - draft proposal

Hi Ugo,

First of all, thank you very much for reading the proposal draft in details.

I guess I did consider the mapping identical / similar to your suggestion during our internal brainstorming. If you look at the original longer version of proposal (before the simplified version), I have two options listed in (2C).
I think what you are suggesting is option-I, while I prefer option-II.

The reasons that I prefer option-II are:

Since the XPath to access a message part will always have a part name (e.g. $msgVar/partName/... ), the Xpath will be more intuitive:

having an easy no-brainer mapping from <from variable="msgVar" part="partName" /> to XPath

having a consistent XPath for both wsdl:part[@type] and wsdl:part[@element]: if we chose option-I, wsdl:part[@type] will have its partName in XPath, while the Xpath for wsdl:part[@element] does not.

Consider Danny's example in previoue email, two parts of same element QName, if we chose option-I, we need to use position-based to distinguish different parts (e.g. $msgVar/bar[1]). partName cannot be a part of XPath anymore.

I hope I have convinced you option-II is better.

Regarding to Issue 43, looking back into your resolution:
(I think you did a great job of catching those mistakes in the spec)

<message name="taxpayerInfo"> <part name="identification" element="txtype:socialsecnumber"/> </message> <bpws:propertyAlias propertyName="tns:taxpayerNumber" messageType="tns:taxpayerInfo" part="identification" query="/txtype:socialsecnumber"/>
<bpws:propertyAlias propertyName="tns:shipOrderID" 
        messageType="sns:shippingNoticeMsg" 
        part="shipNotice" 
        query="/shipNotice/ShipNoticeHeader/shipOrderID"/> 
[bold part is your correction]

After passing Issue 103, the part semantics will be assimilated into query string. The same examples will become:

<bpws:propertyAlias propertyName="tns:taxpayerNumber" messageElement="tns:taxpayerInfo" query="/identification/txtype:socialsecnumber"/>
The "identification" part is merged to query string.
<bpws:propertyAlias propertyName="tns:shipOrderID" 
        messageElement="sns:shippingNoticeMsg" 
        query="/shipNotice/ShipNoticeHeader/shipOrderID"/> 
The "shipNotice" part is merged to the query string.

So, it is sync with what you want ... I guess. :-)
Agree? :-)

Regards,
Alex Yiu

P.S.:
---------------
(2C)(option-I) A "wsdl:part" element which has an "element" attribute is mapped to an "xsd:element" which has a "ref" attribute referring to the element in "wsdl:part". The "xsd:element" has minOccurs=1 and maxOccurs="1".

    <xsl:template match="wsdl:part[@element]">
        <xsd:element ref="{@element}" minOccurs="1" maxOccurs="1" />
    </xsl:template>

(2C)(option-II) 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>
---------------

Ugo Corda wrote:

I would also rewrite [EX-7] as:

<xsd:element xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    name="GetLastTradePriceInput">
    <xsd:complexType>
        <xsd:sequence>
            <xsd:element ref="foo:TradePriceRequest" minOccurs="0" maxOccurs="1"/>
        </xsd:sequence>
    </xsd:complexType>
</xsd:element>

-----Original Message-----
From: Ugo Corda
Sent: Thursday, May 06, 2004 7:42 PM
To: Alex Yiu
Cc: wsbpeltc
Subject: RE: [wsbpel] Issue 103 - draft proposal

Hi Alex,

If I understand your section 2 correctly, I think that your proposed mapping (2C) is inconsistent with our previous Issue 39 resolution, in the sense that the element constructed from a part with an "element" attribute should take its name from the value of the "element" attribute and not from the part name.

Ugo