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"/>.

 

2) The AckRequested issues could also be simplified 
with the same enumeration.  For example <Ack requested="true" 
signed="perMessage"/>.

 

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?

 

4) Also, please consider using another attribute name 
other than "flag".  "Flag" is not a very descriptive name.  Dividing 
the element name "AckRequested" into an element "Ack" and an attribute 
"requested" like <Ack requested="perMessage"/> is one way to get more 
descriptive attribute names -- perhaps there are others, as 
well.

 

Once again, thanks for steaming forward with these 
issues.

 

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 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