+1
This would have been discussed in today's call but we ran out of
time.
Considering that this document hasn't made it into the spec yet then it
seems reasonable that we should be able to accept all of the changes and then do
some edits from there. Accepting these changes will provide us with a clean
document for a final round of edits.
If there are no objections, then let's perhaps Thomas could hand off the
document on Friday with all of the existing changes accepted and however many of
Danny's or other people's changes edited in that he had time for. I'll continue
the editing with the hope that Vinky or someone else will be able to take the
pen some time next week.
Can we see this in context? I know that I started this style of
comments, but I realize that it was a mistake. Can we accept all previous
changes to the appendix, and start using Word comments?
Thomas Schulze
wrote:
I'd like to propose the following changes in the current
version of the static analysis list. If no-one objects I'll do the changes
at the end of the week. Additionally I should mention that there are some
section references which are nor valid any longer. I've adapted them
all.
SA49 Change the beginning to: "For <invoke>, one-way
invocation ..." Change the inner sentence to: "If a WSDL message definition
does not contain any parts, then the associated attributes variable,
inputVariable or outputVariable, or the associated <fromParts> or
<toParts> elements MAY be omitted." Important: The wrappers around
<fromPart> and <toPart> are meant here. Need to be adapted in
the spec. This is true for all other message constructs. Maybe move this
inner sentence into a new SA code and say it too for all other
constructs?
SA55 and SA56: They are valid, but not said that
explicitly in the spec. New issue?
SA63: This rule is not said that
explicit in the spec. Remove SA63 or open an issue to reflect that in the
spec?
Add SA64.1 (see section 11.5): "If <pick> has a
createInstance attribute with a value of yes, the events in the
<pick> MUST all be <onMessage> events."
SA66 Change the
wording to: "For <flow>, a declared link’s name MUST be unique among
all <link> names defined within the same immediately enclosing
<flow> ."
Add SA66.1 (see section 11.6.1): "The value of
the linkName attribute of <source> or <target> MUST be the name
of a <link> declared in an enclosing <flow>
activity."
SA67 Split up into two rules: New SA67: "Every link
declared within a <flow> activity MUST have exactly one activity
within the <flow> as its source and exactly one activity within the
<flow> as its target." SA67.1: "Two different links MUST NOT share
the same source and target activities; that is, at most one link may be
used to connect two activities."
Add SA69.1 (see section
11.6.1): "A link MUST NOT cross the boundary of a repeatable construct or
the <compensationHandler> element. This means, a link used within a
repeatable construct (<while>, <repeatUntil>, <forEach>,
<eventHandlers>) or a <compensationHandler> MUST be declared in
a <flow> that is itself nested inside the repeatable construct or
<compensationHandler>."
Add SA69.2 (see section 11.6.1): "A
link that crosses a <faultHandlers> or <terminationHandler>
element boundary MUST be outbound only, that is, it MUST have its source
activity within the <faultHandlers> or <terminationHandler>,
and its target activity outside of the scope associated with the
handler."
SA70 Adapt to the current spec text: "A <link>
declared in a <flow> MUST NOT create a control cycle, that is, the
source activity must not have the target activity as a logically preceding
activity."
SA71 Adapt to the current spec text: "The expression
for a join condition MUST be constructed using only Boolean operators and
the activity's incoming links' status values."
Add SA71.1 (see section
11.7) "The expressions in <startCounterValue> and
<finalCounterValue> MUST return a TII (meaning they contain at least
one character) that can be validated as a xsd:unsignedint. Static analysis
MAY be used to detect this erroneous situation at design time when possible
(for example, when the expression is a constant)."
SA75 (discussed
too in the thread with Danny) In chapter 12 I've not found this rule. Maybe
it should be replaced with rules like: "The partnerLink reference of
<onEvent> MUST resolve to a partner link declared in the process in
the following order: the associated scope first and then the ancestor
scopes."? The same for variables (resolve only to the ancestor
scope), correlationSets and messageExchange.
SA76 and SA77
(discussed too in the mail thread with Danny): Replace SA76 with the
current spec text (see section 12.4.3 / 12.4.3.1): "The value of the target
attribute on a <compensateScope> activity MUST refer to the name of
an immediately enclosed scope of the scope containing the FCT-handler with
the <compensateScope> activity. This includes immediately enclosed
scopes of an event handler (<onEvent> or <onAlarm>) associated
with the same scope."
Add new SA77 (see section 12.4.3.1): "The
target attribute of a <compensateScope> activity MUST refer to a
scope or an invoke activity with a fault handler or compensation
handler."
SA78 and SA79 (discussed too in the mail thread with
Danny): Replace SA78 with the current spec text (see section
12.4.4.3): "The root scope inside a FCT-handler MUST not have a
compensation handler." Remove SA79.
SA82 This rule is in section
12.5, but in the spec SA81 (12.5.2) and SA80 (12.5) are behind that rule,
so I'd like to move SA82 up so that it becomes SA79.1.
Question,
maybe a new SA82.1 check: In 12.5.3 it says: "Such compensation handlers
MUST NOT use isolated scopes themselves because isolated scopes cannot be
nested." Or is it covered by SA87.2 (see below)?
SA85 Adapt to
the current spec text: "Variables referenced by the variable attribute of
<fromPart> elements or the variable attribute of an <onEvent>
element are implicitly declared in the associated scope of the event
handler. Variables of the same names MUST NOT be explicitly declared in the
associated scope."
SA86 Adapt to the current spec text: "...and
that part is defined with an element type. That element type MUST be an
exact match of the element type referenced by the element
attribute."
SA87 Drop, it's a duplicate of SA84.
Add new
SA87.1 (see section 12.6.1): "If the variable attribute is used in the
<onEvent> element, either the messageType or the element attribute
MUST be provided in the <onEvent> element."
Add new SA87.2
(see section 12.7): "A scope with the isolated attribute set to "yes" is
called an isolated scope. Isolated scopes MUST NOT contain other isolated
scopes"
SA88 I've not found this in the current spec. Remove
it?
Best regards/Mit freundlichen
Grüßen,
Thomas
Schulze
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates
this mail. You may a link to this group and all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
|