Bruce:
Please see my embedded comments.
Regards,
-Arvola
-----Original Message-----
From:
PEDRETTI,BRUCE (HP-NewJersey,ex2) <>
To:
'Arvola Chan' <>
Cc:
<>
Date:
Monday, November 26, 2001 10:35 AM
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"/>.
<ac>
Even when
the two parties agree that duplicate elimination is to be specified per
message, the sending MSH may still want to look to the CPA for guidance on how
this attribute should be set. That is, the application may explicitly specify
a value for the duplicateElimination attribute, or choose to omit it in which
case the CPA should provide the default value. Therefore, just having
"perMessage", "true", and "false" as the only possible values for the inForce
attribute is not quite sufficient.
</ac>
2) The AckRequested issues could also be simplified
with the same enumeration. For example <Ack requested="true"
signed="perMessage"/>.
<ac>
Similarly, the CPA should provide
guidance to the sending MSH whether it should construct an AckRequested
element, if the application chooses to omit such specification.
</ac>
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?
<ac>
The
intended meaning is that the application may specify on a per message basis,
whether an AckRequested element should be constructed. However, if the
application omits such a specification, the MSH should not construct an
AckRequested element because includeInMessageHeader is set to false. At the
same time, this default can be changed by setting includeInMessageHeader to
true.
</ac>
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.
<ac>
I agree
with your suggestion.
</ac>
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
