W3C

W3C <SpecName> PAS Explanatory Report

Status: April 2014 - Template to use with new W3C PAS proposals

Editor(s): Daniel Dardailler, Director of International Relations, W3C.

Nearby: W3C PAS Status . WS Package PAS . WCAG2 PAS . PAS Selection Process . PAS FAQ

This document: http://www.w3.org/2010/03/pas-er.html


Table Of Content:

1. Introduction

This document presents the W3C SpecName being submitted by W3C for JTC 1 PAS transposition into an ISO/IEC International Standard.

This W3C Recommendation is within scope of the W3C PAS Submitter's original application and is part of the Core Web technology stack that W3C is continually maintaining and evolving. The conditions for the recognition of W3C as a PAS Submitter have not changed since approval of W3C as a PAS Submitter.

@@DD: in the case it happens: W3C believes that this submission is not appropriate for assignment to any existing JTC 1 subcommittee, as this submission does not fall within one unique JTC 1 structure, and therefore requests that the JTC 1 Secretariat perform the duties normally assigned to a subcommittee secretariat. W3C notes that the JTC 1 Secretariat might use the expertise available in SC ....

The W3C/Spec specification URL, and first publication date, along with the final International Standards ISO/IEC title and number we are requesting, is:

Number Title URL
40xxx W3C SpecName http://www.w3.org/TR/..................................................

The remainder of this Introduction section addresses the strategic interests in Interoperability, and in Cultural and Linguistic Adaptability. Subsequent sections address the JTC 1 PAS criteria listed in the Document-Related Criteria (mapping to the section 7.4 in JTC 1 Standing Document on PAS).

1.1. Strategic values

Here we need to talk about enhanced interoperability brought by our work, e.g. what would be the situation without it, what level of interoperability it provides and doesn't provide.

We hope that an ISO/IEC approval of these specifications will help promote an even greater level of interoperability and a higher level of compliance to the same set of semantics.

These technologies are simple in their architecture, and their value is entirely in the interoperable global market of ICT service applications they help create.

As with all W3C technologies, the @@@ technology went through the review of our Internationalization activity.

In addition, our standard development process is open to all participants, regardless of cultural or linguistic origins, and as a result, today's @@@ technology provide a standard means of interoperating between different and independently designed software applications, running on a variety of platforms and/or frameworks, all independent of cultural or linguistic parameters.

Here we need to give a quick technical architecture tutorial explaining why we need these specs, what they each do, in which ways they make a coherent unit. N/A is only one spec is sent.

2. Document Related Criteria (7.4 in JTC 1 Standing Document on PAS)

Using the JTC 1 numbering below.

7.4.1 Quality

Within its scope the specification shall completely describe the functionality (in terms of interfaces, protocols, formats, etc) necessary for an implementation of the PAS. If it is based on a product, it shall include all the functionality necessary to achieve the stated level of compatibility or interoperability in a product independent manner.

7.4.1.1 Completeness

  1. How well are all interfaces specified?
  2. How easily can implementation take place without need of additional descriptions?
  3. What proof exists for successful implementations (e.g. availability of test results for media standards)?

The .... specifications being submitted have all followed the same W3C process and evolved in the same context, so the descriptions that follow are applicable to all of them.

One important resource, referenced several times below, can be used to judge the current quality of our specifications: it is the W3C QA Matrix, listing all our technical reports and the presence of validators, test suites, tutorials. See http://www.w3.org/QA/TheMatrix for live data.

In the rest of this document, examples will be extracted from various documents pointed by this QA Matrix, but the intent is not to duplicate it.

Our interfaces are defined in US English with semantics for terms imposed by various formal mechanisms, and we also provide specific authoring templates that help our groups raise the overall quality of their interface definitions, using the right normative referencing rules, wording for conformance sections, etc.

The specifications presented here describe data formats, and the rules for generating, exchanging, and processing messages using those formats.

They are self-sufficient in terms of compliant specifications and even though they do not mandate the scope of any particular implementation, they require that no implementation violates any mandatory requirement listed in their Conformance section.

These specific clauses rely on the detailed meaning of the adjective MUST/SHALL, SHOULD or MAY, as ISO specifications do (W3C always point at the IETF version of these definitions, RFC 2119).

See the next sections for details on test results, conformance criteria, etc.

7.4.1.2 Clarity

  1. What means are used to provide definitive descriptions beyond straight text?
  2. What tables, figures, and reference materials are used to remove ambiguity?
  3. What contextual material is provided to educate the reader?

These specifications mostly describe programmatic interfaces and are doing so using formal grammar languages such as SGML DTDs or XML Schema technologies, or BNF sometimes.

They include tables and call out their normative references as well as informative references in separate sections.

They each have tutorial or primers available free of charge on the W3C site.

7.4.1.3 Testability

The extent, use and availability of conformance/interoperability tests or means of implementation verification (e.g. availability of reference material for magnetic media) shall be described, as well as the provisions the specification has for testability.

The specification shall have had sufficient review over an extended time period to characterise it as being stable.

As detailed in the public W3C QA Matrix resource, these specifications have all received some level of test support, for which results should still be available. See http://www.w3.org/QA/TheMatrix for live data.

7.4.1.4 Stability

  1. How long has the specification existed, unchanged, since some form of verification (e.g. prototype testing, paper analysis, full interoperability tests) has been achieved?
  2. To what extent and for how long have products been implemented using the specification?
  3. What mechanisms are in place to track versions, fixes, and addenda?

These specifications have been released with their test materials, implementation reports and interop test results since before they were endorsed as W3C Recommendation, since the end of their Candidate Recommendation phase, at least.

Each W3C specifications maintains a Web page to track known errata to the Recommendation, with the date it was added to the errata page, a classification of the error (e.g., editorial, clarification, bug, known problem with the document itself), a short description of the problem and what part of the Recommendation is affected, any proposed corrections and whether those corrections would affect conformance of documents or software and any normative corrections.

W3C wrote a specific section on Errata Management in the W3C Process Document.

7.4.1.5 Availability

  1. Where is the specification available (e.g. one source, multinational locations, what types of distributors)?
  2. How long has the specification been available?
  3. Has the distribution been widespread or restricted? (describe situation)
  4. What are the costs associated with specification availability?

All the W3C specifications, including our W3C Recommendation track (highest mark for a W3C standards), are available for free download, without registration, on the W3C public Web site at the address: http://www.w3.org/standards/

There are also available translations for these specifications. Please check our live translation catalog for these specifications.

7.4.2 Consensus

The accompanying report shall describe the extent of (inter)national consensus that the document has already achieved.

7.4.2.1 Development Consensus

  1. Describe the process by which the specification was developed.
  2. Describe the process by which the specification was approved.
  3. What “levels” of approval have been obtained?

The W3C Process Document promotes the goals of quality and fairness in technical decisions by encouraging consensus, requiring reviews (by both Members and public) as part of the standard development process, obliging the WG to respond to all comments.

As explained in this foundational W3C document, Consensus is a core value of our community and to promote it, the W3C process requires its WG Chairs to ensure that groups consider all legitimate views and objections, and endeavor to resolve them, whether these views and objections are expressed by the active participants of the group or by others (e.g., another W3C group, a group in another organization, or the general public).

The W3C Process goes provides a simple definition for what Consensus means in our context, as a way to describe the level of support for a decision among a set of eligible individuals:

The chain of steps going from a Working Group draft to a final W3C Recommendation status, followed by all W3C specifications submitted through PAS, is described in the W3C PAS submitter status file.

Here's a picture that summarizes these steps, or maturity levels:

W3C Process steps

Each specification in the package has a Status section describing its origin, and the name of the W3C working group in charge of it at the time it was done.

It starts by saying:

Status of this Document

This document is a W3C Recommendation. It has been produced by the ... Working Group, which is part of the ... Activity.

As required by our process, when all the issues raised during the various review steps have been resolved, these specifications have reached the highest mark in the W3C process, W3C Recommendations.

7.4.2.2 Response to User Requirements

  1. How and when were user requirements considered and utilised?
  2. To what extent have users demonstrated satisfaction?

Most of the groups working on W3C specifications start by collecting their technical requirements in a separate documents. ..

7.4.2.3 Market Acceptance

  1. How widespread is the market acceptance today? Anticipated?
  2. What evidence is there of market acceptance in the literature?

The QA Matrix (at http://www.w3.org/QA/TheMatrix) provides pointers to the various Implementation reports for these specifications.

7.4.2.4 Credibility

  1. What is the extent and use of conformance tests or means of implementation verification?
  2. What provisions does the specification have for testability?

W3C doesn't run or is associated with any certification program for ...

We try our best to have all our standards develop test suites, validators, and conformance sections detailing their own criteria for testability, and that implementers are free to run and self-assess their programs against.

W3C has also developed a set of QA Specification Guidelines to help W3C editors write better specifications, by making them easier to interpret without ambiguity and clearer as to what is required in order to conform.

As indicated in the QA Matrix, all these specifications have a Conformance section, a test suite and test results available online.

7.4.3 Alignment

The specification should be aligned with existing JTC 1 standards or ongoing work and thus complement existing standards, architectures and style guides. Any conflicts with existing standards, architectures and style guides should be made clear and justified.

7.4.3.1 Relationship to Existing Standards

  1. What international standards are closely related to the specification and how?
  2. To what international standards is the proposed specification a natural extension?
  3. How is the specification related to emerging and ongoing JTC 1 projects?

The ... specification seats on top of the XML stack, which, without being an ISO standard, is widely recognized, including by ISO, as a de facto industry open standard. XML itself is based on SGML, an ISO standard.

There are no known conflicts with existing International Standards.

Several JTC 1 groups are working within the framework of XML, and several ISO/IEC standards are already using XML as their underlying syntax. Our understanding is that there are already ISO/IEC standard referencing pieces of the W3C stack, so the alignment is clear.

The JTC 1 SC .. group is doing so and so in relation to this spec..

7.4.3.2 Adaptability and Migration

  1. What adaptations (migrations) of either the specification or international standards would improve the relationship between the specification and international standards?
  2. How much flexibility does the PAS submitter have ?
  3. What are the longer-range plans for new/evolving specifications?

There is no identified need for migrations or adaptations of either ...

7.4.3.3 Substitution and Replacement

  1. What needs exist, if any, to replace an existing international standard? Rationale?
  2. What is the need and feasibility of using only a portion of the specification as an international standard?
  3. What portions, if any, of the specification do not belong in an international standard (e.g. too implementation specific)?

There is no plan or expressed need to replace any existing IS with the transposition of this specification. Quite the opposite, the plan is to complement and enrich the global system of standards (some of them being already JTC 1 standards, some not).

7.4.3.4 Document Format and Style

  1. What plans, if any, exist to conform to JTC 1 document styles?

The production of all W3C specifications is driven by a set of W3C publication tools, templates, and rules that support accessibility and broad usability across different environments. W3C is capable of generating multiple output formats using our specification sources (e.g. HTML, PDF, plain text.)

The intended publication mode for this submission would be to retain the essential aspects of the W3C publication. Should any updating of the publication require transposition to JTC 1 document styles, a primary consideration would be full accessibility support as defined by this specification, and full retention of linguistic and hyperlinking expected by one of the primary audiences for our work, the community of web developers.

Regarding final names and numbers in the ISO/IEC style, the table in the introduction section above provides the requested title and number (40404) for W3C/SpecName (using the assigned 40K numbering base allocated to W3C).

7.4.4 Maintenance

Have changes occurred on the subject of maintenance since the PAS Submitter application or renewal or, for a Fast Track, since the most recent submission of the standard? (This is the place to mention any particular agreement reached with a JTC 1 entity).

(This is a new section in revised JTC 1 PAS procedures in 2013.)


Created by Daniel Dardailler
last updated $Id: pas-er.html,v 1.65 2014/04/14 10:23:38 danield Exp $