RE: RosettaNet signal dtd's

[John Yunker <JohnY@EDIFECS.COM>]

Karsten, BP team,

If you have decided to use the RNIF 2.0 implementation for ebXML initial
implementation, then here are my recommendations for constructing an
acceptance acknowledgement.

Before I get to the recommendations please note the following:

While the acknowledgement of receipt has a very narrowly defined purpose,
that acceptance ack is more broadly defined:
1) While the receipt ack simply states that the message is "readable", in
that its structure is recognizable and content parsable, the acceptance ack
states that the content is actionable, in that its content meets minimum
business rules required for the responding action to be undertaken.
2) The business effect of the receipt ack is to transition the originator's
transaction state machine from "delivering message" to "request tendered",
while the business effect of the acceptance ack is to transition the
requester's transaction state machine from "request tendered" to "response
promised"  (note that this completes any negotiation on the acceptability of
the request, which allows the requester to optimize his internal process
based on more certainty in the transaction timing)

In effect, the acceptance ack allows the parties to electronically negotiate
the terms of the request before delivering the request to the responding
business activity.  As such it should have some input from Jamie on what
elements are necessary to convey that the request meets the terms
established by the responder for a valid request. (note that electronic
negotiation requires adding an "offendingElement" element to the exception
signal as recommended below)

In RosettaNet RNIF 2.0 the signals were constructed as part of the messaging
implementation infrastructure to work in conjuction with the service header
which contains the elements which connect the signal to the original message
(to tie the collaboration together). For ebXML ccbp to construct signals
without close cooperation with TRP is very dangerous.  If TRP has provided
for association of signals with original messages, then it is probably
sufficient to clone the receipt ack and use its structure.  If TRP has not
adequately provided for the association of messages in the larger context of
a collaboration, then those elements must be added to both the receipt ack
and the acceptance ack.  I confess that I have not been through the TRP spec
with this end in mind.

My recommendations for the acceptance ack:
1) give requirements to TRP and have them construct the implementation dtd
for signals (may be too late for this, but at least the dialogue should take
place - please excuse my ignorance if that dialogue has already taken
place).
2) have Jamie provide necessary elements for an acceptance ack to convey
that the request meets the responders terms (business rules) for an
actionable request.
3) keep it as simple as possible for version 1, and just use the receipt ack
structure if items 1 and 2 are either addressed or dismissed.

My recommendations for the exception signal:
1) add a 0..n "offendingElement[XPATH]" or similar element so that the
originating system can optimize the ability of the requester to correct the
message, and so statistics can be maintained for evolution of message
structure / validation rules.

regards,
John

-----Original Message-----
From: Karsten Riemer [mailto:Karsten.Riemer@east.sun.com]
Sent: Thursday, March 15, 2001 12:57 PM
To: ebxml-bp@lists.ebxml.org; ebxml-core@lists.ebxml.org
Subject: RosettaNet signal dtd's


Hi,
In specschema 0.90 we had included RosettaNet RNIF 1.0 dtd's as the
recommended dtd's for business signals. For specschema 1.0 we need to at the
very least update these to the much simplified RNIF 2.0.

A couple of questions before I do so:

1. Does UMM have a set of signal DTD's we should use instead.
2. RNIF 2.0. does not have an acceptanceAcknowledgement. Should I just clone
the RNIF 2.0. receiptAcknowledgement? 3. Should we include the generic
notification of failure? (This is not a signal, but a generic Business
Document to notify another party about a failure). 4. Does anyone in core
components have suggestions how to use core components in any of these
signals, they have tags like telephone number etc. in them.

Attached are the two signals receiptAcknowledgement and exception, and the
notificationOfFailure.

thanks,
-karsten