RE: [wsbpel] Issue - 103 - Draft of a proposal

["Ugo Corda" <UCorda@SeeBeyond.com>]

Title: Message

Hi Alex and Yaron,

Thank you for all this work! I overall agree with the proposal. My comments below are primarily points of clarification (I will refer to the three attached documents in order as doc1, doc2 and doc3).

 

1) In doc1, point (1) states that a variable can be either a node-set or a value, depending on the way it is defined. We should clearly define the conversion rules from one kind to the other.

 

I think we cannot rely only on the XPath 1.0 conversion rules, because they only allow conversions from node-set to value, not the other way around. Here is an example. Suppose I am assigning the value of a variable declared with type String to another variable declared as messageType. In the <to> side I specify an XPath query which identifies a subelement of a message part which is of type String. Evidently that subelement is a node according to XPath. So I am trying to assign a value to a node, and a conversion should take place. (But, as far as I understand, XPath does not allow that type of conversion, so we would be covering new ground).

 

2) Some of the old syntax examples need to be better qualified:

 

For instance, in doc1, point (2) says:

 

<from variable="myMsg" part="part01" query="/some_x_path" />
will become:
<from>$myMsg/part01/some_x_path</from>

But, if the part was defined as a type, the old syntax would be incorrect. Here is an example:

 

<message name="Msg">

  <part name="part01" type=Type1"/>

</message>

<variable name="myMsg" messageType="Msg"/>

 

The old syntax would be:

 

<from variable="myMsg" part="part01" query="/part01/..." />

 

which becomes:

 

$myMsg/part01/...

 

where part01 only appears once in the new syntax. But if we applied your template above, it would appear twice.

 

3) Vice-versa, the old syntax in EX-1.4 and EX-1.6 (second one) of doc2 is only valid if the part is defined as a type. Let's take EX-1.4 and suppose the part was defined as an element. Here is what we could have:

 

 <message name="Msg">

  <part name="part1" element=part1"/>

</message>

<variable name="myMsg" messageType="Msg"/>

 

and the old syntax would be

 

<from variable="myMsg" part="part1" query="/part1/..." />

 

which should become:

 

$myMsg/part1/part1/...

 

contradicting EX-1.4 where part1 only appears once.

 

4) EX-1.3 and EX-1.6 (first one) provide example of old syntax that I don't think could exist. The examples show element-based variables, which of course have no associated parts. But sec. 14.3 does not even define a query string in cases where no part is used.

 

5) I personally find the use of $var syntax for linkStatus confusing, because $var immediately brings to my mind a BPEL variable instead of a control link. I would prefer to keep getLinkStatus. (This is just a personal perspective. I understand that there would be no ambiguity in use).

 

Ugo

 

 

-----Original Message-----
From: Alex Yiu [mailto:alex.yiu@oracle.com]
Sent: Tuesday, August 24, 2004 11:05 PM
To: wsbpel@lists.oasis-open.org
Cc: Alex Yiu; Yaron Y. Goland
Subject: [wsbpel] Issue - 103 - Draft of a proposal

Hi, all,

After weeks and months of discussion with various people, here are second iteration of Issue 103 proposal. The content is divided into 3 parts:

• issue103_proposal_v8.html : the core part of the proposal
• issue103_terms_and_examples.html : references and detailed examples on how Issue 103 works
• xpath_bpel_part_1.html : details of XPath semantics when used in BPEL. (Note this part is needed, regardless the syntax form of Issue 103. It has been just a underspecified area in the spec.)
  

Special thanks to Yaron (co-author of this proposal) for spending hours to nail down all the details of this proposal.

Hopefully, we can move on to formal voting for this issue between 1 to 3 weeks from now.
Thanks!!!


Regards,
Alex Yiu