[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 247 Appendix contribution
Hi Danny, please see my comments/suggestions inline.
Best regards/Mit freundlichen Grüßen,
Thomas Schulze
Danny van der
Rijn
<dannyv@tibco.com To
> "Mehta, Vinkesh (US - Austin)"
<vmehta@DELOITTE.com>
01.06.2006 00:33 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.
<ths>IMO the list should be as equal as possible to the wording in the
spec. If it is possible to copy from the spec, we should do it. Of course,
this applies only when the resulting text is valid stand-alone.</ths>
- MUST be rejected by the WS-BPEL processor -> MUST be rejected by a
compliant WS-BPEL processor
<ths>Not sure if we need this. It's all about compliance, isn't it?</ths>
- 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.
<ths>What do you think about the following wording (the previous wording
tried to copy the wording from the spec as good as possible): "If any
referenced queryLanguage or expressionLanguage is unsupported by the
WS-BPEL processor then the processor MUST reject the submitted WS-BPEL
process definition."</ths>
- 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.
<ths>If needed, this should be addressed by an issue? I'm comfortable with
the current wording...</ths>
- WSLD -> WSDL in SA00010. In spec, too?
<ths>Good catch ;-), spec is ok (v 1.154)</ths>
- amongst -> among in SA23, 45
<ths>I agree. In SA18, SA48 and SA66, too. Change in the spec, too? -> If
yes, please open an AI if not already covered by one of the existing.</ths>
- SA30 - stop the description after the MUST sentence
<ths>I would like to keep at least "It is therefore illegal to pass into a
WS-BPEL XPath function any XPath variables, the output of XPath functions,
a XPath location path or any other value that is not a quoted string." as
more detailed description. Do you agree?</ths>
- Don't describe the function in SA31
<ths>What do you think about the following wording: "The second argument of
the XPath 1.0 extension function bpel:getVariableProperty(string, string)
MUST be a string literal conforming to the definition of QName in [XML
Namespaces] section 3."</ths>
- SA32 seems to be covered by the schema?
<ths>Regarding SA32 and your mail exchange with Mark, it currently says: "
For <assign>, the <from> and <to> element MUST be one of the specified
variants." and "...the from-spec MUST be one of the following variants: "
and "The to-spec MUST be one of the following variants:". That wording is
an exact copy of the current spec text. If it's not clear to you we should
change it with an issue?</ths>
- SA38 doesn't seem like an SA directive to me. More runtime?
<ths>I'm not sure what the outcome of your discussion with Mark is. Should
this sentence be removed from the spec and from this list because of the
resolution of issue 268? Means schema validation does the job for us?</ths>
- SA39 is not an SA check.
<ths>I agree.</ths>
- don't describe the function in SA40, 41, 42
<ths>What do you think about the following wordings:
SA40: "The first parameter of the XPath 1.0 extension function
bpel:doXslTransform(string, node-set, (string, object)*) is an XPath string
providing a URI naming the style sheet to be used by the WS-BPEL processor.
This MUST take the form of a string literal."
SA41: "In the XPath 1.0 extension function bpel:doXslTransform(string,
node-set, (string, object)*) the optional parameters after the second
parameter MUST appear in pairs. An odd number of parameters is not valid."
SA42: "For the third and subsequent parameters of the XPath 1.0 extension
function bpel:doXslTransform(string, node-set, (string, object)*) the
global parameter names MUST be string literals conforming to the definition
of QName in section 3 of [Namespaces in XML]."</ths>
- SA47 should say that it's talking about correlation within invoke, not
just invoke
<ths>What do you think about the following wording:
"The pattern attribute used in <correlation> within <invoke> is required
for request-response operations, and disallowed when a one-way operation is
invoked."</ths>
- SA48 - pending issue
<ths>Duplicate to SA77. Wait for the final resolution of issue 287 and
apply it at the correct place (either section 10.1 or 12.3.3).</ths>
- SA51 probably isn't an SA check
<ths>I think it is. This check means only WSDLs are allowed where the QName
of a fault is unique. If a WSDL defines one/two portType(s) with two
operations introducing the same fault name, this WSDL can't be used with a
WS-BPEL process. I think static analysis is the correct place to discover
that.</ths>
- SA52 appears to contradict itself. Spec problem?
<ths>Yes, I think so. Should be addressed by an issue. Can you open one?
This check should be true for <reply>, too?</ths>
- SA58 remove description
<ths>I think it's stand-alone more clear with the description.</ths>
- SA62 is not an SA check
<ths>Why not? Can't SA detect if the process contains multiple IMA and
reply activities in parallel paths which require messageExchange? Maybe add
"This requirement MAY be caught during static analysis."?</ths>
- SA63 drop the last sentence
<ths>Done.</ths>
- SA64 drop all but first sentence, and reword
<ths>Done.</ths>
- SA65 merge into SA40
<ths>It's not SA40, it's SA57, I think. I've changed that reference in the
list.
There are similar cases for other checks. I think we need to decide on a
general strategy for those checks. Say it in one rule for all constructs or
in one rule for each construct?</ths>
- SA68, 69 drop first sentence
<ths>I prefer keeping them so the rules are easier to understand and valid
stand-alone. Think about two parallel flows introducing the same link. The
sentence "Each <source> element MUST use a distinct link name." might be
misunderstood that it applies to all activities in a process. Then one of
the two links wouldn't be able to be used.
Together with SA67 it's clear what's allowed. A link must have one source
activity and one target activity and in this activity only one source
element or target element is allowed to reference the link.</ths>
- SA72 drop description
<ths>What do you think about the following wording:
"For the <forEach> activity, <branches> is an integer value expression.
Static analysis MAY be used to detect if the integer value is larger than
the number of directly enclosed activities of <forEach> at design time when
possible (for example, when the branches expression is a constant)."</ths>
- SA73 drop description and reword
<ths>What do you think about the following wording:
For <forEach> the enclosed scope MUST NOT declare a variable with the same
name as specified in the counterName attribute of <forEach>.</ths>
- SA74 same
<ths>Dropped. It's a duplicate of SA73.</ths>
- SA75 seems backwards in that the invalidity is pinned on the lack of
declaration, rather than the unresolvable reference
<ths>Not sure what the result of your discussion with Mark is. Do you like
any adaption for onEvent/forEach?
IMO this rule is ok, because it says "...in order for its reference to be
valid." Means if the declaration is missing the reference is invalid, so
that reference have to be flagged instead of a scope/the process. And it
talks about "References to resources". The variable attribute in onEvent
and the counterName in forEach are no references. That are declarations. So
this rule does not apply to them, right?</ths>
- SA76 seems to be referring to resolution rules, rather than just saying
"MUST NOT be..."
<ths>Not sure if this is still in the spec. I have not found it. Should we
remove it?</ths>
- SA77 has 2 rules in it. The second should be deleted, since it's already
covered in SA75
<ths>You mean SA76 instead of SA75? Rule 1 is a duplicate of SA48 so maybe
we can remove SA77 completely depending on the resolution of issue
287?</ths>
- SA78, 79 remove all but last 2 sentences
<ths>Done. Do we have a similar rule for terminationHandlers? I haven't
found it in the list...</ths>
- SA80 remove the introductory explanatory clause
<ths>I would leave it.</ths>
- SA81 drop all but first sentence
<ths>I think it's stand-alone better understandable with the
explanation.</ths>
- SA84 should be folded into SA40
<ths>Same comment as for SA65 above.</ths>
- SA85 drop explanation
<ths>I would leave it. Stand-alone better understandable.</ths>
- SA86 drop first 2 sentences
<ths>Done.</ths>
- SA87 reword
<ths>What do you think about the following wording:
"If <fromPart> elements are used on <onEvent>, then the variable attribute
MUST NOT be used."</ths>
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]