I tried to say that the element should be required in the message header. I
guess I mis-spoke there. However, if the element is not in the message
header, the CPA controls. If the CPA says "per message" and the element is
missing from the message header, it is a programming error and should not
be papered over by having a second level default. Similarly, if the CPA
says "yes" or "no" and the element is present in the message header, that's
also a programming error.
Since the program (rather, the middleware component that communicates with
the MSH) has to look for all kinds of things in the CPA, I fail to see why
this is any different.
Regards,
Marty
*************************************************************************************
Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287; IBM tie line 863-7287
Notes address: Martin W Sachs/Watson/IBM
Internet address: mwsachs @ us.ibm.com
*************************************************************************************
David Fischer <> on 11/27/2001 11:30:06 AM
To: Dale Moberg <>, Martin W
Sachs/Watson/IBM@IBMUS, "PEDRETTI,BRUCE (HP-NewJersey,ex2)"
<>
cc: Arvola Chan <>,
Subject: RE: [ebxml-msg] Proposed CPP/A schema changes to deal with ebMS
perMessage parameters
I'm not sure which side I am coming down on but I'm wondering, while
reading
this discussion, how we can make the element required/throw-an-error in one
case
(perMessage) while not allowing the element to appear in another case
(true|false). This means the program must look in the CPA to decide
whether it
should expect the element to appear? This sounds more difficult that it
should
be.
Regards,
David Fischer
Drummond Group.
-----Original Message-----
From: Dale Moberg [mailto:]
Sent: Tuesday, November 27, 2001 10:42 AM
To: Martin W Sachs; PEDRETTI,BRUCE (HP-NewJersey,ex2)
Cc: Arvola Chan;
Subject: RE: [ebxml-msg] Proposed CPP/A schema changes to deal with ebMS
perMessage parameters
I agree with Marty.
When the attribute is missing,
we can discuss what the default
value should be. I proposed "perMessage"
as the default in that case.
Chris F. doesn't like that proposal,
from what I could understand.
But I have no idea how
to decide between yes (always)
versus no (never) as a default
for requesting acknowledgements,
for example. To me it
makes sense to say that absent
an agreement upon
an explicit fixed value, make it
perMessage.
-----Original Message-----
From: Martin W Sachs [mailto:]
Sent: Tuesday, November 27, 2001 7:22 AM
To: PEDRETTI,BRUCE (HP-NewJersey,ex2)
Cc: 'Arvola Chan';
Subject: RE: [ebxml-msg] Proposed CPP/A schema changes to deal with ebMS
perMessage parameters
Since there are really only 3 cases: yes in CPA, no in CPA, per
message, I
don't understand the need for a default in the message specification.
Given that the only usable values in the message are yes and no, why
should the attribute be permitted to be left out?
Regards,
Marty
************************************************************************
*************
Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287; IBM tie line 863-7287
Notes address: Martin W Sachs/Watson/IBM
Internet address: mwsachs @ us.ibm.com
************************************************************************
*************
"PEDRETTI,BRUCE (HP-NewJersey,ex2)" <> on
11/26/2001
06:07:05 PM
To: "'Arvola Chan'" <>,
cc:
Subject: RE: [ebxml-msg] Proposed CPP/A schema changes to deal with
ebMS
p erMessage parameters
Arvola,
Thank you for helping me understand the issues. This design is elegant
in
that you nicely cover the gambit with two attributes, but perhaps it is
difficult to understand because the "flag" attribute is dual-purpose.
Sometimes "flag" provides a fixed value, sometimes it provides a
default.
This makes me a bit uneasy for two reasons: 1) if a value is a default,
then for readability the attribute name ought to indicate such (for
example, "perMessageDefault"); and 2) without annotated documentation,
this "dual-purpose" concept can not be expressed in a schema.
There are at least two other alternatives:
1) <DuplicateElimination inForce="perMessage"
perMessageDefault="false"/>
2) Use element presence for boolean conditions. For example:
a) if duplicate elimination false: <DuplicateElimination> absent
b) if duplicate elimination true: <DuplicationElimination> present
c) if duplicate elimination perMessage: <DuplicateElimination
perMessageDefault="true"/>
All 3 seem to me to have pros and cons. My preference is
for alternative
(1). My fellow hp developers prefer alternative (2). If you go with
your
original proposal, careful documentation may be important.
Bruce
============================================
Bruce Pedretti Hewlett-Packard Company
Software Developer 6000 Irwin Road
(856) 638-6060 Mt. Laurel, NJ 08054
http://www.hp.com/
============================================
-----Original Message-----
From: Arvola Chan [mailto:]
Sent: Monday, November 26, 2001 4:24 PM
To: PEDRETTIBRUCE (HP-NewJerseyex2); ;
Subject: Re: [ebxml-msg] Proposed CPP/A schema changes to deal with
ebMS
permessage parameters
Bruce:
I was allowing for the fact that the two parties may have agreed that a
property like AckRequested is "perMessage" and still specify in the CPA
a
bilaterally agreed default value (which can be different from the
schema
default) for the property should the sending application omit to specify
a
value for this property.
If such negotiated defaults are unnecessary, then I agree that your
suggested simplifications will be sufficient.
Thanks,
-Arvola
-----Original Message-----
From: PEDRETTI,BRUCE (HP-NewJersey,ex2) <>
To: 'Arvola Chan' <>; <
>
Date: Monday, November 26, 2001 12:36 PM
Subject: RE: [ebxml-msg] Proposed CPP/A schema changes to deal with
ebMS
permessage parameters
<bp>Comments in-line...</bp>
-----Original Message-----
From: Arvola Chan [mailto:]
Sent: Monday, November 26, 2001 2:58 PM
To: PEDRETTIBRUCE (HP-NewJerseyex2)
Cc: ;
Subject: Re: [ebxml-msg] Proposed CPP/A schema changes to deal with
ebMS p
ermessage parameters
Bruce:
Please see my embedded comments.
Regards,
-Arvola
-----Original Message-----
From: PEDRETTI,BRUCE (HP-NewJersey,ex2) <>
To: 'Arvola Chan' <>
Cc: <>
Date: Monday, November 26, 2001 10:35 AM
Subject: RE: [ebxml-msg] Proposed CPP/A schema changes to deal with
ebMS p
ermessage parameters
Arvola,
Thanks for taking the initiative to present these ideas to the cpa
team.
Comments:
1) Personally speaking, I had envisioned an attribute for
DuplicateElimination that had the enumerated values: true, false,
perMessage. For example, <DuplicateElimination inForce="true"/> or
<DuplicateElimination inForce="perMessage"/>.
<ac>
Even when the two parties agree that duplicate elimination is to be
specified per message, the sending MSH may still want to look to the CPA
for guidance on how this attribute should be set. That is, the
application
may explicitly specify a value for the duplicateElimination attribute,
or
choose to omit it in which case the CPA should provide the default
value.
Therefore, just having "perMessage", "true", and "false" as the only
possible values for the inForce attribute is not quite sufficient. <bp>I
don't understand what you mean by "not sufficient". What other
possible
values might there be? Just to be explicit about the meaning of these
values as I see them:
1) If "true", then both parties agree that duplicateElimination is
inForce;
2) If "false", then both parties agree that duplicateElimination should
not be performed.
3) If "perMessage", then the Receiving MSH will comply with message
header
(if possible).
Are there other arrangements? I agree that the CPA schema should
provide
a default value, but that idea is not counter to an enumeration.</bp>
</ac>
2) The AckRequested issues could also be simplified with the same
enumeration. For example <Ack requested="true" signed="perMessage"/>.
<ac>
Similarly, the CPA should provide guidance to the sending MSH whether
it
should construct an AckRequested element, if the application chooses to
omit such specification. <bp>Similar rebuttal as above</bp>
</ac>
3) Also, am I understanding correctly that you are proposing defaults
for
AckRequested such that:
<AckRequested perMessageCharacteristics="perMessage"
includeInMessageHeader="false"/>
... are these default values at odds with each other? If AckRequested
is
supposed to be decided on a per message basis, mustn't the info be
included in the message header -- or am I misunderstanding the
includeInMessageHeader attribute?
<ac>
The intended meaning is that the application may specify on a per
message
basis, whether an AckRequested element should be constructed. However,
if
the application omits such a specification, the MSH should not
construct
an AckRequested element because includeInMessageHeader is set to false.
At
the same time, this default can be changed by setting
includeInMessageHeader to true. <bp>Isn't an absence of AckRequested
and
an AckRequested="false" semantic the same? Seems to me that if
the app says nothing about an MSH ack requested, then the MSH should
not
create the AckRequested element. Under what circumstances might it
need
to create an AckRequested="false"? </bp>
</ac>
-----Original Message-----
From: Arvola Chan [mailto:]
Sent: Monday, November 19, 2001 7:16 PM
To: Doug Bunting
Cc: ;
Subject: Re: [ebxml-msg] Proposed CPP/A schema changes to deal with
ebMS
per message parameters
Doug:
The first point in my original message was intended to differentiate
message properties that originate from BPSS from those that are
specific
to the messaging specification. The DeliveryChannel element originally
contains a Characteristics element that carries BPSS related
parameters. I
am recommending that Characteristics be renamed
BusinessProcessCharacteristics before we add the new
MessagingCharacteristics element.
Here is another suggested set of schema changes to address your desire
to
allow
"acknowledgments are required for this delivery channel and the
message
will indicate whether signing is required" or "any requested
acknowledgement must be signed".
<element name="MessagingCharacteristics">
<complexType>
<sequence>
<element ref="tns:AckRequested"/>
<element ref="tns:AckSignatureRequested"/>
<element ref="tns:DuplicateElimination"/>
</sequence>
</complexType>
</element>
<element name="AckRequested">
<complexType>
<attribute name="perMessageCharacteristics" type
="tns:perMessageCharacteristics.type" default="perMessage"/>
<attribute name="includeInMessageHeader" type="boolean" default
="false"/>
<attribute name="actor" type="tns:actor.type"
default="toPartyMSH"/>
</complexType>
</element>
<element name="AckSignatureRequested">
<complexType>
<attribute name="perMessageCharacteristics" type
="tns:perMessageCharacteristics.type" default="perMessage"/>
<attribute name="flag" type="boolean" default="false"/>
</complexType>
</element>
<element name="DuplicateElimination">
<complexType>
<attribute name="perMessageCharacteristics" type
="tns:perMessageCharacteristics.type" default="perMessage"/>
<attribute name="flag" type="boolean" default="false"/>
</complexType>
</element>
<simpleType name="perMessageCharacteristics.type">
<restriction base="NMTOKEN">
<enumeration value="fixed"/>
<enumeration value="perMessage"/>
</restriction>
</simpleType>
<simpleType name="actor.type">
<restriction base="NMTOKEN">
<enumeration value="nextMSH"/>
<enumeration value="toPartyMSH"/>
</restriction>
</simpleType>
Regards,
-Arvola
-----Original Message-----
From: Doug Bunting <>
To: Arvola Chan <>
Date: Monday, November 19, 2001 3:26 PM
Subject: Re: [ebxml-msg] Proposed CPP/A schema changes to deal with
ebMS
per message parameters
Arvola,
I'm not on the CPPA list and I'm unsure about the history here. Feel
free
to forward your answers as appropriate.
What will the effect of the first point be? More particularly, what
does
this have to do with the goals you've listed above?
The line "<attribute name="actor" type="tns:actor.type"/ default
="toPartyMSH">" needs the slash moved to the end.
I like what's been described as two separate Boolean values for
AckRequested in the CPA -- one that controls whether acknowledgements
are
supported at all and another that controls whether any supported
acknowledgments may be signed. This proposal seems to eliminate that
separation. A CPA will not be able to say "acknowledgments are
required
for this delivery channel and the message will indicate whether signing
is
required" or "any requested acknowledgement must be signed".
thanx,
doug
----- Original Message -----
From: Arvola Chan
To: ;
Sent: Monday, 19 November 2001 15:12
Subject: [ebxml-msg] Proposed CPP/A schema changes to deal with ebMS
per
message parameters
At last week's ebxml-msg TC F2F meeting, it was agreed that the
duplicateElimination attribute (under QualityOfServiceInfo) and the
AckRequested element (under soap:Header)will in principle be treated as
parameters that are adjustible on a message by message basis. Trading
partners may specify in the CPA that they have agreed that these
parameters are variable per message, or that these parameters are to be
fixed at certain values, for a given delivery channel.
Accordingly, I am proposing the following changes/additions to the
CPP/A
schema:
- Rename the existing Characteristics element under DeliveryChannel as
BusinessProcessCharacteristics.
- Add a MessagingCharacteristics element under DeliveryChannel.
- Add AckRequested and DuplicateElimination elements under the
MessagingCharacteristics element, as follows:
<element name="MessagingCharacteristics">
<complexType>
<sequence>
<element ref="tns:AckRequested"/>
<element ref="tns:DuplicateElimination"/>
</sequence>
</complexType>
</element>
<element name="AckRequested">
<complexType>
<attribute name="perMessageCharacteristics" type
="tns:perMessageCharacteristics.type" default="perMessage"/>
<attribute name="includeInMessageHeader" type="boolean" default
="false"/>
<attribute name="actor" type="tns:actor.type"/
default="toPartyMSH">
<attribute name="signed" type="boolean" default="false"/>
</complexType>
</element>
<element name="DuplicateElimination">
<complexType>
<attribute name="perMessageCharacteristics" type
="tns:perMessageCharacteristics.type" default="perMessage"/>
<attribute name="value" type="boolean" default="false"/>
</complexType>
</element>
<simpleType name="perMessageCharacteristics.type">
<restriction base="NMTOKEN">
<enumeration value="fixed"/>
<enumeration value="perMessage"/>
</restriction>
</simpleType>
<simpleType name="actor.type">
<restriction base="NMTOKEN">
<enumeration value="nextMSH"/>
<enumeration value="toPartyMSH"/>
</restriction>
</simpleType>
- If the perMessageCharacteristics attribute (under AckRequested and/or
DuplicateElimination) is 'perMessage', then both parties have agreed
that
AckRequested and/or DuplicateElimination can be varied per message.
Furthermore, the sender would by default make use of attributes under
the
AckRequested and DuplicateElimination elements within the CPA to
populate
the AckRequested element and duplicateElimination attribute in the
ebXML
message. For example, if the includeInMessageHeader attribute under
AckRequested is true, then an AckRequested element will be constructed
with its actor and signed attributes populated accordingly in the ebXML
message. Of course, the sender is free to populate the AckRequested
element in the ebXML message differently, based on other criteria (if
the
CPA stipulates that this is to be treated as perMessage).
- Conversely, if the perMessageCharacteristics attribute is 'fixed',
then
both parties have agreed that AckRequested and/or DuplicateElimination)
must always be set to the same values as indicated in the CPA under the
AckRequested and DuplicateElimination elements for the corresponding
DeliveryChannel. In this case, the sender is required to make use of
attributes under the AckRequested and DuplicateElimination elements
within
the CPA to populate the AckRequested element and duplicateElimination
attribute in the ebXML message. For example, if the value attribute
under
DuplicateElimination is true, then the duplicateElimination attribute
under QualityOfServiceInfo will be set to true. Any deviation from the
agreed upon fixed values would cause the receiver MSH to return an
error.
Please let me know if you see a problem in the suggested schema change,
or
if I have mis-represented the decision reached last Thursday.
Thanks,
-Arvola
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
