WSN TC Process

 

Introduction

 

This document describes the issue resolution process and document naming conventions that are being used by the OASIS WS-Notification Technical committee. These are based on the approach agreed at the Face-to-Face meeting of the TC that was held in London on 29th and 30th July 2004.

 

The goals of the process are to define:

 

  1. The mechanism for tracking the progress of specification issues, and identifying the current state of each issue.
  2. The means of recording the TCs decisions.
  3. The process which the TC uses to review changes to the draft specifications
  4. A versioning scheme that distinguishes between work-in-progress drafts and consistent levels of the specifications, and that reduces the amount of work required to get the cross-references between specifications correct.

 

Issue process

 

A new issue may be proposed by any TC member. A proposal for a new issue is first discussed at a TC meeting or call.

 

The purpose of this initial discussion is to determine whether there is general agreement among the TC members that

  • the issue addresses questions that are within the TC’s scope
  • the issue is not a duplicate of an existing open issue
  • the TC members are happy that we should consider the issue further

It is also an opportunity to clarify the wording of the issue and – if the raiser agrees – to narrow or widen its scope.

 

If the TC does accepts the proposed issue, it is added as an Open Issue to the WSN_IssuesList, maintained by Sanjay Patil. An up to date copy of this list is kept in the Documents section of the TC web site.

 

Each issue in this list is categorized into one of four states.

 

  • Open
  • Open-approach agreed – TC  agreed on approach, but change not yet made/verified
  • Resolved - once the change has been made to an editor's draft, and has been reviewed by a third party
  • Closed – the TC has decided to take no action to resolve the issue OR the resolution has appeared in a draft that has been approved by a vote of the TC.

 

Issues progress through these states as follows

 

  1. The TC works on open issues at its meeting and calls. The TC may decide to close an issue, if it so chooses. For example it may simply decide not to proceed with the issue, or it may decide that it is superseded by one or more other issues. If so the issue is marked as closed in the IssuesLists – with a brief description of why and when this happened.
  2. Alternatively the TC may decide on the approach it wishes to take to resolve the issue – usually this will involve a change to one or more of the draft specifications, In this case the issue is marked as “Open – approach agreed”. The approach to be taken is recorded in the issues list. This should give clear instructions to the editors of the specifications concerned; however it does not include precise wording changes.
  3. The specification Editors periodically apply these changes to the relevant specification documents, to create “Editor’s Working Drafts”. Editors post these drafts to the TC website – with a list of the issues that they have addressed. When they do so they ask another TC member to verify the changes - in addition all TC members are free to review and comment on the changes at this stage. Assuming there are no adverse criticisms, the issue then moves to Resolved state
  4. When the TC deems it appropriate, it produces “Stable Working Drafts” of the various specifications. The editors of each specification produce candidate stable working drafts, and the whole TC reviews them for consistency within themselves and with the other specifications. This may process may result in some reworking of the resolved issues. Once the TC has approved a stable working draft, the issues Resolved in that that draft move to Closed state.

 

Stable Working Drafts

 

A Stable working draft is a stepping stone to Committee draft, and represents a level of a specification which the TC feels is consistent, and which – though still subject to change - could be used as a basis for a prototype implementation.

 

Stable working drafts will be named using the following scheme:

 

WS-XXX 1.3 Working Draft nn

 

where XXX is the name of the specification and nn is 01 for the first stable working draft, 02 for the second and so on. We will stick with 1.3 until we have produced our first Committee drafts.

 

We will release stable working drafts of all the WS-N specifications as a matched set and all members of the set have the same draft number, and are released in the same month and year. Prior to releasing a stable working draft the TC determines which level of other specifications (e.g. WS RF specifications) it is going to reference – this is to ensure consistency between the various WSN specifications.

 

When producing a stable working draft, the editors need to check that the WSDL and XSD and the various entries in the document itself have been updated to match the new level and that they conform to the patterns shown in the following table:

 

 

 

Title:

Web Services XXX 1.3 (WS-XXX)

Working Draft nn, dd month yyyy

Document Identifier:

wsn-WS-XXX-1.3-draft-nn

Location/Filename:

http://docs.oasis-open.org/wsn/yyyy/mm/wsn-WS-XXX-1.3-draft-nn.pdf

References to other WSN specs:

http://docs.oasis-open.org/wsn/yyyy/mm/wsn-WS-XXX-1.3-draft-nn.pdf

WSN-defined Namespaces:

http://docs.oasis-open.org/wsn/yyyy/mm/wsn-WS-XXX-1.3-draft-nn.xsd

http://docs.oasis-open.org/wsn/yyyy/mm/wsn-WS-XXX-1.3-draft-nn.wsdl

References to and Namespaces of other specifications:

As agreed for this working draft release.

 

In this table nn, dd, month, mm, yyyy are filled in with the actual values for the release. Note that the yyyy and mm in the URIs are identical for all the specs.

 

In addition the editors will include the following sentence in the Status section at the start of each specification document:

 

On [date], this document was approved by the OASIS WS-Notification Technical

Committee for publication so that users of the specification have a stable draft version available until the TC publishes a Committee Draft. Send comments to the editors.

 

 

The WSN TC home page includes easy-to-find links to the latest stable working drafts of all the WSN specifications and associated XSD/WSDL files.

 

Editor’s Working Drafts

 

Editor’s working drafts interim drafts released between stable working drafts. Unlike stable working drafts, we do not coordinate releases across the varying specifications, so between two stable working drafts we may have, for example, 4 editor’s working drafts of one specification, but only one of another.

 

Editor’s working drafts follow a similar numbering scheme to Stable working drafts, but with the following differences:

 

  1. The document identifier is the identifier of the NEXT stable working draft, but with an alphabetic suffix. For example, having released 1.3 stable working draft 01, the next two WS-BaseNotification drafts would be

·        WS-BaseNotification 1.3 Working Draft 02a

·        WS-BaseNotification 1.3 Working Draft 02b

 

  1. The XSD and WSDL Namespace URIs include the draft number for the NEXT stable working draft, but do not include a suffix. In addition they contain a literal “yyyy/mm” for their date – not a filled in version like 2004/11. So all the 02x working drafts of WS-BaseNotification will use the same URI for wsnt:   

 

http://docs.oasis-open.org/wsn/yyyy/mm/wsn-WS-BaseNotification-1.3-draft-02.xsd

 

  1. The editor’s working drafts do not include the “This document was approved” sentence.