Hi, Ugo,
Thanks for the quick feedback.
See comments inline ...
Ugo Corda wrote:
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).
[AY = AlexYiu]
AY: When you assign a value to a node, I would not consider calling
that a conversion process. I would call the "assign/copy" process
(which is defined by BPEL).
Allow me to use W3C DOM concept here to illustrate what I mean. If the
from-spec yields a string value, the copy process semantics will be
similar to calling this DOM API: toNode.setValue(fromValue)
Currently, the "copy" semantics is an underspecified area in BPEL.
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.
AY: For the concern in 2) and 3), Ugo has sent me a separate email
before I made this proposal public. I believe I have made the
corrections on the old syntax already in the Example (doc2) file.
Still, I missed the example in Core (doc1) file. Thanks for catching
that. I have fixed it in my local copy already. Next time, when I send
out the proposal, you should be able see the correction.
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.
AY: I see what you mean. My reading of the current spec is: the current
spec under-specifies the case of the query-string on element-based
variables. It does not explicity rule it out. It does not provide a
well-defined definition either. I guess the reason of this strange
situation in the spec is: the element-based variable was added later
than message-based variable and people forgot to provide a definition
of query string in that direction. I tend to believe a number of BPEL
implementations out there allow the usage of query-string on
element-based variables. Otherwise, element-based variables are not
useful.
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).
AY: I am open to have this syntactic taste discussion issue.
Thanks!!!
Regards,
Alex YIu
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
|