Re: [ws-rx] Comments on Editors WSRM #9

[Peter Niblett <peter_niblett@uk.ibm.com>]

Looking at this I noticed that the {any} and @{any} syntax used in the
XPATHs is not defined anywhere. It isn't standard XPATH, so it should be
defined in section 1.1 Notational Conventions.

It's also a little strange that we use ellipsis (...) in the pseudo-schema,
but {any} or @{any} in the corresponding XPATHs.

Peter Niblett




                                                                           
             Matthew                                                       
             Lovett/UK/IBM@IBM                                             
             GB                                                         To 
                                       ws-rx@lists.oasis-open.org          
             27/06/2006 13:02                                           cc 
                                                                           
                                                                   Subject 
                                       [ws-rx] Comments on Editors WSRM #9 
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Hi all,

I tried to take a fine tooth comb to one of the editor's drafts, I
happened to pick #9. Many of these comments are nits, but as they could
impact the schema & exemplars I guess we might need an issue to record
them formally... anyway, here we go:

1) Line 27-29, within the Abstract. The final sentence reads rather oddly:
"WS-ReliableMessaging is a building block that is used in conjunction with
other specifications and application-specific protocols to accommodate a
wide variety of *protocols* related to the operation of distributed Web
services."

I don't think that the repetition of 'protocol' helps here. I think
'requirements' would be a better substitute, or perhaps 'scenarios'.
Anyone swallowed a dictionary recently? 'capabilities'?



2) Extensibility (or not) of the Protocol Elements.
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. Here's some detail:

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.

If we can get some agreement on these then I'll take a look at the schema
to check it follows the text - but let's agree on mainline text first.

Thanks

Matt