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
