Re: [wsrm] Why not Get Rid of Request Header

[John Fuller <jfuller@wernervas.com>]

I guess I see why you'd want to abstract it away from use as a header
to use as an elemental type...
Maybe the prefix "Messaging" for data/info
since it's scoped by the RM namespace anyway I suppose there
wouldn't be confusion with other aspects of messaging?

On Monday, September 29, 2003, at 02:29 PM, John Fuller wrote:

> To me,
> a header suggests information for use by a messaging layer for a  
> message
> MetaData suggests information about the data in the message, the  
> contents
> MessageData suggests data in the message, the contents
> MessageInfo suggests information about the message,
> but information is a pretty broad domain.   Often the word
> is used to indicate an optional or human readable collection of data.
> In any case, it doesn't suggest that it is expressly for use by
> a messaging layer the way headers are traditionally used...
>
>
>
> On Monday, September 29, 2003, at 02:06 PM, Sunil Kunisetty wrote:
>
>>
>>  Tom,
>>
>>  We need to abstract the Metadata information (MessageHeader - we  
>> really need
>>  to change this to either MessageInfo, MessageData or MetaData) with  
>> the RM
>>  information so that we could reuse a different MetaData Header if  
>> one exists and
>>  becomes standard in the future.
>>
>>  It will be too rigid juxtaposing RM & MetaData information into one  
>> header.
>>
>>  My $0.02.
>>
>>  -Sunil
>>
>> Tom Rutt wrote:
>>
>>> Tom Rutt wrote:
>>>
>>>> Here is a counterproposal for consideration and comment:
>>>>
>>>> Lets look at the request message type.
>>>> <xsd:complexType name="RequestType">
>>>>        <xsd:complexContent>
>>>>            <xsd:extension base="wsrm:RmBaseType">
>>>>                <xsd:sequence>
>>>>                    <xsd:element name="DuplicateElimination"
>>>> type="wsrm:EmptyType" minOccurs="0"/>
>>>>                    <xsd:element name="AckRequested"
>>>> type="wsrm:EmptyType" minOccurs="0"/>
>>>>                </xsd:sequence>
>>>>            </xsd:extension>
>>>>        </xsd:complexContent>
>>>>    </xsd:complexType>
>>>>
>>>> I has two empty elements which are flags for some protocol  
>>>> operation.
>>>>
>>>> Now if we had the presence of groupID be the trigger for  
>>>> acknowledement
>>>> features, we
>>>> could get rid of one empty element.
>>>>
>>>> Lets go one step further, we could require sequence numbers for
>>>> duplicate elimination (due to
>>>> simplification of algorithm design) and use the sequence number as  
>>>> the
>>>> signal for duplicate elimination features.
>>>
>>> Actually we could put the duplicate elimination as an attribute of  
>>> group id.
>>>
>>> --
>>> ----------------------------------------------------
>>> Tom Rutt                email: tom@coastin.com; trutt@fsw.fujitsu.com
>>> Tel: +1 732 801 5744          Fax: +1 732 774 5133
>>>
>>> To unsubscribe from this mailing list (and be removed from the  
>>> roster of the OASIS TC), go to  
>>> http://www.oasis-open.org/apps/org/workgroup/wsrm/members/ 
>>> leave_workgroup.php.
>>
>>
>> To unsubscribe from this mailing list (and be removed from the roster  
>> of the OASIS TC), go to  
>> http://www.oasis-open.org/apps/org/workgroup/wsrm/members/ 
>> leave_workgroup.php.
>>
>
>
> To unsubscribe from this mailing list (and be removed from the roster  
> of the OASIS TC), go to  
> http://www.oasis-open.org/apps/org/workgroup/wsrm/members/ 
> leave_workgroup.php.
>