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


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

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

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.


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

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