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

Changes based on latest draft sent by Tony

From: Gary Brown <gary@enigmatec.net>
Date: Wed, 1 Dec 2004 10:41:38 -0000
Message-ID: <005501c4d792$5a06ab00$4b00a8c0@LATTITUDEGary>
To: <public-ws-chor@w3.org>


Section "Notational Conventions"

--> Change "others" to "other" in last bullet point:

·Examples starting with <?xml contain enough information to conform to this specification; others examples are fragments and require additional information to be specified in order to conform.

becomes:

·Examples starting with <?xml contain enough information to conform to this specification; other examples are fragments and require additional information to be specified in order to conform.



***********************

Section 2.1 "Model Overview"

Bulleted point indentation appears messed up - I am using OpenOffice, so may not be issue an issue in Word

***********************

Would suggest rewording the text regarding an interaction activity

·Interaction Activity</emph> - An Interaction is the basic building block of a Choreography, which results in an exchange of information between parties and possible synchronization of their observable information changes and also the actual values of the exchanged information

Unfortunately I cannot suggest a change, as I don't really understand what "possible synchronization of their observable information changes and also the actual values of the exchanged information" means. I assume that synchronization of the actual values of exchanged information relates to alignment - but what does synchronization of "observable information changes" mean?

***********************



Section 2.2.4 "Semantics"

Change to first sentence: semantics - remove the 's'

***********************



Section 2.3.1 "Role Types"

Does not define the behavior 'name' or its uniqueness rules/scope. Suggested text would be:

The attribute name on the behavior element is used for specifying a distinct name for each behavior element declared within a Choreography Package.

***********************

Section 2.3.2 "Relationship Types"

Change the 'behavior' attribute text to explain the delimiters used to separate members of the list.

Change text from:

Within the role element, the OPTIONAL attribute behavior identifies the commitment of a party as a list of behavior types belonging to the Role Type specified by the type attribute of the role element. If the behavior attribute is missing then all the behaviors belonging to the Role Type specified by the type attribute of the role element are identified as the commitment of a party.

to:

Within the role element, the OPTIONAL attribute behavior identifies the commitment of a party as a list of behavior types belonging to the Role Type specified by the type attribute of the role element. The list of behavior types will be delimited by a <whitespace,comma,???>. If the behavior attribute is missing then all the behaviors belonging to the Role Type specified by the type attribute of the role element are identified as the commitment of a party.

***********************

Section 2.3.3 "Participant Types"

End of first paragraph: change "by" to "be"

Change from:

Variable types can by re-used in any role in any participant but values of an instance of a type can only be shared between roles that are defined to be part of a single participant.

to:

Variable types can be re-used in any role in any participant but values of an instance of a type can only be shared between roles that are defined to be part of a single participant.

***********************



Section 2.3.4 "Channel Types"

Paragraph 10, first sentence, change from:

The OPTIONAL element passing describes the Channel Type(s) of the Channel(s) that are passed from one party to another, when using in an information exchange a Channel of this Channel Type.

to:

The OPTIONAL element passing describes the Channel Type(s) of the Channel(s) that can be passed, from one party to another, as part of an information exchange on a Channel of this Channel Type.

***********************

ISSUE: No mechanism for specifying that no channels can be passed

Suggested change: (making the 'channel' optional)

<passing channel="qname"?

action="request-respond"|"request"|"respond"?

new="xsd:boolean"? />*



Change text from:

The OPTIONAL element passing describes the Channel Type(s) of the Channel(s) that are passed from one party to another, when using in an information exchange a Channel of this Channel Type. The OPTIONAL attribute action within the passing element defines if a Channel will be passed during a request exchange, during a response exchange or both. The default for this attribute is set to "request-respond". The OPTIONAL attribute new within the passing element when set to "true" enforces a passed Channel to be always distinct. 

If the element passing is missing then this Channel Type MAY be used for exchanging business documents and for passing Channels of any Channel Type without any restrictions.

to:

The OPTIONAL element passing describes the Channel Type(s) of the Channel(s) that can be passed, from one party to another, as part of an information exchange on a Channel of this Channel Type. The OPTIONAL attribute channel is used to identify the Channel Type of a Channel that can be passed. The OPTIONAL attribute action within the passing element defines if a Channel will be passed during a request exchange, during a response exchange or both. The default for this attribute is set to "request-respond". The OPTIONAL attribute new within the passing element when set to "true" enforces a passed Channel to be always distinct. 

If the OPTIONAL channel attribute on the passing element is missing then this Channel Type MAY be used for exchanging business documents and for passing Channels of any Channel Type without any restrictions.

If the element passing is missing then this Channel Type MAY NOT be used for passing Channels of any Channel Type.

***********************

Section 2.4.1 "Information Types"

Update the paragraph:

When the attribute exceptionType is set to "true", this information type is an Exception Type and could map to WSDL fault type. The default for this attribute is set to "false".

to:

When the attribute exceptionType is set to "true", this information type is an Exception Type and could map to a WSDL fault type. If the exceptionType is set to "false", then the information type cannot specify a WSDL fault type. The default for this attribute is set to "false".
Received on Wednesday, 1 December 2004 10:41:55 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:01:06 UTC