OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: New proposed issues for Aug 10th call


All new proposed issues are attached since we still do not have archives. I would suggest that as these are all editorial we could possibly accept them all as one issue for the issue list to process rather than taking each individually. We could of course separate out any from such a grouping that did need discussion.

 

Propoes-01 location of normative XSD

 

Propoes-02 runon sentence in section 2

 

Propoes-03 editorial def'n of RMS and RMD

 

Propoes-04 clarify second bullet in Protocol Invariants

 

Propoes-05 RM Protocol Elements dives right into extensibility discussion, no intro

 

Propoes-06 use of capitalization for defined terms

 

Propoes-07 Inconsistent use of single and double quotes for values

 

Propoes-08 WS-RX Public Review

 

Propoes-09 Text describing extensibility syntax in WS-RM needed in WS-RM Policy

 

Propoes-10 Missing period on line 347 of WS-RM

 

Propoes-11 Weird gap on page 21

--- Begin Message ---
Title: editorial RM Protocol Elements dives right into extensibility discussion, no intro

Description:

Section 3 seems to jump right in with a note to implementers, without at all introducing what the RM protocol
elements are, are for, etc.

It starts out, on line 265 (CD4 draft):
        The following protocol elements define extensibility points at various places. Implementations MAY add
        child elements and/or attributes at the indicated extension points but MUST NOT contradict the semantics
        of the parent and/or owner, respectively. If a receiver does not recognize an extension, the receiver
        SHOULD ignore the extension.

        ...

Target: spec

Type: editorial

Proposal:

It would seem to me that the content of section 3 is really separate sub-sections that deals specifically with
extensibility considerations, composition, etc. I would think that the spec would be better off if these were called out in their own
subsections, and some introductory text were provided, that explains what is in the sub-sections that follow.

Thus, I think that the following would do the trick:

3 RM Protocol Elements

The following sub-sections define the various RM protocol elements, and prescribe their usage by a conformant
implementation.

3.1 Considerations on the Use of Extensibility Points

        (first para of current section 3)

3.2 Considerations on the Use of "Piggy-backing"

        (2ndpara of current section 3)

3.3 Composition with WS-Addressing

        (remainder of section 3 prose)

and renumber sub-sections 3.1 through 3.8 accordingly.

Cheers,

Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295
--- End Message ---
--- Begin Message ---
Title:  editorial clarify second bullet in Protocol Invariants

Description:

the second bullet, on line 219 of CD4 draft, could be clearer, and use the defined
terms appropriately.

target: spec

type: editorial

Proposal:

Change:

line 219: Within every acknowledgement it issues, the RM Destination MUST include one or more
acknowledgement ranges that contain the message number of every message accepted by the RM
Destination. The RM Destination MUST exclude the message numbers of any messages it has not
accepted.

to:

line 219: Within every Acknowledgement Message it issues, the RM Destination MUST include one or more
<AcknowledgementRange> child elements that contain, in their collective ranges, the message numbers of every message
accepted by the RM Destination. The RM Destination MUST exclude, in the <AcknowledgementRange> elements,
the message numbers of any messages it has not accepted.

Cheers,

Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295
--- End Message ---
--- Begin Message ---
Title: editorial def'n of RMS and RMD

Description:

the definitions of RMS and RMD could be clarified. Also, the term Send should be defined in
a similar manner to Deliver.

Target: spec

Type: editorial

Proposal:

Change:

line 195: RM Destination: For any one reliably sent message the endpoint that receives the message.
line 197: RM Source: The endpoint that transmits the message.
line 198: Send: The act of submitting a message to the RM Source for reliable transfer.

To:

line 195: RM Destination: The endpoint that receives messages transmitted reliably from an RM Source.
line 197: RM Source: The endpoint that transmits messages reliably to an RM Destination.
line 198: Send: The act of transferring a message from the Application Source to the RM Source for reliable transfer.

Cheers,

Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295
--- End Message ---
--- Begin Message ---
Title: runon sentence in section 2

Description:

The following sentence at line of CD4 draft  is what most would consider to be a run-on sentence.

        The WS-ReliableMessaging specification defines an interoperable protocol that requires a Reliable
        Messaging (RM) Source and Reliable Messaging Destination to ensure that each message transmitted by
        the RM Source is accepted by an RM Destination, or barring acceptance, that an RM Source can, except
        in the most extreme circumstances, accurately determine the disposition of each message transmitted as
        perceived by the RM Destination, so as to resolve any in-doubt status regarding receipt of the messages
        transmitted.

Target: spec

Type: editorial

Proposal:

Replace the sentence starting on line of CD4 draft with the following:

The WS-ReliableMessaging specification defines an interoperable protocol that enables a Reliable
Messaging (RM) Source to accurately determine the disposition of each message it transmits as
perceived by the RM Destination, so as to allow it to resolve any in-doubt status regarding receipt of the messages
transmitted. The protocol also enables an RM Destination to efficiently determine which of those messages it receives
have been previously received, enabling it to filter out duplicate message transmissions caused by the retransmission,
by the RM Source, of perceived unacknowledged messages.. It also enables an RM Destination to deliver the messages
it receives to the Application Destination in the order in which they were sent by an Application Source, in the event that they
are received out of order.

Cheers,

Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295
--- End Message ---
--- Begin Message ---
All,

A minor editorial issue for the CD4 draft.

Title: location of normative XSD

Descrpiption:

Section 1.2 adds the following text to indicate the location of the normative XSD
for the spec.

        The normative schema for WS-ReliableMessaging can be found at:
                http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-schema-200608.xsd

I think that we should indicate that the namespace URI resolves to a RDDL document that
provides a link to the normative version of the schema.

My reasoning is that I believe it possible that we might address errata, etc. without requiring a namespace
name change, and yet need to post a different version of the schema and update the RDDL document
to either change the link to the normative schema or add a link to the version that addresses errata.

Target: spec

Type: editorial

Proposal:

Replace the text above (line 144 in the CD4 draft) with the following:

        The normative schema for WS-ReliableMessaging can be found linked from the
        namespace document that is located at the namespace URI:
                http://docs.oasis-open.org/ws-rx/wsrm/200608

Cheers,

Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295
--- End Message ---
--- Begin Message ---
Title:

Description:

In the spec, there are a number of cases where defined terms are used in their un-capitalized form. This makes it
difficult to determine just when a word is used as a defined term or when it is being used in the conversational sense.

As an example, in CD4 draft, starting at line 250, it reads:

        The RM Source will expect to receive acknowledgements from the RM Destination during the course of a
        message exchange at occasions described in Section 3 below. Should an acknowledgement not be
        received in a timely fashion, the RM Source MUST re-transmit the message since either the message or
        the associated acknowledgement might have been lost.

Is the use of "acknowledgements" intended to be the defined term? Hard to tell. Also, is it "acknowledgements"
or should it more correctly be "Acknowledgement Messages"?

Target: spec

Type: editorial

proposal:

When using defined terms, use the Capitalized form, or choose a different font styling, such as
italics so as to make it clear when a defined term is being used in the formal sense.

Cheers,

Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295
--- End Message ---
--- Begin Message ---

Title:  Inconsistent use of single and double quotes for values

Description:
The spec is inconsistent in its use of quotes for values of elements and attributes. In some cases it use a single quote such as ‘PT0S’ to state a potential value for Expires on line 359. In other cases double quotes as in stating the possible values of IncompleteSequenceBehavior on lines 368, 371 and 373.

Target: spec

Type: editorial

proposal:

Pick one and apply throughout spec.

--- End Message ---
--- Begin Message ---
Title: [ws-rx] FW: [Fwd: WS-RX Public Review]

In preparation for the PR, the OASIS staff has suggested the following
update to our specifications. This is a boiler-plate, pro forma change
and I would not expect any objections to this as such.  Nevertheless, we
could talk about this on tomorrow's call and decide to apply this change
for the next revision (due after tomorrow's call), which would be a PR
candidate as per our current plans.

Marc, could you please include Mary's suggestion in your list of new
issues.

Kudos to our editors team that the OASIS staff could not raise any major
red flags.

-- Sanjay

-----Original Message-----
From: Mary McRae [mailto:marypmcrae@gmail.com]
Sent: Wednesday, Aug 09, 2006 16:19 PM
To: Patil, Sanjay; mary.mcrae@oasis-open.org; 'Paul Fremantle'
Subject: RE: [Fwd: WS-RX Public Review]

Hi Patil,

  It looks fine, except for the status section. Please update the text
to match
the template - particularly noting how to submit comments - as shown
below:

------------

 This document was last revised or approved by the [TC name] on the
above date.
The level of approval is also listed above. Check the current location
noted
above for possible later revisions of this document. This document is
updated
periodically on no particular schedule.

Technical Committee members should send comments on this specification
to the
Technical Committee's email list. Others should send comments to the
Technical
Committee by using the "Send A Comment" button on the Technical
Committee's web
page at www.oasis-open.org/committees/[specific-location].

For information on whether any patents have been disclosed that may be
essential
to implementing this specification, and any offers of patent licensing
terms,
please refer to the Intellectual Property Rights section of the
Technical
Committee web page ( www.oasis-open.org/committees/[specific-location]/
ipr.php.

The non-normative errata page for this specification is located at
www.oasis-open.org/committees/[specific-location].

------------

Other than that it looks good to go. The good news is that both comment
lists
and the members announce list appear to be functioning properly (other
than
archives) so I can actually make the announcement once the documents are
approved and submitted.

Regards,

Mary

> -----Original Message-----
> From: Patil, Sanjay [mailto:sanjay.patil@sap.com]
> Sent: Wednesday, August 09, 2006 6:09 PM
> To: mary.mcrae@oasis-open.org; Paul Fremantle
> Subject: RE: [Fwd: WS-RX Public Review]
>
>
> Hi Mary,
>
> The candidate PR drafts are at
> http://www.oasis-open.org/committees/download.php/19583/WSRM-CD4.zip.
> This package does not yet include an HTML version and our
> editors team is currently working on it. Meanwhile, could you
> please take a look at the other formats (PDF, ODT) and let us
> know if they look alright. It will be great to get your
> feedback by tomorrow (8/10) before 1 PM Pacific, since that's
> when our TC meets and we plan to finalize the content of PR
> drafts during this meeting. Sorry for the short notice.
>
> -- Sanjay
>
> > -----Original Message-----
> > From: Mary McRae [mailto:mary.mcrae@oasis-open.org]
> > Sent: Thursday, Aug 03, 2006 14:06 PM
> > To: 'Paul Fremantle'; Patil, Sanjay
> > Subject: RE: [Fwd: WS-RX Public Review]
> >
> > Hi Paul,
> >
> >   Hopefully the comment lists will be functional in the next day or
> > two; there's no need to *set up* anything as this was done
> for all TCs
> > at the same time. The most important thing is to make sure the
> > specification is in the proper format - please check the
> templates at
> > docs.oasis-open.org/templates/ and make sure that you have the
> > appropriate cover page boilerplate text, notice, etc.
> >
> >   When you're ready to make the formal submission, note
> that I'll need
> > the spec in three formats: editable source, HTML, and PDF.
> >
> >   That should be it, but please feel free to send me a
> pointer to the
> > spec and I'll do a quick check before you produce all of
> the versions
> > and point out anything that should be changed.
> >
> > Mary
> >
> >
> > >
> > > -------- Original Message --------
> > > Subject:  WS-RX Public Review
> > > Date:     Mon, 31 Jul 2006 23:05:45 +0100
> > > From:     Paul Fremantle <paul@wso2.com>
> > > To:       Mary McRae <mary.mcrae@oasis-open.org>, "Patil, Sanjay"
> > > <sanjay.patil@sap.com>
> > >
> > >
> > >
> > > Mary
> > >
> > > The WS-RX TC has now closed all substantive issues, and we are
> > > aiming to have a vote for CD and PR on the call 8/17. We
> would like
> > > to be ahead of the game in terms of getting
> > ready for that.
> > >
> > > Our issues editor is starting to prepare for capturing any raised
> > > issues. I believe we need to setup the comments list
> using the new
> > > comments facility. And we need to inform you.
> > > Have I missed anything?
> > >
> > > What else can we do to be aforehand in our preparations?
> > >
> > > Yours,
> > > Paul
> > >
> > > --
> > >
> > > Paul Fremantle
> > > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> > >
> > > http://feeds.feedburner.com/bloglines/pzf
> > > paul@wso2.com
> > >
> > > "Oxygenating the Web Service Platform", www.wso2.com
> > >
> > >
> > >
> > >
> > > --
> > >
> > > Paul Fremantle
> > > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> > >
> > > http://feeds.feedburner.com/bloglines/pzf
> > > paul@wso2.com
> > >
> > > "Oxygenating the Web Service Platform", www.wso2.com
> > >
> >
> >

--- End Message ---
--- Begin Message ---

Title:  Weird gap on page 21

Description:
There is a weird gap between lines 748 and 749 on page 21.

Target: spec

Type: editorial

proposal:

Get rid of the gap.

 

--- End Message ---
--- Begin Message ---

Title:  Missing period on line 347 of WS-RM

Description:
Missing period on line 347 of WS-RM after “WS-Addressing)”

Target: spec

Type: editorial

proposal:

Add the period.

 

--- End Message ---
--- Begin Message ---

Title:  Text describing extensibility syntax in WS-RM needed in WS-RM Policy

Description:
The text added to WS-RM on lines 127 – 135 explaining the extensibility syntax is not present in WS-RM Policy.

Target: spec

Type: editorial

proposal:

Add lines 127- 135 of WS-RM to WS-RM Policy after line 75.

 

--- End Message ---


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]