Bruce:
I agree with you that all three schemes have pros and cons. I
can see why my proposal is confusing. In your alternative 1, if inForce is set
to "true" or "false", then I think perMessageDefault is not applicable, so it
may not be appropriate to make this a boolean attribute. Similarly, in the
alternative preferred by your fellow developers, it is not clear to me how case
(b) and case (c) can be differentiated. Again, the perMessageDefault attribute
may have to take on the enumerated values "true", "false", and "notApplicable",
rather than being a simple boolean attribute.
I will recommend to the CPP/A team that this issue be
discussed in one of the upcoming conference calls. I have no problem supporting
either one of your alternatives with the minor clarification indicated
above.
Thanks,
-Arvola
-----Original Message-----
From:
PEDRETTI,BRUCE (HP-NewJersey,ex2) <>
To:
'Arvola Chan' <>;
<>
Date:
Monday, November 26, 2001 3:07 PM
Subject: RE: [ebxml-msg]
Proposed CPP/A schema changes to deal with ebMS perMessage
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
