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
|