RE: RosettaNet signal dtd's

["Kanaskie, Kurt A (Kurt)" <kkanaskie@lucent.com>]

For what its worth, I agree with John's recommendations that we requirements
to TRP. This has to be done for other aspects such as process
identification, security etc. that need to have something in the TRP message
headers.

________________________________________________________________
Kurt Kanaskie
Lucent Technologies
kkanaskie@lucent.com
(610) 712-3096

 -----Original Message-----
From: 	Karsten Riemer [mailto:Karsten.Riemer@east.sun.com] 
Sent:	Thursday, March 15, 2001 8:13 PM
To:	John Yunker
Cc:	ebxml-bp@lists.ebxml.org; ebxml-tp@lists.ebxml.org
Subject:	RE: RosettaNet signal dtd's

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



------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-tp-request@lists.ebxml.org