[ws-chor] 5/25/2004: Issue Clarifications Requested (fwd)

(sending to the tech list)

-- 
Yves Lafon - W3C
"Baroula que barouleras, au tiéu toujou t'entourneras."

---------- Forwarded message ----------
Date: Tue, 25 May 2004 14:36:55 -0600
From: Monica J. Martin <Monica.Martin@Sun.COM>
Subject: [ws-chor] 5/25/2004: Issue Clarifications Requested
Resent-Date: Tue, 25 May 2004 16:37:56 -0400 (EDT)


Issue 682:
Section 2.2.1:  The package construct allows aggregating a set of
Choreography definitions' where the elements informationType' token'
tokenLocator' role' relationship' participant and channelType are shared
by all the Choreographies defined within this package.

As you can see in the example from TWIST, visibility and segmentation in
a multi-party interaction are important and may affect if tokens,
participants, roles, etc. are visible between choreographies. For
example, different conversations may not be visible to all parties. Take
the TWIST, Multilateral RFQ with no exec conf and a third party trading
service case, it is variable if the sellers are aware of one another in
the interactions (Section 7.2.3).

Issue 684:
Section 2.4.2: The following rules apply to Variable Declarations:

    * If a variable is declared without a Role' it is implied that it is
      declared at all the Roles that are part of the Relationships of
      the Choreography. For example if Choreography C1 has Relationship
      R that has a tuple (Role1' Role2)' then a variable x defined in
      Chreography C1 without a Role attribute means it is declared at
      Role1 and Role2
    * The variable with channelType MUST be declared without a role
      attribute

If an information exchange or state variable, I believe the role should
be explicit rather than implicit.

On the comment regarding import and performed choreography, it is best
that the roles (if not associated with a channel type but information
exchange or state variable) be explicit. This may assist in verifying
the appropriate roles are in a relationship and the choreography
performed. Our definition of import may have further impact on this
discussion.

Issue 686:
Reference in Section 2.4.8.1: The actions within the Exception Work Unit
MAY use variable information visible in the Visibility Horizon of its
enclosing Choreography as they stand at the current time.

Unless the fault doesn't match and is propagated to the enclosing
Choreography, should the variable information be visible to the enclosed
Exception Work Unit? It seems we have a hierarchy of exception work
units, variables and choreographies. We need to determine what
restrictions apply to their visibility and use.

Issue 687:
Will think about and provide an example. Thanks.

Received on Wednesday, 26 May 2004 10:12:43 UTC