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. It was updated a the Face-To-Face meeting held in Palo Alto on 18th-20th May 2005 as a result of changes to the OASIS TC process.

 

Revised 6 June 2005, with new format for specification names and identifiers.

 

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 “Committee Drafts” of the various specifications. The editors of each specification produce candidate committee 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 committee draft, the issues Resolved in that that draft move to Closed state.

 

Committee Drafts

 

A Committee draft is a stepping stone to a Public Review 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.

 

Committee drafts will be named using the following scheme:

 

WS-BaseNotificationXXX 1.3 Committee Draft nn

WS-BrokeredNotification 1.3 Committee Draft nn

WS-Topics 1.3 Committee Draft nn

 

 

 

where XXX is the name of the specification and nn is 01 for the first committee draft, 02 for the second and so on.

 

The TC will release committee drafts of all the WSN specifications as a matched set . All members of the set have the same draft number, and are released in the same month and year. Prior to releasing a committee 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 committee 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 Base NotificationXXX 1.3 (WS-BaseNotificationXXX)

Committee Draft nn, dd month yyyy

Web Services Brokered Notification 1.3 (WS-BrokeredNotification)

Committee Draft nn, dd month yyyy

Web Services Topics 1.3 (WS-Topics)

Committee Draft nn, dd month yyyy

Document Identifier:

wsn-ws_base_notification-1.3-cd-nn

wsn-ws_brokered_notification-1.3-cd-nn

wsn-ws_topics-1.3-cd-nn

Location/Filename:

http://docs.oasis-open.org/wsn/wsn-ws_base_notification-1.3-cd-nn.pdf

http://docs.oasis-open.org/wsn/wsn-ws_brokered_notification-1.3-cd-nn.pdf

http://docs.oasis-open.org/wsn/wsn-ws_topics-1.3-cd-nn.pdf

References to other WSN specs:

http://docs.oasis-open.org/wsn/wsn-WS-XXX-1.3-cd-nn.pdfUse their location URLs

WSN-defined Namespaces for base notification:

http://docs.oasis-open.org/wsn/b-n

http://docs.oasis-open.org/wsn/bw-n

 

Namespaces for brokered notification

http://docs.oasis-open.org/wsn/br-n

http://docs.oasis-open.org/wsn/brw-n

 

Namespace for topics

http://docs.oasis-open.org/wsn/t-n

 

Action URIs

Formed from the relevant WSDL namespace URI, following WS-Addressing default mechanism

References to and Namespaces of other specifications:

As agreed for this committee draft release.

 

In this table XXX is filled in with the name of the specification (e.g. Topics) and nn, dd, month,  yyyy are filled in with the actual values for the release. The namespace n value is incremented if and only if the artefact has changed incompatibly from the previous version.

 

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

 

On [date], the OASIS WS-Notification Technical

Committee approved this document for publication as a Committee Draft. Committee members should send comments on this specification to the wsn@lists.oasis-open.org list.  Others may submit comments to the TC via the web form found on the TC's web page at http://www.oasis-open.org/committees/wsn. Click the button for "Send A Comment" at the top of the page. Submitted comments (for this work as well as other works of the TC) are publicly archived and can be viewed at http://lists.oasis-open.org/archives/wsn-comment/.

 

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 WSNRF TC web page (http://www.oasis-open.org/committees/wsn/).

 

 

Editor’s Working Drafts

 

Editor’s working drafts interim drafts released between committee drafts. Unlike committee drafts, we do not coordinate releases across the varying specifications, so between two committee 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 committee drafts, but with the following differences:

 

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

·        WS-BaseNotification 1.3 Committee Draft 02a

·        WS-BaseNotification 1.3 Committee Draft 02b

 

2.      The XSD and WSDL Namespace URIs follow the same scheme as that used in Committee Drafts e.g.:   

 

http://docs.oasis-open.org/wsn/b-n

 

The namespace n value is incremented if and only if the artefact has changed incompatibly from the previous version.

 

 

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