Hi Doug,
On Mon, 2002-10-21 at 14:19, Doug Bunting wrote:
> That approach would probably be workable. We'd also need to nail down the
> significance of the RefToMessageId element in the Acknowledgment element.
> Is it required if this value always duplicates the MessageData contents?
> Should we require an Inconsistent error if MessageData and Acknowledgment
> contain different RefToMessageId values, for example?
Hmm I was still assuming that an Acknowledgment mshSignal could in fact
be inserted on a Business Message that was _not_ a direct response to
the message being acknowledged. ie That you could piggyback an Ack
mshSignal on any BusinessMessage headed towards that remote MSH.
I came to this conclusion because Acknowledgment does have a
RefToMessageId child... This is notable because an ErrorList does _not_
have a RefToMessageId child and is explicitly constrained as only being
allowed (as a Warning) on a message with a MessageHeader/RefToMessageId
that refers to the message-in-error.
If Acknowledgment elements could not be included where the MessageHeader
RefToMessageId was different, then that's a good question, what would be
the significance of the Acknowledgment/RefToMessageId element in the
first place?
Cheers,
Dave Elliot
XML Global Technologies
