Requiring that the attribute be in the message header simplifies things
considerably. There are only two possible values, so why allow the
attribute to be omitted from the message header? The attribute should be
required and an error thrown if it is missing. Certainly, guessing by the
MSH is totally off base. It can't be allowed to second-guess the two
parties.
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
*************************************************************************************
"PEDRETTI,BRUCE (HP-NewJersey,ex2)" <bruce_pedretti@hp.com> on 11/27/2001
10:15:43 AM
To: Martin W Sachs/Watson/IBM@IBMUS
cc: "'ebxml-msg@lists.oasis-open.org'" <ebxml-msg@lists.oasis-open.org>
Subject: RE: [ebxml-msg] Proposed CPP/A schema changes to deal with ebMS
p erMessage parameters
Marty,
Arvola needed to make this clear to me, as well. The use case is that two
partners agree to perMessage semantics. But in practice, what happens on
the sending MSH side when the business app makes no perMessage indication?
Should the sending MSH make a random choice? Or, what happens when the
receiving app gets a message that has no perMessage indication? What
should
the senders and receivers do in these cases? Establishment of an agreed
upon default value (other than the one in the cpa) would promote clear
expectations and consistent results.
Bruce
============================================
Bruce Pedretti Hewlett-Packard Company
Software Developer 6000 Irwin Road
(856) 638-6060 Mt. Laurel, NJ 08054
http://www.hp.com/
============================================