OASIS ebXML Messaging Services TC

[ebxml-msg] AI from Wednesday's call: Proposal for Unrelated Bundlingfeature

  • 1.  [ebxml-msg] AI from Wednesday's call: Proposal for Unrelated Bundlingfeature

    Posted 10-25-2002 20:04
     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