Re: [ws-rx] Issue i147 - make your choice!

[Doug Bunting <Doug.Bunting@Sun.COM>]

I applaud Matt's work to complete my action item.

Direction (2) below is pretty much what I had in mind. This may be a
slightly larger change than (3) but also provides a higher level of
"consistency", a requirement mentioned earlier on this thread. Given the
relatively simple nature of the individual changes, my preference is for
(2) because it will result in a slightly smaller and simpler
specification and schema. We aren't undercutting interoperability but
making small changes in how later extensions might be written.

I don't like (1) much at all because it adds a lot of words and schema
content with very little value due to overlapping semantics. When <a/>
always contains <b/>, extending either is semantically identical. When
<a/> optionally contains <b/>, <a/>'s extension point could easily be
used to add content modifying <b/> (if present) without losing
extensibility.

We unfortunately have direction (2a) as well: In Matt's original
"[ws-rx] Issue i147 - alternative proposal" email, he mentioned an idea
I like a great deal. That option would remove the Identifier element
from those losing extensibility and move us a bit closer to (3). The
main advantage in leaving Identifier extensibility alone is its separate
identity in the "copied around from element to element" sense. We should
allow Identifier to be extended because its content is reused.

I would go one step further (creating direction (2b) I guess) and leave
at least AcknowledgementRange with its current attribute extensibility.
This element may appear multiple times within its parent SOAP header and
some extension may apply individually to a range. This option builds on
(2a), leaving the existing Identifier extensibility alone as well. Like
(2a), (2b) again moves closer to (3).

If we're willing to move a bit in the opposite direction (to (2c),
sorry), Nack should probably have attribute extensibility for the same
reasons as AcknowledgementRange and there's no reason the forced-empty
AcknowledgementRange content couldn't instead be an element
extensibility point for consistency with its existing attribute
extensibility. This option builds on (2b), leaving the existing
Identifier and AcknowledgementRange extensibility (limited to attribute
extensibility in the AcknowledgementRange case) alone.

My (micro-)preferences are (2c) then (2b) then (2a).

thanx,
doug

On 11/07/06 08:23, Marc Goodner wrote:
> I prefer 3, and that does sound like what we discussed.
>
> -----Original Message-----
> From: Matthew Lovett [mailto:MLOVETT@uk.ibm.com] 
> Sent: Tuesday, July 11, 2006 12:38 AM
> To: ws-rx@lists.oasis-open.org
> Subject: Fw: [ws-rx] Issue i147 - make your choice!
>
> Hi all,
>
> I'd hoped we would have time to discuss this issue on the last call, but
> it didn't happen. What I'd like is for the TC to express the direction
> that you'd like to take, and then I'll do the legwork to get a concrete
> proposal on list before Thursday. Hopefully that will give us at least
> one easy issue this week :)
>
> There are currently 3 directions on offer:
>
> 1. Add extensibility, so that it is consistently everywhere. This is the
> proposal 1 in the original issue
> http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i147
>
> 2. Remove some extensibility, so that only top-level elements allow
> extensions. This is proposal 2 in the issue
> http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i147
>
> 3. Do minimal change to get the exemplars, text, and schema in sync
> (with that order - e.g. no exemplar change, and force the schema into
> line last).
> This is my interpretation of what Chris and Marc suggested, but we don't
> have concrete text for it yet. Arguably, this is a delta that can be
> managed by the editors.
>
> My opinion is that I can go with Chris / Marc's preferred option of
> minimal change at this point in the spec lifecycle. Equally, I'd be
> happy with 2 (the changes may look scary, but they mostly just remove
> extensibility from the wsrm:Identifier element, and I'm not sure when
> you'd want to extend that).
>
> If you can let me know how you feel about this one then we should be
> able to get some consensus before the call.
>
> Thanks
>
> Matt
>
>
> "Marc Goodner" <mgoodner@microsoft.com> wrote on 06/07/2006 17:34:19:
>
>   
>> +1
>>
>> From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
>> Sent: Wednesday, July 05, 2006 7:37 PM
>> To: ws-rx@lists.oasis-open.org
>> Subject: Re: [ws-rx] Issue i147 - alternative proposal
>>
>>
>> IMO, I think that the way that we should deal with this issue is to 
>> reconcile what is currently specified (e.g. align the text with the 
>> exemplars and schema).
>>
>> I agree that top-level elements should be extensible via elements and 
>> attributes and that this principle need not necessarily apply to the 
>> descendants of those top-level elements. However, I think that the 
>> guiding principle here should be "do no harm". If there are child 
>> elements of top-level elements that have either or both attribute or 
>> element extensibility in the exemplar (or schema) then the prose 
>> should match that. If not, then leave things as they are.
>> If the schema is not consistent with
>> the exemplars, then the schema should be changed to match the exemplar
>>     
>
>   
>> unless of course, there is prose indicating either or both element or 
>> attribute extensibility that is not reflected in the exemplar, in 
>> which case the exemplar should be corrected to reflect the elipses.
>>
>> I think that we should be striving at this point to change as little 
>> as possible, with the aim to simply make the specification internally 
>> consistent.
>>
>> Cheers,
>>
>> Christopher Ferris
>> STSM, Software Group Standards Strategy
>> email: chrisfer@us.ibm.com
>> blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
>> phone: +1 508 377 9295
>>
>> Matthew Lovett <MLOVETT@uk.ibm.com> wrote on 07/04/2006 11:43:48 AM:
>>
>>     
>>> Hi all,
>>>
>>> I thought I should follow up on this issue, following Doug B's
>>>       
> comments 
>   
>>> that we don't need to put extensibility everywhere. I'm inclined to
>>>       
> agree 
>   
>>> - the direction I took in the proposal was an attempt to add
>>>       
> extensibility 
>   
>>> into the doc, but it's just as valid to switch the other way and
>>>       
> remove 
>   
>>> some of the overkill. How's this for an alternative proposal:
>>>
>>> The guiding principle is that each top-level element we define 
>>> should
>>>       
> have 
>   
>>> both element and attribute extensibility. Child elements need not be
>>>       
>
>   
>>> extensible, except in special cases. The only special cases I could
>>>       
> see 
>   
>>> were the Offer and Accept elements, which are logically quite 
>>> separate
>>>       
>
>   
>>> from the containing CreateSequence(Response) and I think they 
>>> benefit
>>>       
> from 
>   
>>> separate extensibility. If we add in the wsrm:Identifier element as 
>>> another special case then the deltas below become a lot simpler, but
>>>       
>
>   
>>> I
>>>       
>
>   
>>> can't see any reason why that element should be special. I think 
>>> that
>>>       
> the 
>   
>>> current extensibility of wsrm:Identifier is just the result of 
>>> copy-and-paste.
>>>
>>> Another noteworthy point - where types defined by others (such as
>>> wsa:EndpointReferenceType) allow extensibility, I don't see any need
>>>       
> to 
>   
>>> point that out in our document. They have their own descriptions ;)
>>>
>>> Here's some detail, based off the files in: 
>>> http://oasis-open.org/apps/org/workgroup/ws-rx/download.
>>> php/19014/Latest%20WSRX.zip
>>>
>>> CreateSequence exemplar:
>>> Line 271 Strike the ellipsis from wsrm:AcksTo Line 272 Strike the 
>>> ellipsis from wsrm:Expires Line 274 Strike the ellipsis from 
>>> wsrm:Offer/wsrm:Identifier Line 276 Strike the ellipsis from 
>>> wsrm:Offer/wsrm:Expires
>>>
>>> Descriptive text:
>>> Line 304-306 Strike the description of 
>>> wsrm:CreateSequence/wsrm:Expires/@{any}
>>> Line 313-315 Strike the description of 
>>> wsrm:CreateSequence/wsrm:Offer/wsrm:Identifier/@{any}
>>> Line 331-333 Strike the description of 
>>> wsrm:CreateSequence/wsrm:Offer/wsrm:Expires/@{any}
>>> Line 334-339 Move the description of the Offer wildcards below the 
>>> description for wsrm:Offer/wsrm:IncompleteSequenceBehavior
>>> Line 351 The font used for wsrm:CreateSequence/{any} seems to be 
>>> wrong
>>>
>>>
>>> CreateSequenceResponse exemplar
>>> Line 363 Strike the ellipsis from wsrm:Identifier Line 369 Strike 
>>> the ellipsis from wsrm:Accept/wsrm:AcksTo
>>>
>>> Descriptive text:
>>> Line 382-384 Strike the description of 
>>> wsrm:CreateSequence/wsrm:Identifier/@{any}
>>> Line 390-392 Strike the description of 
>>> wsrm:CreateSequenceResponse/wsrm:Expires/@{any}
>>>
>>>
>>> CloseSequence exemplar
>>> Line 455 Strike the ellipsis from wsrm:Identifier
>>>
>>> Descriptive text
>>> Line 466-468 Strike the description of 
>>> wsrm:CloseSequence/wsrm:Identifier/@{any}
>>>
>>>
>>> CloseSequenceResponse exemplar
>>> Line 480 Strike the ellipsis from wsrm:Identifier
>>>
>>> Descriptive text
>>> Line 490-492 Strike the description of 
>>> wsrm:CloseSequenceResponse/wsrm:Identifier/@{any}
>>>
>>>
>>> TerminateSequence exemplar
>>> Line 509 Strike the ellipsis from wsrm:Identifier
>>>
>>> Descriptive text
>>> Line 522-524 Strike the description of 
>>> wsrm:TerminateSequence/wsrm:Identifier/@{any}
>>>
>>>
>>> TerminateSequenceResponse exemplar
>>> Line 536 Strike the ellipsis from wsrm:Identifier
>>>
>>> Descriptive text
>>> Line 547-549 Strike the description of 
>>> wsrm:TerminateSequenceResponse/wsrm:Identifier/@{any}
>>>
>>>
>>> Sequence exemplar
>>> Line 569 Strike the ellipsis from wsrm:Identifier
>>>
>>> Descriptive text
>>> Line 585-587 Strike the description of 
>>> wsrm:Sequence/wsrm:Identifier/@{any}
>>>
>>>
>>> AckRequested exemplar
>>> Line 621 Strike the ellipsis from wsrm:Identifier
>>>
>>> Descriptive text
>>> Line 630-632 Strike the description of wsrm:AckRequested 
>>> /wsrm:Identifier/@{any}
>>>
>>>
>>> SequenceAcknowledgement exemplar
>>> Line 659 Strike the ellipsis from wsrm:Identifier
>>>
>>> Descriptive text
>>> Line 678-680 Strike the description of 
>>> wsrm:SequenceAcknowledgement/wsrm:Identifier/@{any}
>>> Lines 696 - 717 The exemplar has the children in the order None,
>>>       
> Final, 
>   
>>> Nack; but the detail has Final, Nack, None. Reorder the detail to
>>>       
> follow 
>   
>>> the order that the elements are introduced in the exemplar.
>>>
>>>
>>> SequenceFault exemplar
>>> Line 915. I believe the intent is to allows attributes as well as
>>>       
> elements 
>   
>>> here, so add another ellipsis to the exemplar. The corresponding 
>>> description is already there.
>>>
>>> Fault detail sections:
>>> Line 948: Delete another ellipsis from a wsrm:Identifier element 
>>> Line 958: Delete another ellipsis from a wsrm:Identifier element 
>>> Line 975: Delete another ellipsis from a wsrm:Identifier element 
>>> Line 994: Delete another ellipsis from a wsrm:Identifier element
>>>
>>> Line 967: This exemplar reuses the SequenceAcknowledgement type, so
>>>       
> the 
>   
>>> use of the ellipsis here is a bit misleading. Perhaps better to 
>>> write
>>>       
> the 
>   
>>> exemplar as the following (the type name should be in italics).
>>> "<wsrm:SequenceAcknowledgement> wsrm:SequenceAcknowledgementType 
>>> </wsrmSequenceAcknowledgement>"
>>> I'm not sure if we can use the type name here as the schema 
>>> definition
>>>       
> of 
>   
>>> the SequenceAcknowledgement element uses a anonymous complex type...
>>>       
>
> but I 
>   
>>> think the meaning is clear, and we could fix the schema.
>>>
>>> Comments?
>>>
>>> Thanks,
>>>
>>> Matt
>>>