[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue i147 - alternative proposal
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]