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] Rel YY


Tom and Sunil,

Is this issue about preferences against attributes or against using 
attributes to drive somewhat larger decisions?  I am primarily curious 
though it might make me lean one way or the other.

At the moment, one thing seems necessary to me is preventing a sender 
including a request for ordering but no sequence number or ending a 
group that is not ordered.  How exactly those things are tied together 
and how the schema prevents four or six categories where only three have 
"meaning" seems much less important.  But, I would certainly prefer the 
proposed MessageOrder element or similar attributes *not* be allowed (in 
the schema, not just the text) without the existing SequenceNumber element.

I also believe (going the other way) that it is better to restrict a 
messaging schema so that each thing you want to "say" can be said in 
only one way.  If we re-introduce the MessageOrder element or add more 
to the SequenceNumber attributes to introduce the same categorization, 
we should remove any (overlapping) special semantics for a 
SequenceNumber of 0.

thanx,
	doug

On 26-Sep-03 16:00, Tom Rutt wrote:

> Tom Rutt wrote:
> 
>> Jacques Durand wrote:
>>
>>> Sunil, Bob,
>>>
>>> I think your revised proposal is compatible with the concerns that
>>> motivated mine.
>>>
>>>
>>> > I prefer MessageOrder (or what ever is the name) sub-element as the
>>> > triggering mechanism rather than the value of some attribute or 
>>> sub-element
>>> > to distinguish the category.
>>>
>>> I favor this too: more consistent with what we do for ack requested, 
>>> dup elimination.
>>>
>>> Jacques
>>>
>>
>> I really do not care that much, but the messageOrder element, when we 
>> took sequenceNumber
>> out, had no data but only the status attribute.  By putting the status 
>> attribute with the sequenceNumber, we got rid of the now awkward 
>> orphaned messageOrder shema structure.
>>
>> If we are not going to move sequenceNumber back with messageOrder, I 
>> think the schema
>> we have is more concise.  This is, as always, a matter of style 
>> preferences and artistic viewpoints.
>>
>> Tom Rutt 
> 
> 
> 
> New thought, if we could have the messageOrder sub element  have the 
> enum value,
> first, continue, end.    It would not have any attributes.
> 
> This would get over my "orphanedShema" problem.
> 
> The sequence number would then also have no attributes.
> 
> Would the following make everyone happy:
> 
> 1) Remove status attribute from sequenceNumber.  Keep sequence number 
> optional
> 
> 2) Place RMOrder sub element in the appropriate header, with the enum 
> value (first, continue, end).
> 
> 
>>
>>
>>>
>>>
>>>
>>
>>
> 
> 



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