- 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>
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