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


    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


Related Content