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>
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 <dougb62@yahoo.com>
To:
Arvola Chan <arvola@tibco.com>
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 -----
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