[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue 247 additional changes in the static analysis list
Hi Mark,
thanks for your comments.
Regarding SA63:
My fault, I meant SA64 (It seems I was confused when creating that long
list because in the v22 document and the notes regarding that version it
was SA63 ;-).
SA82.1: Yes I think too it is covered by 87.2. I'll not add it.
Best regards/Mit freundlichen Grüßen,
Thomas Schulze
"Mark Ford"
<mark.ford@active
-endpoints.com> To
Thomas Schulze/Germany/IBM@IBMDE,
07.06.2006 18:10 <wsbpel@lists.oasis-open.org>
cc
Subject
RE: [wsbpel] Issue 247 additional
changes in the static analysis list
SA63 Line 3612 in ver 1.157 provides this text
"A <reply> activity is associated with an IMA, such as, <receive>,
<onMessage> and <onEvent> based on the tuple partnerLink, operation, and
messageExchange. The name used in the optional messageExchange attribute
MUST resolve to a messageExchange declared in a scope (where the process is
considered the root scope) which encloses the <reply> activity and its
corresponding IMA. This resolution follows the same scoping rules as
correlation set resolution."
SA55 and SA56: +1 on opening issues
SA82.1: -1 on creating this rule, it's covered by 87.2 as you've pointed
out.
-----Original Message-----
From: Thomas Schulze [mailto:ThomasSchulze@de.ibm.com]
Sent: Wednesday, June 07, 2006 10:00 AM
To: wsbpel@lists.oasis-open.org
Subject: [wsbpel] Issue 247 additional changes in the static analysis list
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]