Re: [ebxml-msg] Revised proposal for "per message" properties

[Arvola Chan <arvola@tibco.com>]

Doug:

Sorry for the delayed response. Please see inline.

Regards,
-Arvola

-----Original Message-----
From: Doug Bunting <dougb62@yahoo.com>
To: Arvola Chan <arvola@tibco.com>
Date: Friday, November 30, 2001 6:50 PM
Subject: Re: [ebxml-msg] Revised proposal for "per message" properties


>Arvola,
>
>Perhaps this is a side issue but I'd prefer all of these attributes to be
>required.  What does it mean when they aren't in a fully-formed CPA?  Are
>they only optional in a CPP?
>

I would rather make these attributes required both in the case of a CPP and
in the case of a CPA.

>Also, I'd prefer it be possible to direct an AckRequested to the ultimate
>destination, not the store-and-forward node operating on their behalf
>(ToPartyMSH).  You'd probably need some additional value in the enumeration
>that means "leave this attribute off the AckRequested element".
>

Section 2.2.10 and 2.2.11 define the URI's that correspond to the next MSH
and the to party MSH. I have been assuming that these are the only possible
values for the actor attribute in the AckRequested element. If omitting the
actor attribute is a valid option, I think the Messaging spec must explain
what that means. It would be clearer to enumerate all possible values for
the actor attribute, rather than defining another enumeration value to
indicate that the actor attribute be omitted from the AckRequested element.

>What would happen later if we add additional SOAP extensions that allow the
>soap:actor attribute?  You probably want to make it clear this one is for
>the matched AckRequested / Acknowledgement pair.
>

Yes, this should be clearly documented in the CPP/A spec.

>later,
>    doug
>
>----- Original Message -----
>From: "Arvola Chan" <arvola@tibco.com>
>To: "Arvola Chan" <arvola@tibco.com>; <ebxml-msg@lists.oasis-open.org>
>Cc: <ebxml-cppa@lists.oasis-open.org>; <mwang@tibco.com>
>Sent: Friday, 30 November 2001 18:42
>Subject: [ebxml-msg] Revised proposal for "per message" properties
>
>
>Based on a discussion I have had with Michael Wang, I like to simplify my
>proposal. Essentially, we like to make the structure of
>MessagingCharacteristics mirror that of BusinessProcessCharacteristics
which
>has an empty content model with only a number of attributes.
>
>Also, I no longer think that MessageOrder should be a "per message"
>property. Instead, its presence or absense in a message should be
completely
>governed by a Reliable Messaging parameter in the CPA. It should only be
>present in the message header if the CPA indicates that the message order
>semantics is "Guaranteed". This requires removal of the
>messageOrderSemantics attribute from the MessageOrder element.
>
>Attached please find updated schemas for ebxml-msg and ebxml-cppa
>corresponding to this proposal.
>
>The MessagingCharacteristics element now look like:
>
> <element name="MessagingCharacteristics">
>  <complexType>
>   <attribute name="ackRequested" type="tns:perMessageCharacteristics.type"
>default="perMessage"/>
>   <attribute name="ackSignatureRequested"
>type="tns:perMessageCharacteristics.type" default="perMessage"/>
>   <attribute name="duplicateElimination"
>type="tns:perMessageCharacteristics.type" default="perMessage"/>
>   <attribute name="actor" type="tns:actor.type"
>default="urn:oasis:names:tc:ebxml-msg:actor:toPartyMSH"/>
>  </complexType>
> </element>
> <simpleType name="perMessageCharacteristics.type">
>  <restriction base="NMTOKEN">
>   <enumeration value="always"/>
>   <enumeration value="never"/>
>   <enumeration value="perMessage"/>
>  </restriction>
> </simpleType>
> <simpleType name="actor.type">
>  <restriction base="NMTOKEN">
>   <enumeration value="urn:oasis:names:tc:ebxml-msg:actor:nextMSH"/>
>   <enumeration value="urn:oasis:names:tc:ebxml-msg:actor:toPartyMSH"/>
>  </restriction>
> </simpleType>
>
>-Arvola
>
>-----Original Message-----
>From: Arvola Chan <arvola@tibco.com>
>To: ebxml-msg@lists.oasis-open.org <ebxml-msg@lists.oasis-open.org>
>Cc: ebxml-cppa@lists.oasis-open.org <ebxml-cppa@lists.oasis-open.org>
>Date: Thursday, November 29, 2001 12:33 PM
>Subject: Re: [ebxml-msg] Agenda December 3
>
>
>>Attached please find a tentative schema for the evolving CPP/A spec. It
>>incorporates Dale's suggestion to use "always", "never", and "perMessage"
>as
>>the enumerated values for tns:perMessageCharacteristics.type.
>>
>>The relevant constructs for "per message" properties are as follows:
>>
>> <element name="MessagingCharacteristics">
>>  <complexType>
>>   <sequence>
>>    <element ref="tns:Ack"/>
>>    <element ref="tns:AckSignature"/>
>>    <element ref="tns:DuplicateElimination"/>
>>    <element ref="tns:MessageOrder"/>
>>   </sequence>
>>  </complexType>
>> </element>
>> <element name="Ack">
>>  <complexType>
>>   <attribute name="requested" type="tns:perMessageCharacteristics.type"
>>default="perMessage"/>
>>   <attribute name="actor" type="tns:actor.type" default="toPartyMSH"/>
>>  </complexType>
>> </element>
>> <element name="AckSignature">
>>  <complexType>
>>   <attribute name="requested" type="tns:perMessageCharacteristics.type"
>>default="perMessage"/>
>>  </complexType>
>> </element>
>> <element name="DuplicateElimination">
>>  <complexType>
>>   <attribute name="requested" type="tns:perMessageCharacteristics.type"
>>default="perMessage"/>
>>  </complexType>
>> </element>
>> <element name="MessageOrder">
>>  <complexType>
>>   <attribute name="requested" type="tns:perMessageCharacteristics.type"
>>default="perMessage"/>
>>  </complexType>
>> </element>
>> <simpleType name="perMessageCharacteristics.type">
>>  <restriction base="NMTOKEN">
>>   <enumeration value="always"/>
>>   <enumeration value="never"/>
>>   <enumeration value="perMessage"/>
>>  </restriction>
>> </simpleType>
>>
>>-Arvola
>>
>>-----Original Message-----
>>From: ian.c.jones@bt.com <ian.c.jones@bt.com>
>>To: ebxml-msg@lists.oasis-open.org <ebxml-msg@lists.oasis-open.org>
>>Date: Thursday, November 29, 2001 8:25 AM
>>Subject: [ebxml-msg] Agenda December 3
>>
>>
>>>Agenda December 3 - Voting
>>>
>>>1. Roll call - Voting Membership
>>>
>>>2. SyncReply Module
>>>
>>>3. PersistDuration
>>>
>>>4. CPA & MS overriding parameters
>>>   Proposed CPP/A schema changes to deal with ebMS perMessage parameters
>>>
>>>5. Editorial issues
>>>
>>>6. Agree our deadline for delivery - NO MORE FUNCTIONAL CHANGES
>>>WHATSOEVER!!!
>>>
>>>7. AOB
>>>
>>>
>>>Apologies - I may be late joining as I am on Vacation - David Fischer
will
>>>you lead as you need the answers to the agenda points.
>>>
>>>
>>>Ian Jones
>>>Chair OASIS ebXML Messaging Services TC
>>>
>>>Tel: +44 (0)29 2072 4063
>>>Fax: +44 (0)29 2072 4137
>>>Email: ian.c.jones@bt.com
>>>
>>>
>>>
>>>----------------------------------------------------------------
>>>To subscribe or unsubscribe from this elist use the subscription
>>>manager: <http://lists.oasis-open.org/ob/adm.pl>
>>
>
>