[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]