Hi, all,
I forgot to mention this issue in the editor conf call today.
I have not heard anything from the editor group.
If nobody oppose, I will forward this email to the public TC.
To see whether people want to vote on this issue.
Thanks!
Regards,
Alex Yiu
Alex Yiu wrote:
Hi,
Last editing subgroup conf call, I got an action item to follow up some
editing for Issue 13 and the email from Andrew Francis.
Here is what I consolidate and find out so far. Please let me know
whether you guys want to pass this email to the public TC ... and
discuss it in the next main 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.
============================================
|