- From: Anders W. Tell <opensource@toolsmiths.se>
- Date: Mon, 31 Jan 2005 23:04:22 +0100
- 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 UTC