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

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

From: Martin Chapman <martin.chapman@oracle.com>
Date: Thu, 15 Apr 2004 14:54:23 +0100
To: "'WS-Choreography List'" <public-ws-chor@w3.org>
Message-ID: <002001c422f1$291dfb70$0901a8c0@ie.oracle.com>

Please also CC issues to the comment list:
public-ws-chor-comments@w3.org
I have already forwarded this one.

> -----Original Message-----
> From: public-ws-chor-request@w3.org 
> [mailto:public-ws-chor-request@w3.org] On Behalf Of Monica J. Martin
> Sent: 15 April 2004 02:51
> To: WS-Choreography List
> Subject: [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 Thursday, 15 April 2004 09:56:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:24 UTC