|
SA75
I
agreed with your original point and clarification below.
My comment was that if we include language that references the common
lexical scoping rules or refer to "enclosing construct" then we should also
mention the variation on these rules for <onEvent> and its variable,
messageExchange, and correlationSet references. The rules for resolving these
references contain at least one MUST in Section 12.6.1. For example, a variable
on the <onEvent> MUST resolve to the associated scope while the other
resources resolve first to the associated scope and then the anscestor scope.
We could also avoid this altogether by not mentioning how the resources
get resolved but rather state that any unresolved resource references must
result in the process being rejected.
SA 38
It looks like the text for this rule needs to be updated. The issue
resolution must not have been applied to the spec text at the time this list was
compiled.
Mark Ford wrote:
Your comments look good. I have an issue with two of
them below and a comment on a third.
- SA32 seems to be covered by the schema?
Schema won't catch mutually exclusive attributes.
This check is intended to remove any ambiguity regarding which
from-spec/to-spec should be used when encountering an invalid construct. For
example: <from variable="v1" part="p1" property="ns:foo"/>. One impl
might treat as variable/part and another might treat as variable/proper while
a third might reject. This rule removes requires engines to reject the process
to avoid this interpretation.
Got it.
32 should probably refer, then, to the fact that the attributes/elements may
only be used in prescribed ways. It's not clear from the SA text.
- SA38 doesn't
seem like an SA directive to me. More runtime?
The phrasing
here is awkward but a literal assign that contains multiple EII's can be
detected during SA and therefore should result in rejecting the process. For
example:
<from>
<literal>
<child1/>
<child2/>
</literal>
</from>
This form of the literal will result in a
bpel:selectionFailure when executed so let's reject it during
SA.
My reading of the SA38 text doesn't
disallow this. It only says that <literal>'s children may only be
EIIs and TIIs. I agree that it should say that only one EII or only one
TII is allowed.
- SA75 seems backwards in that the invalidity is
pinned on the lack of declaration, rather than the unresolvable
reference
Should this mention the exception to the rule which
is the onEvent scoping rules? In this case the associated scope resolves the
variable. The associated scope also gets first crack at messageExchange,
correlationSets, and partnerLinks prior to resolving to the anscestor scope.
In fact there is a MUST and static analysis statement in Section 12.6.1
regarding this.
I'm not sure I understand
your point. Let me rephrase mine in hopes that it will somehow clarify
things. My preference is to state the rules for resolution, as we
do. Then to say that references to resources MUST resolve, and if they
don't, that we reject the process. Right now we say that enclosing
constructs MUST provide declarations. To make my issue more concrete, take
the following example:
process
scope
invoke ...
inputVarable="var1"
var1 is used, but not declared. I would hope
that we tag the invoke with an SA75 error. The way I read it now, we'd
have to tag either the process, or the scope, or both, with an SA75 error for
failing to declare var1.
I didn't want
to comment inline, since there are so many change marks. General
comment: Rather than just copying from the spec, the SA text should be
valid standalone, and without a lot of the description that has been
included.
- MUST be rejected by
the WS-BPEL processor -> MUST be rejected by a
compliant WS-BPEL processor
- The following sentence is grammatically
awkward, and too long. Largely because of that, it's hard to figure out
what it says. Is it taken directly from the spec?
SA00004
Determine which
languages are referenced by queryLanguage or expressionLanguage attributes
either in the WS-BPEL process definition itself or in any WS-BPEL property
definitions in associated WSDLs and if any referenced language is unsupported
by the WS-BPEL processor then the processor MUST reject the submitted WS-BPEL
process definition.
- I suggest that we add the fact that the
"within" here refers to nesting at any level: If it's directly from the
spec, change there, too. Same for 7, 8.
SA00006 - The <rethrow> activity MUST only be
used within a faultHandler (i.e. <catch> and <catchAll> elements). This
syntactic constraint MUST be statically enforced.
- WSLD -> WSDL in
SA00010. In spec, too?
- amongst -> among in SA23, 45
-
SA30 - stop the description after the MUST sentence
- Don't describe
the function in SA31
- SA32 seems to be covered by the schema?
-
SA38 doesn't seem like an SA directive to me. More runtime?
-
SA39 is not an SA check.
- don't describe the function in SA40, 41,
42
- SA47 should say that it's talking about correlation within invoke,
not just invoke
- SA48 - pending issue
- SA51 probably isn't an
SA check
- SA52 appears to contradict itself. Spec
problem?
- SA58 remove description
- SA62 is not an SA
check
- SA63 drop the last sentence
- SA64 drop all but first
sentence, and reword
- SA65 merge into SA40
- SA68, 69 drop
first sentence
- SA72 drop description
- SA73 drop description
and reword
- SA74 same
- SA75 seems backwards in that the
invalidity is pinned on the lack of declaration, rather than the unresolvable
reference
- SA76 seems to be referring to resolution rules, rather than
just saying "MUST NOT be..."
- SA77 has 2 rules in it. The second
should be deleted, since it's already covered in SA75
- SA78, 79 remove
all but last 2 sentences
- SA80 remove the introductory explanatory
clause
- SA81 drop all but first sentence
- SA84 should be
folded into SA40
- SA85 drop explanation
- SA86 drop first 2
sentences
- SA87 reword
Mehta, Vinkesh (US -
Austin) wrote:
Attached is the Appendix that contains a List of
the items for Static Analysis. This list was created with input from
Mark Ford, Paco, Thomas and Vinky.
This Appendix addresses issue 247 and issue 84.
The Appendix is essentially complete. Mark and Thomas
may want to make additional (minor) changes to this list using the
Action Items or Issues process.
All items in the list has a description that is
"almost" a duplicate of the text in the main body. There was a suggestion to
create new shorter description for brevity. But I was concerned that that
re-writing the text may change the original meaning. Hence some of the
items have a long description.
I would like to propose that we make this the new
Appendix B (And shift the existing Appendix B, C,...).
regards,
-Vinky
Attached is an updated document that focuses on
syntax checks for static analysis which is an area that Vinky and Paco's
original document did not address. I would like to see this document merged
into a single one with static analysis error codes as proposed in the
original contribution from Vinky and Paco. My updated document tries to
group similar errors together so as to avoid having dozens of repetitive
rules. For example, there could be one rule for enforcing the common lexical
scoping rules as opposed to individual rules for each occurrence of a
referenced resource.
<<...>>
This message (including any attachments)
contains confidential information intended for a specific individual and
purpose, and is protected by law. If you are not the intended
recipient, you should delete this message.
Any disclosure, copying, or distribution of
this message, or the taking of any action based on it, is strictly
prohibited. [v.E.1]
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
|