Name:
"unneeded joinCondition"
Purpose: find elements, which have no meaning to the engine, and
therefore probably are a sign of an omission at design time
Check:
Find activites with an joinCondition attribute, but no target subelement. A more
compelx check could also verify, that only the linkStatus() function is used on
the incoming links. The actual semantic of join condition in absence of target
links is discussed in issue #74.
Mit freundlichen Grüßen
Bernd
Eckenfels
Chief Architect
--
SEEBURGER
AG - Edisonstr.1 , D-75015 Bretten, Germany
Fax: +49 (0)7252 96-2400 - Phone:
+49 (0)7252 96-1256
mailto: - http://www.seeburger.de
-----Original Message-----
From: Harvey Reed
[mailto:]
Sent: Tuesday, October 14, 2003
5:38 PM
To: 'ws bpel tc'
Subject: [wsbpel] Fishing
expedition for static check assumptions
All,
As you may recall, the use cases
group has structured the deliverables in such a way that there is a section in
the use case catalog for “Global Assumptions”. The assumptions so far are
divided into:
-
design time
-
deploy time
-
run time
As I read the last exchange on
issue #37 Satish mentioned that perhaps a certain error condition can be
statically detected. I also recall that Tony Andrews is also very keen on
static analysis, and I must say that I am also interested. We probably all
are.
I would like to start now by
filling in the ‘Global Assumptions’ in the use case catalog with a list of
assumptions, starting with “static checks”. If you know of any, please reply
(to the whole group please) with the following info:
Name of static
check
Purpose
Rough outline of how you think
this would be implemented.
I will put these static check
assumptions under “design time” assumptions. If there is already such a
comprehensive list, and I overlooked it, please direct me to
it.
Thanks in
advance!
Harvey Reed
Technical Product
Manager
Sonic Software
www.SonicSoftware.com
781-999-7027
