+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