Hello,
I've looked at the issue again, and now believe the
constraint on units with a "always" policy I was assuming
until last week is in fact unnecessary, so I agree with the
original proposed update to:
These referenced message units MUST NOT have a value never
for Pmode[].bundling.policy.
Sorry for the confusion, and hopefully we've now addressed
all outstanding content issues with the spec.
For the next revision we do need to look at the section
numbering, whi:
- There is a jump from 2.7.2 to 4.1.1
- Another one from 7.2 to 11.
- A third one from 11.3 to 12.1
- A fourth one from 12.9 to 14
Pim
-----Original Message-----
From: Pim van der Eijk [mailto:pvde@sonnenglanz.net]
Sent: 21 October 2010 17:35
To: 'ebxml-msg@lists.oasis-open.org'
Subject: RE: [ebxml-msg] Groups -
ebms-v3-part2-PR-commented.odt uploaded
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-----
From: pim.vandereijk@oasis-open.org
[mailto:pim.vandereijk@oasis-open.org] On Behalf Of
sander@fieten-it.com
Sent: 18 October 2010 21:21
To: ebxml-msg@lists.oasis-open.org
Subject: [ebxml-msg] Groups - ebms-v3-part2-PR-commented.odt
uploaded
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_i
d=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