W3C home > Mailing lists > Public > public-ws-chor@w3.org > April 2004

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

From: Monica J. Martin <Monica.Martin@Sun.COM>
Date: Tue, 13 Apr 2004 13:48:36 -0600
To: WS-Choreography List <public-ws-chor@w3.org>
Message-id: <407C4414.1070301@sun.com>

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.

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.

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.

Section 2.4.8
Need to address concerns on 2.4.6 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?


UDDI reference - implementation option for Registry

isolation
Received on Tuesday, 13 April 2004 15:48:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:01:03 UTC