OASIS ebXML Messaging Services TC

 View Only
  • 1.  Groups - ebms-v3-part2-PR-commented.odt uploaded

    Posted 10-18-2010 19:21
    Team,
    
    as agreed on last weeks call I looked at the review document of Theo
    Kramer. Theo made a lot of editorial changes which I agreed with and
    therefor didn't made changes to or commented on.
    Beside the changes Theo also added some notes to the text. I responded to
    all the notes and made some changes based on the notes. 
    
    Regards,
    Sander   
    
     -- Mr. Sander Fieten
    
    The document named ebms-v3-part2-PR-commented.odt has been submitted by Mr.
    Sander Fieten to the OASIS ebXML Messaging Services TC document
    repository.
    
    Document Description:
    
    
    View Document Details:
    http://www.oasis-open.org/committees/document.php?document_id=39862
    
    Download Document:  
    http://www.oasis-open.org/committees/download.php/39862/ebms-v3-part2-PR-commented.odt
    
    
    PLEASE NOTE:  If the above links do not work for you, your email application
    may be breaking the link into two pieces.  You may be able to copy and paste
    the entire link address into the address field of your web browser.
    
    -OASIS Open Administration
    


  • 2.  RE: [ebxml-msg] Groups - ebms-v3-part2-PR-commented.odt uploaded

    Posted 10-21-2010 15:35
     
    Hello,
    
    Here is a comment on the proposed update in line 1912 of
    this edited version of the document. 
    I propose we rephrase this as:
    
    "These referenced message units MUST have a value "optional"
    for Pmode[].bundling.policy".
    
    When we bundle a message unit with another unit, that other
    unit must support bundling, so its value for
    Pmode[].bundling.policy MUST NOT be "never", as Theo
    proposes.
    
    A bundling algorithm (not the only conceivable one, but a
    very simple one and one used in my bundling ebMS 3
    prototype) works basically by picking a unit U1 (at the
    latest bundling.maxdelay after submitting) with pmode P1
    with value "optional" for Pmode[].bundling.policy as the
    primary unit and adding zero or more units with pmodes that
    have P1 in their compatability list (subject to
    bundling.maxsize constraints). If there are none, the unit
    can sent as a standalone message. This mechanism does not
    work for units that have the value "always", since they
    always depend on some other unit.  If there is none, the
    message unit would fail. So to prevent this, these
    referenced message units also MUST NOT have a value "always"
    for Pmode[].bundling.policy. 
    
    So both the original and the proposed revision make sense.
    But right now there are too many negations in the text, so
    rephrasing the text as I am proposing here to require
    "optional" makes the text easier to read.
    
    Pim