[ws-chor] 4/13/2004: WS-CDL Draft Comments

In line with your request for comments on the draft specification see 
below: These comments have been mapped against previous comments to 
verify what changes have been made. Thanks.


Editorial:
1. bpel4ws is the proprietary version of WS-BPEL. We shouldn't use this 
terminology.
2. The same applies to WS-Security. Specify WS-BPEL and OASIS WS-Security.
3. If you are going to use a registry reference you should specify 
either UDDI or Registry, the choice is an implementation option not a 
limitation on either to provide the web services' functions required.

Substantive:
Figure 1
As indicated 16 March 2004, no mention is made on looking at application 
integration and the value of that in the enterprise.  There could be 
several domains of control within a logical enterprise.
Section 2.1
1. No explicit references provided for abstract and concrete (see F2F 
March 2004). See Tony Fletcher's comments as well and mine from 16 March 
2004 (should be logged in Bugzilla).

Section 2.2.1 and 2.4.6.1
Import
Can we assume that all the constraints, parameters, etc. are 
overwritten. What dictates that? What about local variables that exist 
in the including choreography, are they always considered the master? 
Concerns relate to all of Section 2.4.6 (may impact isolation).

Section 2.2.1
The design assumes that the package elements (anything in the package) 
has visibility to other elements. That may not be true. These are 
business semantics that candictate visibility and provide that 
information to a choreography.

Section 2.3.4
Clarify that the reference with support from tokens, token types, etc. 
are statically defined but dynamically bound. This is clear from the 
confusion in WS-BPEL, and we should be clear of the functions we 
describe and use.

Section 2.4.2
1. At the end of this section, you indicate that if roles are not 
declared with a Role, that the variables apply to the relationship of 
which a role could have been declared. How do these assumptions impact 
your premises on important and performed choreographies? Without 
explicitness, many assumptions could apply: Apply a Relationship R, 
error occurred, role was incorrectly specified, etc. Concerns relate to 
all of Section 2.4.6 (may impact isolation).

Section 2.4.8
Need to address concerns on 2.4.6 (may affect isolation) before 
assessing against functions described in this section. As I did 16 
March, I still would recommend we define faults or errors under 
exceptional conditions.  We are really not addressing business 
exceptions. This may create user community confusion.

Section 2.5.3
1. Please more clearly differentiate a performed choreography vs. an 
imported definition, as the former could be defined outside of the 
enclosing choreography or package. This in essence is an import.
2. As it relates to enclosing choreographies, what overrides are allowed 
if at all. What happens if conditions, parameters, constraints conflict? 
(relates to assumptions
for import).
3. In the F2F in March 2004, we indicated we did not acknowledge 
'dependent' choreographies (the blue boxes) that exist in the package or 
root (blue box). How then can we handle dependencies between imported, 
performed and choreographies with root=false?




isolation

Received on Tuesday, 13 April 2004 15:51:02 UTC