[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Expression-related follow-up editing from Issue 13 (a resolved issue)
Content-Type: multipart/alternative;
boundary="------------010608050205080802020506"
This is a multi-part message in MIME format.
--------------010608050205080802020506
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Hi, BPEL TC members,
In some of our previous editing subgroup conf calls, some editors
(including me) have discussed and identified some follow-up editing
evolved from Issue 13 and an email from Andrew Francis
(andrew.francis@mail.mcgill.ca).
The section below is what I consolidate and find out so far.
The follow-up editing are pretty straight forward changes to just make
the BPEL language more consistent in terms of treating expression
language. Those changes shouldn't be controversial at all. Please let
me know whether you guys feel comfortable with direction and we may
discuss it in the upcoming F2F / TC conf call (or maybe even do a simple
vote on it ...)
Thanks!
Regards,
Alex Yiu
============================================
Follow-up editing for Issue 13
(1)
Changes were applied for Issue 13 by adding:
<condition> (of while loop) <transitionCondition>, <joinCondition>,
<query> element.
However, there was no <expression> element for "from-spec".
Looking back into the proposed resolution, expression was mentioned in
the text. However, the enumeration of syntax changes in the proposal did
not list it out explicitly.
Both Satish and Yaron think it was just an oversight.
Changes that we may need to apply to expression, including:
(i) <from expression="..." /> in Section 9.3 and Section 16
(ii) "tFrom" schema type in the XML Schema in Appendix D.
(2)
How about the "for" and "until" attributes of "wait" and "onAlarm" elements?
Should they be converted to <for-expr> and <until-expr> elements also?
(The corresponding schema type definition is: bpws:tDuration-expr and
bpws:tDeadlin-expr)
Changes that we may need to apply to "wait" and "onAlarm", including:
(i) Syntax illustration in Section 6.2
(ii) Schema type in the XML Schema in Appendix D.
(3)
Email from andrew.francis@mail.mcgill.ca
(a) Comment One from Andrew: "Why can one or more 'condition' elements
be present?"
Actually, the spec just denoted there is only one condition. It was just
some changes-tracking highlight makes it looks there was a "+" related
to the condition
(b) Comment Two from Andrew on tSwitch part of XSD.
There is a duplication of "condition" attribute and "condition"
sub-element under "case" element.
I believe the "condition" attribute (of bpws:tBoolean-expr type) needs
to be removed.
(c) Comment Three from Andrew:
------------------------
By making "case" an extension and thendefining a
"condition" element in the contentModel, doesn't
this imply that cases are written, by virtue of section 4.2of the XSD
Schema Primer (content models are added
sequentially: base + extension) as:
<case>
<activity>
<condition>
</case>
instead of:
<case>
<condition>
<activity>
</case>
------------------------
I agree with his findings in this syntax context.
It may be just syntax sugar. However, the XSD is NOT consistent with the
syntax illustrated in section 6.2.
We may make "case" element extends from tExtensibleElement instead of
tActivityContainer and have a squence of condition element and group
reference to activity.
Similarly, we want to do the similar changes for tWhile, where we just
need re-arrange element sequence in schema.
Also, we want to do the similar thing for "bpws:tOnAlarm" type, if we
want to turn "for" and "until" into an expression.
============================================
--------------010608050205080802020506
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
Hi, BPEL TC members, <br>
<br>
In some of our previous editing subgroup conf calls, some editors
(including me) have discussed and identified some
follow-up editing evolved from Issue 13 and an email from Andrew
Francis (<a class="moz-txt-link-abbreviated"
href="mailto:andrew.francis@mail.mcgill.ca";>andrew.francis@mail.mcgill.ca</a>).<br>
<br>
The section below is what I consolidate and find out so far. <br>
<br>
The follow-up editing are pretty straight forward changes to just make
the BPEL language more consistent in terms of treating expression
language. Those changes shouldn't be controversial at all. Please let
me know
whether you guys feel comfortable with direction and we may discuss it
in the upcoming F2F / TC conf call (or maybe even do a simple
vote on it ...) <br>
<br>
Thanks!<br>
<br>
<br>
Regards,<br>
Alex Yiu<br>
<br>
<br>
============================================<br>
<br>
<span style="font-weight: bold; text-decoration: underline;">Follow-up
editing for Issue 13 </span><br>
<br>
(1) <br>
Changes were applied for Issue 13 by adding: <br>
<condition> (of while loop) <transitionCondition>,
<joinCondition>, <query> element. <br>
<br>
However, there was no <expression> element for "from-spec". <br>
Looking back into the proposed resolution, expression was mentioned in <br>
the text. However, the enumeration of syntax changes in the proposal
did not list it out
explicitly. <br>
<br>
Both Satish and Yaron think it was just an oversight. <br>
<br>
Changes that we may need to apply to expression, including: <br>
(i) <from expression="..." /> in Section 9.3 and Section 16 <br>
(ii) "tFrom" schema type in the XML Schema in Appendix D. <br>
<br>
(2)<br>
How about the "for" and "until" attributes of "wait" and "onAlarm"
elements?<br>
Should they be converted to <for-expr> and <until-expr>
elements also? <br>
(The corresponding schema type definition is: bpws:tDuration-expr and
bpws:tDeadlin-expr)<br>
<br>
Changes that we may need to apply to "wait" and "onAlarm", including: <br>
(i) Syntax illustration in Section 6.2<br>
(ii) Schema type in the XML Schema in Appendix D. <br>
<br>
(3) <br>
Email from <a class="moz-txt-link-abbreviated"
href="mailto:andrew.francis@mail.mcgill.ca";>andrew.francis@mail.mcgill.ca</a><br>
<br>
(a) Comment One from Andrew: "Why can one or more 'condition' elements
be present?"<br>
Actually, the spec just denoted there is only one condition. It was
just some changes-tracking highlight makes it looks there was a "+"
related to the condition<br>
<br>
(b) Comment Two from Andrew on tSwitch part of XSD.<br>
There is a duplication of "condition" attribute and "condition"
sub-element under "case" element. <br>
I believe the "condition" attribute (of bpws:tBoolean-expr type) needs
to be removed. <br>
<br>
(c) Comment Three from Andrew:<br>
------------------------<br>
<pre wrap="">By making "case" an extension and thendefining a
"condition" element in the contentModel, doesn't
this imply that cases are written, by virtue of section 4.2of the XSD
Schema Primer (content models are added
sequentially: base + extension) as:
<case>
<activity>
<condition>
</case>
instead of:
<case>
<condition>
<activity>
</case></pre>
------------------------<br>
<br>
I agree with his findings in this syntax context. <br>
It may be just syntax sugar. However, the XSD is NOT consistent with
the syntax illustrated in section 6.2. <br>
<br>
We may make "case" element
extends from tExtensibleElement instead of tActivityContainer and have
a squence of condition element and group reference to activity. <br>
<br>
Similarly, we want to do the similar changes for tWhile, where we just
need re-arrange element sequence in schema. <br>
<br>
Also, we want to do the similar thing for "bpws:tOnAlarm" type, if we
want to turn "for" and "until" into an expression. <br>
<br>
============================================<br>
<br>
<br>
</body>
</html>
--------------010608050205080802020506--
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]