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] Issue 103 - draft proposal



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


Title: Issue 103 Proposed Resolution

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







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