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:
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295
Matthew Lovett <> 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
