[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
Sending this note to connect issue 247 with the uploaded draft document
v24.
View Document Details:
http://www.oasis-open.org/apps/org/workgroup/wsbpel/document.php?document_id=18659
Download Document:
http://www.oasis-open.org/apps/org/workgroup/wsbpel/download.php/18659/Static%20Analysis%20v24.doc
Best regards/Mit freundlichen Grüßen,
Thomas Schulze
"Mark Ford"
<mark.ford@active
-endpoints.com> To
"'Danny van der Rijn'"
07.06.2006 20:38 <dannyv@tibco.com>, Thomas
Schulze/Germany/IBM@IBMDE
cc
<wsbpel@lists.oasis-open.org>,
"'Mehta, Vinkesh \(US - Austin\)'"
<vmehta@DELOITTE.com>
Subject
RE: [wsbpel] Issue 247 additional
changes in the static analysis list
+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.
From: Danny van der Rijn [mailto:dannyv@tibco.com]
Sent: Wednesday, June 07, 2006 1:54 PM
To: Thomas Schulze
Cc: wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Issue 247 additional changes in the static analysis
list
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]