W3C home > Mailing lists > Public > public-ws-chor-comments@w3.org > January 2005

LAST CALL COMMENT 1/31/2005: Various comments and few suggest

From: Anders W. Tell <opensource@toolsmiths.se>
Date: Mon, 31 Jan 2005 23:04:22 +0100
Message-ID: <41FEAB66.6060803@toolsmiths.se>
To: public-ws-chor-comments@w3.org, public-ws-chor@w3.org

Please accept the following comments and change requests.

-----------------------------------------------------
"2.2.4 Language Extensibility and Binding
....
Extensions MUST NOT change the semantics of any element or attribute 
from the WS-CDL namespace."

Change to

"2.2.4 Language Extensibility and Binding
....
Extensions MUST NOT extend the semantics of any element or attribute 
from the WS-CDL namespace."

rationale:
Some extensions may restrict the semantics and not allow full semantics 
to be used.
-----------------------------------------------------
NOTE:  Section "2.3.2 Relationship Types"
This is an important concept and UMM specifies variations if by its 
Business Process, Collaboration and the upcomming Business Relationship 
modeling features. Thus giving it a grounding business semantics.
-----------------------------------------------------
Section 2.3.4 Channel Types
The OPTIONAL attribute "usage" should be made an Element instead of 
attribute.

Rationale:  It is common that the usage of communication resources may 
be conditional on various informations. By making it an element it is 
possible to change the current "simple" rules into a more elaborate 
mechanism.
-----------------------------------------------------
Section "2.4.2 Variables
Variables capture information about objects in a Choreography as defined 
by their usage:

    * Information Exchange Capturing Variables, which contain 
information such as an "Order" that is:
          o Used to populate the content of a message to be sent, or
          o Populated as a result of a message received"

Change to:
"2.4.2 Variables
Variables capture information about objects in a Choreography as defined 
by their usage:

    * Information Exchange Capturing Variables, which contain 
information such as an "Order" that is:
          o Used to populate the content of a message to be sent, before 
or at the occurence of message-has-been-sent-event or
          o Populated as a result of a message-received-event occurrence"

Rationale:
In order to be able to use CDL as a target language for business and 
*legally* relevant communication then Sent-, Receive-events must be 
excplicitly recognized and specified. The exact specification (of 
Dispatch-, Reach-events) may/should be determinded outside CDL but the 
low level mechanisms must be in place. This is important since these 
events govern the temporal ordering of information exchanges.

The addition of explicit Sent, Receive related event is very unintrusive 
and supports the current CDL-semantics. It all about being explicit.

Refs:
UNRecommendation 26, 31,
UN/CITRAL eCommerce <www.uncitral.org>
US-UETA
... the same aspects may be found in many countries eCommerce and 
evidentiary legislation.
-----------------------------------------------------
"2.5.5 Marking Silent Actions

The Silent Action activity is an explicit designator used for marking 
the point where party specific actions with non-observable operational 
details MUST be performed"

Suggestion: Add enforcement level (may,should, must, besteffort, 
resonable effort to the silent action specification.

Rationale: The MUST modality is only one of several enforcement levels 
traditionally used and specified. MUST may provide to hard requirements 
and may deter users to at all specify silent actions. After all how does 
one enforce an unobservable and maybe under-specified action?

Otherwise this mechanism provides a hook into business semantics which 
is appreciatd and usefull.
-----------------------------------------------------
"2.5.6 Marking the Absence of Actions"

Question: What does no action means ?? (not going to the mensroom or not 
buying a newspaper or not sending a data message?

Suggestion: This section should be reworded to related better relate to 
what actions are not performed.

-----------------------------------------------------

Section 2.5.2.3 Interaction Syntax

"   <record  name="ncname"
            when="before"|"after"|"timeout"
            causeException="true"|"false"? >
     <source  variable="XPath-expression"? | 
expression="Xpath-expression"? />
     <target  variable="XPath-expression" />
   </record>*
"
Suggestion: The definitions of successul-sending and properly-received 
is vital to any legally relevant communication specification 
mechansimssuch as CDL (see above refs). By defining *events* for when a 
data message ha been sent and receive, an important level of precision 
is achieved. The exact definition of successful reception is not only a 
technical problem but more importantly also a legal issue. A simple 
mechanism is to explicitly define the 4 Events and relate Interaction 
completions and variable binding to the events. Organisations such 
UN/CEFACT and national bodies can then apply their specific definitions 
of succesful-reception etc.

The suggestion seem easilly implementable without changing the CDL 
semantics and CDL usefulness and appropriatness for eCommerce will increase.

Adding (4 or more) Events-specifications to Recording and relate them to 
*when* be be an additions. There is a vital/key difference between 
*before* and *successful-sending* where usually the legal meaning is 
attached to *successful-sending*.

"
   <record  name="ncname"
            act="send"|"receive"
            when="before"|"after"|"timeout"
            causeException="true"|"false"? >
     <source  variable="XPath-expression"? | 
expression="Xpath-expression"? />
     <target  variable="XPath-expression" />

     <event name="ncname" act="send"|"receive" 
when="before"|"after"|"timeout"(|"exception")/>
         ... precise definitions added elsewhere ...
     </event>
   </record>*
"

It is important to, in the rest of the CDL document, be clear that the 
occurence of these events are the real trigges for variable assignements 
etc.
-----------------------------------------------------
NOTE: in the example receipt acknowledgement was use as response which 
is an importan example. In the works is a technology neutral 
StandardBusinessAcknowledge framework which can be fitted into WS and as 
it seems rather simple to add to CDL. It is now being tested in major 
nordic consortia.
-----------------------------------------------------


Best Regards
/Anders W. Tell
/Vice chair UN/CEFACT TMG
Received on Monday, 31 January 2005 22:05:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:20:10 GMT