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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

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


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


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.
>



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