[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue 247 Appendix contribution
Hi all!
Mark and Danny, thanks for your comments.
I'd like to propose before starting with any further editing in this
appendix to accept all changes first. That way we will see more clearly
what have been changed in this new editing cycle. If there's no objection
I'll do that tomorrow and start with adding your comments into the
document.
If there are any new entries in the table I'll use the code of the previous
rule, add a "." and then a number which will be increased accordingly. For
example if we like to add a new entry after SA00045, the new will get the
code SA00045.1. This way we don't loose the references from the mails to
the document. Shortly before approving the document finally, I'll update
all codes.
Thanx!
Best regards/Mit freundlichen Grüßen,
Thomas Schulze
"Mark Ford"
<mark.ford@active
-endpoints.com> To
"'Danny van der Rijn'"
01.06.2006 02:52 <dannyv@tibco.com>, "'Mehta,
Vinkesh \(US - Austin\)'"
<vmehta@DELOITTE.com>
cc
<wsbpel@lists.oasis-open.org>
Subject
RE: [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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]