MHonArc v2.5.2 -->
ebxml-msg message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: Re: [ebxml-msg] Constraints for RefToMessageId in Acknowledgmentelement??
Dave,
If memory serves (and it might not), this feature (the RefToMessageId
element in the Acknowledgment element) crept into 2.0 without much
discussion in the TC. It wasn't in the published 1.0 documentation and
appears as a somewhat spurious compatibility issue. In fact, the issues
list mentions this question a few times (issues 41, 149, 183 and 228). I
believe it's up to the current TC membership to decide if rules such as
"MUST match the RefToMessageId value in the MessageData element" are
appropriate.
My vote would be "yes" partially because it clarifies the specification
while avoiding XML schema changes. I would also be (slightly less)
comfortable with removing the extra RefToMessageId element entirely.
Either would be a great simplification to our specification and would
resolve both questions we've been discussing around acknowledgements.
That is, these changes would explicitly disallow bundling multiple
unrelated acknowledgement messages (anything but an end to end and / or an
intermediate acknowledgement to the same message). They would also rule
out combining an acknowledgement message with an unrelated business signal
or response (anything but the business information requested in the
original message). I don't believe any of our implementations create such
bundles when sending acknowledgements though at least a few are
complicated through attempts to decipher such "potential" bundles. Am I
correct?
While David Fischer only mentions the possible bundles (and SMTP
performance enhancements?) in his response to issue 41, it's possible the
RefToMessageId element in the Acknowledgment element was originally
designed to help us modularize the schema and to support separation of the
reliability features for broader use. If this is the case, I'd suggest
our steps towards "raising" MessageData to the top level are a more usable
/ flexible approach to the problem. This would support, for example, a
truly minimal acknowledgement message containing only the MessageData and
Acknowledgment elements.
thanx,
doug
Dave Elliot wrote:
> Is anyone able to confirm whether the RefToMessageId in an
> Acknowledgment element "MUST" or "MAY" match the RefToMessageId in the
> message's MessageHeader/MessageData ??
>
> Thanks and Regards,
>
> Dave Elliot
> XML Global Technologies
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC