[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue - 103 - Draft of a proposal
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
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]