Re: [wsbpel] Issue 103 - draft proposal

[Alex Yiu <alex.yiu@oracle.com>]

Yaron,

Thank you for reading the proposal in details.
I totally agree with you that it will still take a number of emails to 
get all details of this proposal flushed out right. :-)

Summary:
---------------------------------
Regarding to QNAME collision, that issue has been at the back of my mind 
for a while. I have been putting it in a lower priority in my thinking 
process. I also want to solve the collision issue.

I agree with mostly with your point "/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 .../"

For your point "/2) Introduce the bpel:partName attribute .../" ... I am 
not sure that is necessary.
---------------------------------


Detailed reply to your feedback (which is very constructive):

(I)
"/1) Enable BPEL variables to be defined using both simpleTypes and
complexTypes (I have been meaning to propose this anyway)./"

If my analysis (below) is right, we can solve the QNAME collision 
problem without formal introducing ComplexType into variable 
declaration. We may no need to introduce complexType to solve this 
issue. Let's handle complexType issue separately. (I am still open to 
that idea in general.)

(II)
Also under "1)", "/Then require that XML schemas auto-generated from 
WSDL messages be anonymous .../"

I think I like this idea. We can avoid QNAME collision by generating 
anonymous QNAME for XML Schema Element corresponding to a WSDL Message 
Type.

Given that adopting this mechanism, I would remove item (4) in my 
proposal ("messageType" => "messageElement"). Keeping messageType 
attribute would be fine.

<variable name="fooMsg" messageType="mywsdl:myFooMsgType" />

By using messageType attributes, the BPEL translator knows it will 
generate an anonymous QNAME of an XML Schema Element for 
"mywsdl:myFooMsgType".

(III)
"/2) Introduce the bpel:partName attribute .../"

I guess there is no collision for part name in general. Because, for a 
message part, we are generating a local element declaration and 
definition. The part name does not constitute a QNAME. The part name is 
a non-qualified local element declaration. Using your example, "Details" 
and "MoreDetails" are not qualified elements.  (Just like "product" 
element can have a "name" subelement which is a string of maxLength = 
50, while "customer" element can have a "name" subelement which is a 
string of maxLength = 40.)

(IV) XPath Semantic Clarification:

If you look back to my proposal in item (1):
"/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 .../"

There is a big difference between element node or document node in terms 
of how XPath look like.

If we go for a document node, your XPath will be right:
"$BV/a:MT/a:Part/a:Element"

If we go for an element node, the XPath in the proposal will be right:
"$BV/a:Part/a:Element"

Here is a little experiment that I run on XMLSpy to illustrate this:

emp_test.xslt
----------------------------------
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" 
xmlns:xsl="http://www.w3.org/1999/XSL/Transform";>
    <xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes"/>
    <xsl:template match="/employeeTag">
        <xsl:variable name="empVar" select="." />
        <test>
            <test1><xsl:value-of select="$empVar/@id" /></test1>
            <test2><xsl:value-of select="$empVar/fname" /></test2>
            <test3><xsl:value-of select="name($empVar)" /></test3>
        </test>
    </xsl:template>
</xsl:stylesheet>
----------------------------------

emp.xml
----------------------------------
<?xml version="1.0" encoding="UTF-8"?>
<employeeTag id="101">
    <fname>John</fname>
    <lname>Dole</lname>
</employeeTag>
----------------------------------

Execution Result:
----------------------------------
<?xml version="1.0" encoding="UTF-8"?>
<test>
    <test1>101</test1>
    <test2>John</test2>
    <test3>employeeTag</test3>
</test>
----------------------------------

If my proposal got accepted, we need to change Section 14.3 accordingly 
a little bit in the spec.

(V)
 From reading your appendix, I am glad that you also think getting rid 
of part names is a good idea.
We are more or less on the same page there.


Thanks!



Regards,
Alex Yiu



Yaron Y. Goland wrote:

> 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
>>