XML | XML Schema

• 1 Background: process document on last call
• 2 Procedure
  • 2.1 Initial capture
  • 2.2 Initial classification
  • 2.3 Acknowledgement
  • 2.4 WG action
  • 2.5 Advocacy teams
  • 2.6 Summary

This document describes the procedures to be used by the W3C XML Schema Working Group in handling Last-Call comments.

1. Background: process document on last call

The W3C process document describes Last Call this way:

6.2.2 Last Call Working Draft

Requirements for Entrance

The Working Group has resolved all known issues and the Chair issues a Last Call.

Associated activities

The Working Group solicits and responds to review and comments from W3C Working and Coordination Groups and external sources.

Duration

The Duration is specified by the Chair. A Last Call typically lasts three weeks. The Chair may request a longer period may if the document is complex or has significant external dependencies.

Next State

Upon Director approval, a Working Draft is advanced to Candidate Recommendation. Otherwise it is sent back to the Working Group for further work.

A Last Call Working Draft is a special instance of a Working Draft that is considered by the Working Group to meet the requirements of its charter. The Working Group publishes a Last Call Working Draft in order to solicit review from at least all dependent Working Groups (copying Chairs of known dependent groups). External feedback is also encouraged. A last call announcement must recapitulate known dependencies. It must also state the deadline for comments (e.g., three to four weeks is issued). The Last Call Working Draft must be a public document.

To ensure the proper integration of a specification in the international community, documents must, from this point on in the Recommendation process, contain a statement about how the technology relates to existing international standards and to relevant activities being pursued by other organizations.

Once the last call period has ended, all issues raised during the last call period resolved, and the Working Draft modified if necessary, the Working Group may request that the Director submit the document for review by the Advisory Committee as a Candidate Recommendation. It is possible that comments will cause substantive changes that require that the document return to Working Draft status before being advanced to Last Call again.

The next section describes the Requirements for Entrance for Candidate Recommendation this way:

Requirements for Entrance

The Director must be satisfied that the Working Draft has successfully completed the Last Call with all comments resolved and that the Working Group has prepared an adequate implementation report.

2. Procedure

One key responsibility of the WG during Last Call is thus to ensure that all Last Call comments are resolved to the satisfaction of the commentator, or in the cases where we cannot satisfy the commentator at least ensure that the comments and our responses are documented fully.

The chairs propose a five-step procedure for dealing with last-call comments.

2.1 Initial capture

First, during the Last Call comment period, the chairs will review the IG and comments list, and add items to the Last-Call Issues document for each point raised. (I have started on this process, but have not yet gotten up to date with the lists.)

2.2 Initial classification

Second, the chairs will propose a classification of the issue or comment as:

• A a request for functionality which already exists (or a question about how to use existing functionality); the appropriate response to such an item is to explain how to use the existing functionality
• B a request for functionality which is, strictly speaking, outside the scope of XML 1.0; obvious cases of this include functionality which goes beyond our chartre, but other cases may be less clearcut. The appropriate response to such an item is to explain that the feature is out of scope, and perhaps explain why.
• C a bug in the spec, with an obvious fix (typos go here, but other things might go here, too)
• D a request for functionality or comment which the WG is going to need to consider in some detail and which might lead to revisions in the spec

One purpose of this classification is to allow us to get started early on items which don't need to wait until the end of the comment period.

2.3 Acknowledgement

Third, the chairs will send a formulaic response to the commentator acknowledging receipt of the comment and inviting the commentator to check the issues list to make sure we have understood and properly paraphrased the point at issue.

2.4 WG action

Fourth, the WG will consider and classify the comments (by accepting or changing the chairs' proposed classification). At this point, we propose to distribute the responsibility for action among the WG members.

• Each A-comment will be assigned a respondent, who will draft a reply explaining how to use the existing functionality to do what the commentator wishes.
• Each B-comment will be assigned to the chairs, who will draft a reply explaining the scope of XML Schema.
• Each C-comment will be assigned to the appropriate editor, who will implement the obvious fix and write the commentator to confirm that the fix has been made.
• Each D-comment will be assigned to an 'advocacy team' consisting of one to three WG members.

The draft responses to A- and B-comments (and C-comments?) will be reviewed and approved by the WG before being sent to the commentator and recorded in the disposition-of-comments document.

2.5 Advocacy teams

The response to D-comments will require more elaborate preparation. The advocacy team is responsible for:

• understanding the issue (discussing it with the commentator if necessary), and revising the description of the issue in the issues document if necessary; if necessary, the advocacy team will serve as 'translators' between the WG and the commentator.
• documenting the relevant design decisions, i.e. identifying the decisions which will or might be overturned if we do what the commentator wants us to do. This can be fairly lightweight. It will go into the description of the issue in the issues list; its purpose is to allow the WG to remember, and others to discover, the relevant design decisions.
• proposing alternatives which might (or might not) resolve the issue, and discussing these with the commentator; at the very least we need to know which alternatives the commentator believes will be acceptable resolutions of the issue.
• acting as an advocate for the commentator in WG discussions; it's handy if the advocate actually agrees with the commentator, but even if no one agrees, every commentator should have an advocate in WG discussion.
• writing up the disposition of the comment, unless the task is assigned to someone else.

The WG may choose to discuss D-comments before the end of the comment period, but we will not attempt to resolve D-comments before the comment period is over and we have a finite set of comments to work on.

2.6 Summary

Each comment should be resolved, either by deciding that no change will be made to the spec (with an explanation of why) or by making an appropriate change to the spec. Each resolution will be documented, and the commentator will be notified of the resolution. The list of all comments raised, and their disposition, will be made public as part of the WG's decision record.