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

[Matthew Lovett <MLOVETT@uk.ibm.com>]

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