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

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 Tuesday, 13 April 2004 15:56:52 UTC