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
