- 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:34 UTC