New Issue: Extensibility (or not) of the Protocol Elements.

[Matthew Lovett <MLOVETT@uk.ibm.com>]

Title: Extensibility (or not) of the Protocol Elements.

Description:
Currently there is some inconsistency when it come to extensions. The 
exemplars generally have attribute wildcards for simply typed elements, 
and both attribute and element wildcards for elements with complex types. 
However that isn't always the case, and the corresponding descriptions 
don't always match the exemplars.
We should adopt a consistent approach to extensions, unless there are 
compelling reasons to deviate from the convention.

Justification:
Our spec should be as consistent as possible.

Target: core
Type: design

Proposal:

Section 3.1, Sequence Creation. Line 289: Insert a description for 
/wsrm:CreateSequence/wsrm:AcksTo/@{any}. (It is in the exemplar, but not 
the corresponding text.)

Section 3.1, Sequence Creation, Line 266: Insert an attribute wildcard 
into wsrm:CreateSequence/wsrm:Offer/wsrm:Endpoint. Insert matching detail 
around line 317.

Section 3.1 Sequence Creation, Line 268: Insert an attribute wildcard into 
wsrm:CreateSequence/wsrm:Offer/wsrm:IncompleteSequenceBehavior. Insert 
matching detail around line 341.

Section 3.1 Sequence Creation, Line 325 - 330. Normally the wildcard 
descriptions follow the children that we define, so this should move after 
the IncompleteSequenceBehavior description.

Section 3.1 Sequence Creation, Line 342. /wsrm:CreateSequence/{any} - it 
may just be my printer, but this seems to be in the wrong font.

Section 3.1 Sequence Creation, Line 355. The exemplar is missing a 
attribute wildcard on the Expires element, though it appears in the 
descriptive text.

Section 3.1 Sequence Creation, Line 384 - 394. This is a repeat of the 
IncompleteSequenceBehavior text, but it wasn't updated when we resolved 
i129. Perhaps it's simpler to refer back to the earlier text, rather than 
duplicate it?

Section 3.1 Sequence Creation, Line 356. Insert an attribute wildcard into 
wsrm:CreateSequenceResponse/wsrm:IncompleteSequenceBehavior. Insert 
matching detail around line 394.

Section 3.1 Sequence Creation, Line 409. Insert text to describe the 
wsrm:createSequenceResponse/wsrm:Accept/wsrm:AcksTo/@{any}. (It is in the 
exemplar, but not the corresponding text.)

Section 3.4 Sequences, Line 560. Insert an attribute wildcard into 
wsrm:Sequence/wsrm:MessageNumber. Insert matching detail at line 584.

Section 3.6 Sequence Acknowledgement. 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.

Section 3.6 Sequence Acknowledgement, Line 651. Add an attribute wildcard 
to wsrm:SequenceAcknowledgement/wsrm:None. Insert matching detail.

Section 3.6 Sequence Acknowledgement, Line 652. Add an attribute wildcard 
to wsrm:SequenceAcknowledgement/wsrm:Final. Insert matching detail.

Section 3.6 Sequence Acknowledgement, Line 653. Add an attribute wildcard 
to wsrm:SequenceAcknowledgement/wsrm:Nack. Insert matching detail.

Section 3.7 MakeConnection, Line 751. Add an attribute wildcard to 
wsrm:MakeConnection/wsrm:Identifier. Insert matching detail.

Section 3.7 MakeConnection, Line 752. Add an attribute wildcard to 
wsrm:MakeConnection/wsrm:Address. Insert matching detail.

I also noticed some others in the Faults sections - these were not in my 
earlier note to the list.

Section 4.1 SequenceFault Element, Line 902. Add an attribute wildcard to 
wsrm:SequenceFault/wsrm:FaultCode. Insert matching detail.

Section 4.1 SequenceFault Element, Line 903. Add an attribute wildcard to 
wsrm:SequenceFault/wsrm:Detail. The detail is already there, but not in 
the exemplar.

Section 4.5 Message Number Rollover, Line 964. Add an attribute wildcard 
to the wsrm:MaxMessageNumber element

Section 4.9 Unsupported Selection, Line 1001. Add an attribute wildcard to 
the wsrm:UnsupportedElement element

Related issues: 
None

Thanks,

Matt