OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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"/>.
 
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:arvola@tibco.com]
Sent: Monday, November 19, 2001 7:16 PM
To: Doug Bunting
Cc: ebxml-msg@lists.oasis-open.org; ebxml-cppa@lists.oasis-open.org
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 <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
 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC