RE: RosettaNet signal dtd's

[Martin W Sachs <mwsachs@us.ibm.com>]

Karsten,

I'm not sure what you believe that the TP team has declined getting into or
when.  The only discussion I recall on these subjects was the discussion in
the Boston F2F about which business signals are application to application
and which ar middleware to middleware. However that is completely separate
from the question of what is in scope for the TP team.

Certainly, any agreements that are necessary about business signals are
within the scope of the TP team though, practically speaking, it would be
for after Vienna at this point.

In particular, anything related to nonrepudiation of receipt or origin is
clearly with the scope of the TP team unless the signing and signature
checking take place entirely within the application rather than within the
document-exchange section of the CPA.

Regards,
Marty

*************************************************************************************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************



Karsten Riemer <Karsten.Riemer@east.sun.com> on 03/15/2001 08:12:37 PM

Please respond to Karsten Riemer <Karsten.Riemer@east.sun.com>

To:   John Yunker <JohnY@EDIFECS.COM>
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