RE: [wsbpel] Issue 247 Appendix contribution

["Mark Ford" <mark.ford@active-endpoints.com>]

Title: [wsbpel] Issue 247 Appendix contribution

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.

 

- 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.

 

- 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.

---

From: Danny van der Rijn [mailto:dannyv@tibco.com]
Sent: Wednesday, May 31, 2006 6:33 PM
To: Mehta, Vinkesh (US - Austin)
Cc: wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Issue 247 Appendix contribution

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

---

From: Mark Ford [mailto:mark.ford@active-endpoints.com]
Sent: Wednesday, May 10, 2006 12:12 PM
To: wsbpel@lists.oasis-open.org
Cc: Mehta, Vinkesh (US - Austin)
Subject: [wsbpel] Issue 247 Appendix contribution

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