← Prev in month ← Prev in thread

[ebxml-msg] Proposed CPP/A schema changes to deal with ebMS permessage parameters

From
Arvola Chan <>
Date
2001-11-19T23:14:30+00:00
ID
01d201c1714f$97916d90$
Thread
[ebxml-msg] Proposed CPP/A schema changes to deal with ebMS permessage 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
← Prev in month ← Prev in thread