[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] Comments on Editors WSRM #9
Peter/Matt,
There is a lot of useful feedback in this thread. Could you please try
to identify and raise potential new issues before this week's call.
-- Sanjay
> -----Original Message-----
> From: Peter Niblett [mailto:peter_niblett@uk.ibm.com]
> Sent: Wednesday, Jun 28, 2006 3:45 AM
> To: Matthew Lovett
> Cc: ws-rx@lists.oasis-open.org
> Subject: Re: [ws-rx] Comments on Editors WSRM #9
>
> 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
>
>
>
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]