MHonArc v2.5.2 -->
ebxml-msg message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: [ebxml-msg] AI from Wednesday's call: Proposal for Unrelated Bundlingfeature
Background:As we discussed during
our teleconference on Wednesday, our specification currently includes an
under specified feature without a clear business case. At least,
we haven't heard the clear business case to date. The Acknowledgment
/ RefToMessageId element supports this feature, which was new in version
2.0.
This element could allow
multiple acknowledgement messages to be combined with each other (beyond
the combination of an intermediate acknowledgement with an end to end acknowledgement).
It also supports bundling an unrelated business signal or document with
an acknowledgement message. The specification does not describe how
such a bundle should be handled when received.
Neither part of this "Unrelated
Bundling" feature appears to be in current use or have a business case.
We've also heard from a number of implementers about complications arising
from inclusion of this feature (such as internal CPA conflicts its use
could cause). Most importantly, this feature is a carry over from
the batch processing days into the more automated, interactive and dynamic
style our specification enables.
The following proposal
aims to remove this feature and includes various options for that removal.
Note that our protocol
would continue to support many other types of bundles after this removal.
It would remain possible (encouraged) to include addendums to a business
document in the same message (an order and an image showing the particular
configuration requested). It would remain possible to include multiple
business responses in the same message (three separate confirmations for
a single order). It would remain possible to include acknowledgements
with reliably delivered business documents (Acknowledgment, AckRequested
and a business response in one message that continues an entirely reliable,
asynchronous conversation). It would remain possible to include multiple
business documents in a single message that initiates a conversation (three
separate orders) though that might confuse our conversational semantics
and the receiving application. Please correct me if I'm wrong in
thinking these bundles are presently supported :-O
Proposal:
1. Deprecate or remove
the Unrelated bundling feature as described above. (That's three
options: do nothing, deprecate or prevent.)
Options:
2. Should we clarify the
existing specification to deprecate or prevent use of this feature immediately?
(Three options, adding a timeline to our answer for 1.)
3. Should we change version
3 to deprecate or prevent use of this feature? (Again, three options
though probably a repeat of our answer for 1.)
4. If done in version
2, we can use the errata sheet to
4a) add a MUST or SHOULD
(2: prevent or 2: deprecate) about not using the Unrelated bundling feature
and describe that feature as shown above.
4b) add a MUST or SHOULD
requiring the Acknowledgment / RefToMessageId element to have an identical
value to the MessageData / RefToMessageId element.
5. If done in version
3, we can rewrite specification and / or schema to
5a) add a MUST or SHOULD
(3: prevent or 3: deprecate) about not using the Unrelated bundling feature
and describe that feature as shown above.
5b) add a MUST or SHOULD
requiring the Acknowledgment / RefToMessageId element to have an identical
value to the MessageData / RefToMessageId element.
5c) remove Acknowledgment
/ RefToMessageId element entirely (3: prevent) or make it optional (3:
deprecate). 5c: optional should probably be done with 5a or 5b as
well.
Constraints:
About the only requirement
is that we do something at least as strong in version 3 as we do in version
2. No MUST in version 2 followed by SHOULD in version 3 because we're
currently at MAY.
I will defer to Ian to
begin a vote on question 1. In the meantime, does anyone have a business
case that may change others' votes on this proposal?
thanx,
doug
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC