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
|