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

mm3: Just adding the ISSUE tag as requested by Steve.

> mm2: c/Registry/ebXML Registry/Repository
>
>> mm1: 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?
>
>
>
>

Received on Wednesday, 14 April 2004 21:51:25 UTC