RE: RosettaNet signal dtd's

[Karsten Riemer <Karsten.Riemer@east.sun.com>]

John,
thanks for your recommendation. I agree on all three points. I think TP team
has previously  declined getting into this space, but I copy them here again
to see if anything has changed.

And Jamie, do you have input to this, before we make any final decision?

-karsten

>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