Requirement 01:Include a conformance clause.

What does it mean?The conformance clause provides the answers to the important questions: what may conform and how? The conformance clause defines at a high-level, what is required of implementers of the specification.  It, in turn can refer to other parts of the specification or other specifications.  The conformance clause may partition the technology into functional subsets, such as profiles, modules or other structures.  Additionally, it may specify minimal requirements for certain functions, as well as extensibility, optional features and alternative approaches and how they are to be handled.

Why care?The conformance clause defines what is required to claim conformance: as such, it provides communication between the specifications creators, implementers, and users as to what is required, and gives meaning to the phrase, “conforming implementation”.  Moreover, it facilitates the consistent application of conformance within a specification and across related specifications.  It promotes interoperability.

Related

• Conformance clause template [CONF-TEMPLATE]

Techniques

• Use the template to create the conformance clause

  • Simply complete the conformance clause template and put the result into the specification.

    To be honest, answering the questions in the conformance clause template may not be a simple matter, and may lead the Working Group into thorny issues. However, these are questions that need to be answered if the specification is to be successful, i.e., if it is to foster multiple high quality interoperating implementations.

  • Create an item in the table of contents for the conformance section.

    If the technology consists of multiple individual recommendations, create a table of contents item for Conformance, and explain that the Conformance section is in another document.

Examples

Good Practice 01:Define the specification's conformance model in the conformance clause.

What does it mean? The conformance model is the conceptual framework in which conformance is defined. It consists of and is defined by addressing at least these three topics:

• What needs to conform and how — hereafter designated asclass of products.
• Any special designations or concepts used to distinguish conformance categories, types, etc. (e.g., profile/module/level, well-formed/valid, A/AA/AAA).
• Ways that conforming implementations can vary from each other (e.g., optionality and extensions).

Why care? The key is to communicate to the reader what conformance to the specification is all about.  It provides a framework for implementers to know what they need to build in order to conform and the different ways that they could claim conformance.  It provides users/buyers a basis to express their requirements.

Related The conformance model overlaps several other topics inQA Specification Guidelines, most particularly:

• Class of products, seesection 2.2.2
• Profile, modules, levels seesection 2.4.1
• Optionality, seesection 2.4.2
• Extensibility, seesection 2.4.3
• Advanced topics, seeVariability in Specifications [VIS]

Techniques

1. List the classes of products targeted by the specification
   1. Identify the types of products that will implement the specification
   2. If not already done (above step), group the products into generic categories – these are the classes of product. (e.g., content, user agent, protocol, API, specification)
2. List the conformance designations or conformance concepts. To help realize this, consider these questions.
   1. Does conformance mean something different for different classes of products?
   2. Is more than one type of conformance defined – e.g., different designations (well-formed, valid) or degrees of conformance (A, AA, AAA)?
   3. Is conformance tied to the class of product and similarly named (e.g., host-language conformance, document conformance)?
3. Create a name for each way that conformance can be qualified – i.e., label it
   1. For specifications subdivided into modules, profiles and/or levels, is there a conformance designation associated with each type of subdivision?
   2. If the specification has options and extensibility, will these have an affect or be affected by the conformance designation?
4. Draw a diagram to put it all together – sometimes it is easier to work from a picture
   1. Diagram the classes of products with associated conformance designations,
   2. Add in the subdivisions and any other variability (e.g., options, extensibility)
   3. Extract from this diagram and define the conformance model.
   4. Write the description into the specification. Bonus - if the diagram helps to understand the model, include it.

Examples

Good Practice 02:Specify in the conformance clause how to distinguish normative from informative content.

What does it mean? Normative content is the prescriptive part of the specification, whereas informative content is for informational purposes and assists in the understanding and use of the specification. Content includes all sorts of different forms — not only descriptive prose, but also illustrations, examples, use cases, formulae and other formalisms.

Why care?Conformance of implementations is defined by and measured against normative content.  Distinguishing normative content from that which is informative helps to make sure the reader can find the normative content, knows for sure that it is normative, and does not fail to notice a normative section.  This good practice aims at the high level partitioning of information (e.g., sections) in a specification.

Related What is mandatory? (Seesection 2.3.2)

Techniques

1. For each section in the specification,
   • Determine if the content is normative or informative and, explicitly label it as either “normative” or “informative”.
   • Make the label part of the section heading (e.g., Informative References), as parenthetical text with the heading (e.g., Glossary (normative)).
   • Alternatively, create a list of each section and indicate its normality, (e.g.,Normative Parts in this document’s conformance section).
2. In the conformance clause, explain what the use and meaning (if necessary) of the words used to convey the normality and informality of the content. SeeRequirement 07:Use a consistent style for conformance requirements and explain how to distinguish them.
3. Try to avoid language that sounds normative in an informative section. It might lead the readers to wrong assumptions.

Examples

Good Practice 03:Provide the wording for conformance claims.

What does it mean? It is inevitable that people (e.g., vendors, purchasers) will either claim conformance or demand conformance to a technology. In fact, claiming conformance to a technology may be required in certain situations. Thus, it is important to provide a consistent and unambiguous way to make these claims. Identification of the specification version, class of products, and conformance label are some of the items that could be part of such wording.

Why care?Having a framework, by which to make conformance claims for a particular usage of the technology, minimizes confusion by people who are interested in such claims. Many contexts use conformance claims, including legal as part of regulations, laws, or policies and commercial when selling or buying a product.

Related Conformance claims are closely related to issues of logos and branding. See4. Licensing and branding ofThe QA Handbook [QA-HANDBOOK].

Techniques

• Provide a template for the conformance claim, including
  1. The full name of the specification along with information to identify it uniquely – version, date and the URI if applicable.
  2. Placeholders for  
     1. The conformance designation – the label or type of conformance that is being claimed.
     2. The product claiming conformance with information to identify it uniquely – version, date.
     3. The date of the claim.
     4. Implementation Conformance Statement (if one exists, seethe next Good Practice).

Conformance Claim Template:

Form 1:

Examples

Specification Guidelinessection 4.4 Conformance Claims provides this document's template for conformance claims.

Good Practice 04: Provide an Implementation Conformance Statement Pro Forma.

What does it mean? AnImplementation Conformance Statement (ICS) provides information about an implementation to a specification, by presenting in a uniform manner the implemented capabilities (e.g., functions, features) and options as well as limitations of the implementation. AnICS pro forma typically takes the form of a blank questionnaire or checklist for an implementation.  It provides the implementer a way to indicate the features implemented. Think of it as an inventory of what has been implemented.  Note that a completedICS does not indicate conformance of the implementation.  Hence, answering "yes" to indicate a capability is supported does not mean that the capability has been tested.

This Good Practice suggests that the specification itself include anICS pro forma.  Providing this pro forma makes it conducive to completing and helps to ensure consistency among completedICS. 

Why care? AnICS pro forma provides a concise summary of a specification, i.e., the capabilities and options defined in the specification as well as any defined subdivisions (e.g., profiles, modules) and conformance designations. TheICS provided with the specification is blank, waiting for the implementer to complete.  This blank ICS provides implementers and users a quick overview of features defined in the specification. A completedICS not only provides information on what has been implemented (mandatory and optional features), but can also be used to document the presence of extensions or any specializations that have been made.  A completedICS provides information useful to facilitate the selection of applicable tests for the particular implementation.  However, that is not all.  Although theICS content is independent of testing, associating it with conformance tests makes it an essential piece in the reporting of conformance results (see techniques inGood Practice 05).

Related

• Optionality, seesection 2.4.2
• Require an Implementation Conformance Statement as part of valid conformance claims, seeGood Practice 05
• ETSI Making Better Standards

Techniques

1. Create a list, table or form listing all features (capabilities) and indicating which are mandatory to implement.
2. Provide space for the implementer to check:  yes (to indicate the feature is implemented), No (to indicate it is not implemented), Not Applicable, and space for comments.
3. Organize the features according to the subdivisions of the specification or in the order they occur in the specification or in some other logical grouping
4. If there are dependencies, express them. (For instance, if No to this question, jump to the next section.)
5. Provide a tool to help implementers fill out the ICS and produce a report (e.g., inEARL [EARL]).

Examples

Good Practice 05: Require an Implementation Conformance Statement as part of valid conformance claims.

What does it mean? This simply puts together the previous two Good Practices. Not only could the specification provide anICS pro forma for implementers, but also the specification could require a link to theICS pro forma from its standardized conformance claim template.

Why care? Providing a completedICS with the conformance claim might help customers and users to determine quickly the implemented capabilities as well as easily verify the level of support for individual requirements of the specifications.  Combining theICS with a conformance test suite, can strengthen the claim.  Specifically, theICS augmented with links to conformance tests, provides a very nice way to indicate not only what has been implemented, but also, what has been implemented correctly (i.e., conforms to the specification).

Related

• See “Provide the wording for conformance claims” insection 2.1.2

Techniques

1. Give precise instruction how theICS becomes part of the conformance claim. It might be an external document, a link to a precise dated document, etc.
2. Augment theICS by providing links to the test suite, such that each feature has associated with it a test (or set of tests).  Explain what it means to check Yes or No.  Specifically, does Yes/No indicate that the implementation has the relevant featureand passes the applicable tests or does Yes/No only indicate that the feature is implemented. In the latter case, add an additional column, to indicate the result of executing the tests.  To avoid confusion as to the role ofICS, we recommend adding an additional column.

Examples

Requirement 02: Define the scope.

What does it mean? Describe what the specification is about.  Let the reader know the topics covered in the specification.

Why care? This is one of the first sections a reader reads, so it is important to capture their attention and make sure they understand what the specification is about. It helps to keep the specification content focused. It helps reviewers determine when the specification is over-stepping its mandate and then gives the possibility to revise the specification in development. It also helps readers know the limits or boundaries of the specification and whether it is of interest to them.

Techniques

• Make the scope easy to find.
  1. Include the scope section in the beginning of the document
  2. Make “Scope” an item in the table of contents
• Write simple, direct statements of fact. Do not include any requirements in the scope section. Use statements such as: This document
  • — specifies a method of …
  • — specifies the characteristics of …
  • — defines…
  • — establishes a system for …
  • — establishes general principles for …
  • — is a guide for …
• In addition to describing the subject of the specification, address the following to achieve a more complete scope:
  • Applicability of the specification,
  • Purpose, objectives, and goals,
  • Types of products or services (i.e., classes of products) to which the specification applies,
  • Relationship to other specifications or technologies,
  • What is not in scope, i.e., what the specification is not about,
  • Limitations on the application of the specification.
  Note that it is not necessary to write a separate statement for each of these items, rather, they can be combined.

Examples

Many W3C specifications have included scope prose in the Abstract section. We advocate making the scope a separate section in the body of the specification, making it easy to find and insuring that it is an item in the table of contents.

Good Practice 06:Provide examples, use cases, and graphics.

What does it mean? Illustrate concepts, behaviors, functionality, interaction, etc. through whatever means makes sense, such as examples, use cases, graphics, and sample code. This aids in the understanding of the specification, especially for areas that are innately complex or for which the Working Group has had to explain to its members or the public.  Additionally, a set of broad examples and use cases can help to clarify the specification’s scope.

Why care?It is difficult to understand some concepts, behaviors, functionality, or other aspects of a specification without informative interpretations to aid the reader. Providing the reader with additional information beyond the specification’s prose, can only help in achieving implementation and interoperability.

Techniques

It is up to the Working Group to determine the best way to illustrate the scope and other parts of the specification. Typically, the nature of the specification influences the type of examples, uses cases, graphics, etc. that make sense.

• Develop use cases to illustrate the specification scope.  Use easy-to-understand narrative to describe situations that are applicable to the specification.
• Provide examples:
  • for each behavior or functionality that was resolved from an issue,
  • to illustrate the meaning of abstract notations (e.g., BNF),
  • for each chapter in the specification.
• Describe the language features through numerous examples and compliment them by references to the normative texts
• Reference a non-normative tutorial document that includes informative explanation of concepts, behavior, or functionality.
• Provide non-normative references to resources such as books, specification annotation, test sets. These references provide annotations to the specification, pictorial illustrations, and explanations of specification rules.

Examples

For markup specifications, provide at least one example of each markup construct; illustrate each transformation capability with an example showing input and output.

Good Practice 07: Write sample code or tests.

What does it mean? For each feature, the Working Group might seek early implementation to demonstrate the feature. If early implementations are not available (e.g., due to commercial constraints,IPR, etc.), it is beneficial to write test cases to illustrate a concept or use case of the technology. This provides a way to to study the interactions between the different parts of the specification and reveal problems. Additionally, these test cases can be incorporated into a test suite.

Why care? Developing a partial implementation (sample code) or test cases can provide an understanding of a concept or feature as well as help to keep it focused. It can save the Working Group and eventually implementers time and resources by:

• providing examples to illustrate the specification,
• facilitating issue resolution,
• helping to have a pre-implementation report at Candidate Recommendation phase,
• contributing to the development of a complete Test Suite,
• encouraging external implementations and therefore a more complete implementation report.

Related

• CSS Test Suite Documentation [CSS-TEST-DOC]
• OWL Test Cases [OWL-TEST]

Techniques

1. Encourage the development of proofs of concept implementations of the technology.
2. Provide at least one example of each feature, which may also be used as the basis of a future test case.
3. Do not put a feature into a specification without the corresponding test cases.
4. Create a template for new feature proposals that includes a request for associated test cases.

Examples

Requirement 03:Identify who and/or what will implement the specification.

What does it mean? Clearly identify theclass of products (i.e., type of products or services) upon which the requirements are imposed.  If multiple classes of products are targeted by the specification, make sure each is described.   Examples of classes of products include: content, producer of content, player, protocol, API, agent, and guidelines.

Why care? It helps define the scope of the specification and is needed when defining conformance. It also helps the reader know the target of the specification – that is, to discover and focus on what they have turned to the document for and avoid what they may find immaterial.

Related

• Classes of Products inVariability in Specifications [VIS]

Techniques

• Give the classes of products in the specification:
  1. Think about all the types of products or services that will implement this technology, group those that are similar or achieve the same purpose, and determine the generic name for the group.  This would be the class of product.
  2. List these classes of products in the specification.
  3. Describe them as part of the scope.

Examples

Requirement 04: Make a list of normative references.

Most W3C specifications contain a list of normative references, clearly identified as such, at the end of the document.

Good Practice 08: When imposing requirements by normative references, address conformance dependencies.

Precise designation and reference: The first example is illegal as the example uses a URI Reference as opposed to only a URI; RFC 2396 clearly distinguishes between those constructs. To make the first example a valid construct, the text should have said:

The value of the attribute is a URI Reference as defined in section 4 of [RFC2396]

Superset of the reference and interpretation: RFC 2396 does not include support for IPv6 literals; RFC 2732 introduced the syntax but it doesnot update RFC 2396. It is not correct to assume that it does even if it seems logical. Do not interpret the intention of the external reference.

As a separate example, any specification that defines the behavior of a class of product that creates XML should address creation of XML 1.1 and anticipate future XML versions. In XSLT, creation of XML is specified by<xsl:output method="xml" version="1.0" />, and each version of XSLT defines the allowable range of values for the version attribute. Another option is to reference the XML Infoset - for instance, XML Inclusions are compatible both with XML 1.0 and XML 1.1 since they reference normatively the XML Infoset, which is the same for the two versions of XML.

In its sectionReferencing the Unicode Standardand ISO/IEC 10646, the specificationCharacterModel for the World Wide Web 1.0: Fundamentals[CHARMOD] gives a detailed indications for referencing Unicode Standard and ISO/IEC 10646. Specification editors areencouraged to follow these recommendations.

Good Practice 15:Use optional features as warranted.

What does it mean? Examine the reason for the optional feature - is it to address a real, existing need? Should it really be optional or made a mandatory part of the specification? Be careful not to provide optional features in anticipation for something that sounds like a good idea but whose implementation is improbable - ask the implementers if they ever plan to need this. Think about the implications of both implementing the optional feature and of not implementing it. Do not make something an option just because the Working Group cannot decide on what to do or cannot reach consensus. As the specification progresses, consider removing unimplemented features.

Why care? A concise list of optional features helps to keep the specification focused and greatly increases the likelihood of obtaining interoperable solutions. Ensuring that only necessary optional features are contained in the specification also makes the job of the implementer easier and reduces costs.

Techniques

• Make a list of use cases with the optional feature.
• Look at the optional feature and each class of product. Is it something that this class of product would implement? Consider if it really is an option - perhaps, for this class of product it is not really an option but should be mandatory.
• Develop an analyzer or set of tests to determine the need for options. Use the analyzer/tests to capture what implementations are doing – are they doing the same thing or is there variety and is that variety desired?

Story:

As part of its exit criteria for Candidate Recommendation, a Working Group created a set of tests to "test the specification". The tests were able to show where there was need for optionality (e.g., diversity among implementations and flexibility justified) and where it was possible to narrow the choices (e.g., implementations used a much narrower set of values than those permitted).

Good Practice 16: Clearly identify optional features.

What does it mean? When introducing an optional feature in the specification, label it as such, so that it is easy to find all the optional features defined in the specification. If there are no optional features, state so in the conformance section.

Why care? Options can be useful, but non-judicious use of optional features increases the variability among conforming implementations. In order to minimize the unnecessary optionality, it is a good idea to provide an easy way to identify them. The use of labels for optional features also helps in constructing pro forma conformance claims, comparisons between two implementations, reports to the W3C Director about implementations, etc.

Techniques

There are many ways to tag options. Any technique that distinguishes the optional feature from the required feature is acceptable. Some possibilities include:

• listing optional features in a separate section;
• specifying optional features in a different font (be careful of accessibility and printing problems);
• including a unique designation to identify the optional feature.

Good Practice 17: Indicate any limitations or constraints on optional features.

What does it mean? Provide as much information as possible to narrow the allowable choices and to increase predictability. For implementation dependent values orfeatures, if possible, provide a range or set of permitted values rather thanleaving it completely open.

Discuss the implications of either using the optional feature or not. It may be helpful to provide rationale for choosing one option over another or for not using the option at all. Consider the unintended consequence of the optional feature - on other optional features, other parts of the specification, on other specifications.

Why care? Narrowing choices and increasing predictability enhance the likelihood of interoperability since the implementer chooses from a reduced sample space. Narrowing choices, providing more information, and eliminating incorrect choices increases the chances of correct implementations. An enumerated list of values is one way to constrain the choice of optionality.

Techniques

For optional features, especially enumerated lists, make sure to indicate the number of choices/options available for implementation. Specifically, can none, exactly one, or several of the allowable choices be implemented? Does this number depend on other parts of the specification or other chosen options?

Questions to consider include:

• What affect will implementing the optional feature have on a conforming implementation, on interoperability?
• Is there any affect or negative consequence if the option is not implemented?
• Is implementation of the option mandatory?
• Is there a default value for the option?
• Are there any dependencies, that is, the option can only be implemented if certain conditions are true?
• Are the optional features mutually exclusive, that is, can one option override and void another?

Examples

Good Practice 19: Warn extension creators to create extensions that do not interfere with conformance.

What does it mean? Include in the specification a warning to those who are creating extensions that extensions should not contradict or negate conformance to the original specification. Extensions can be created in different contexts: directly by implementers, in other specifications, etc.

Why care? Conformance should be independent of whether there is an extension or not – if it conformed without the extension, then conformance should hold true with the extension.

Techniques

Include statements in thespecification such as:

• Each implementation must fully support all required functionality of the specification exactly as specified.
• The use of extensions must not contradict nor cause the non-conformance of functionality defined in the specification.
• Extensions must follow the requirements and guidelines of the specification they extend; i.e., the specifications must be extended in a standard manner.

Examples

Good Practice 20:Define error-handling for unknown extensions.

What does it mean? For each class of product affected by an error condition, include error-handling instructions for when an extension is not available or understood.

Why care? When using a strict conforming application, users might have to deal with documents, data considered invalid because they contain errors, or extended syntactically. Developers need to know what is the expected behavior of the application in such context.

Techniques

There are typically two approaches: (see section4.2.3 Extensibility from Architecture of the World Wide Web, Volume One [WEB-ARCH])

• a so-called “must Understand” policy, as implemented in SOAP 1.2 by themustUnderstand attribute; in this type of mechanism, a processor encountering a syntax token not defined in the specification is required to know how to process the said token or must fail for the whole unit where the token appears
• a so called “must Ignore” policy (as implemented in SOAP 1.2 by themustIgnore attribute), where a processor not knowing how to process an unknown syntax token must skip part or the totality of the unit where the token appears

A good way to handle these two approaches is to have a way in the syntax to distinguish which behavior is expected (e.g.,mustUnderstand/mustIgnore attributes in SOAP 1.2). Which policy to choose depends heavily on the importance of theprocessing of the data, the user experience of applications based on thesaid format, etc.

Do not forget to address all the classes of products. For example, an authoring tool and a rendering tool might behave in different ways.

Examples

Requirement 12: Identify deprecated features.

What does it mean? If the specified technology has already been published in a previous version of the specification, indicate the features from the previous version now deprecated or state in the conformance section that no features were deprecated.

Why care? It helps implementers as well as users know which features may become obsolete in future versions of the technology. This gives them the opportunity to adjust their implementation to phase out the relevant features, and provide new ways to accomplish the same task.

Related

• Other Good Practices in this section.

Techniques

1. Create a list of all deprecated features.
2. Create a dedicated section for it.
3. Create an entry in the table of contents going to this list.
4. For each deprecated feature, create a link to the appropriate definition in the specification.

Examples

Requirement 13:Define how each class of product handles each deprecated feature.

What does it mean? By deprecating a feature, the Working Group indicates its desire that the feature disappear from a future version of the specification. The motivation may be to convert an old feature to a newer one or to remove an old, dangerous, redundant or undesirable feature. Regardless of the reason, it is important to define the affect this has on implementations that may encounter this feature (e.g., consumer products such as user agents or producer products such as authoring tools). How will the user agents or producer products tolerate use of the deprecated feature? Will it signal an error or a warning? Typically, use of a deprecated feature would not affect a consumer (e.g. user agent), while a producer (e.g. authoring tool) should issue a warning.

Why care? Defining how deprecated features are handled, provides a smoother transition for the users of the specified technology and ensures more consistency of the behavior across implementations. It is also particularly important for implementations that need to support different versions of the specification.

For instance, the specification may require that an implementationsupports both the features of the new and the old specifications, orsuggest a converting mechanism.

Techniques

1. Consider the effect of deprecation on all classes of products that implement the specification (e.g., authoring tools, converters, and user agents).
2. Define how it affects conformance.

Examples

Good Practice 21:Explain how to avoid using a deprecated feature.

What does it mean? Deprecating a feature implies that its use is discouraged, often because there is a better technique available to achieve the same result. For each deprecated feature, it is necessary to explain how implementers and users can avoid using it. It might be helpful to give additional information providing insight into the deprecation motivation.

Why care? Examples and information about each deprecated feature help users smoothly evolve toward the new version of the technology and understand its benefits. This enables a faster adoption of the technology.

It helps implementers understand the rationale for implementing the new technology, to implement an alternative mechanism, and to tool tips or conversion scenarios to help users with the transition.

Techniques

1. For each deprecated feature, give one or more examples showing the old way and the new way.

Examples

Good Practice 22:Identify obsolete features.

What does it mean? If the specified technology has been published in a previous version of the specification, indicate the features from the previous version now obsolete, or state in the conformance section that no features were made obsolete.

Why care? It gives a clear message to users and implementers that obsolete features are forbidden and not part of the specification anymore. It helps avoid the creation of documents mixing old and new techniques that would be invalid.

It also helps avoid name clashing. When creating an extension to a technology, implementers are likely to use syntax token for their extended features name. Giving the name of obsolete features helps implementers avoid using the names of previous features that are now obsolete.

Related

• See also the section aboutExtension.

Techniques

1. Create a list of all features that are obsolete.
2. Create a dedicated section for it.
3. Create an entry in the table of contents going to this list.
4. For each deprecated feature, create a link to the appropriate definition in the previous specification.

Examples

Good Practice 23:Define an error handling mechanism.

What does it mean? For each class of product affected by an error condition, address error handling. For instance: for a language, address what effect an error (be it syntactic orsemantic) in the input has to a processor of this language; for a protocol, address how a party to this protocol should behave whena bogus message is received; for anA.P.I., indicate what exceptions are raised.

Why care?There are many reasons a system may fail; to make a technology reliable,it is crucial to define how it should react to bogus input or conditions.Defining error handling also makes it possible for a user of thetechnology to react appropriately to the error condition.

Techniques

Different methodologies exist to handle errors in a technology:

• Identifying failures points and binding them with well-known error messages allows better recovery and or reporting of these failures. This is particularly useful in protocols.
• The technology can specify the handling of syntax errors (content that cannot be parsed) and semantic errors (meaningless content) separately or together.
• One should keep in mind that extensibility may need new syntax tokens (seeGood Practice 20).
• Try to limit the number of types of error defined by the specification; also, processing errors of the same kind in the same way allows for greater interoperability.

Examples

Story:

In 2004, QA Working Group documents entered Candidate Recommendation prior to a thoroughquality review, resulting in a huge number of issues to resolve and theeventual retreat back to Working Draft for major revisions. Many of thecomments could have been prevented, such as inconsistency and incompleteness of the document (e.g., links to supplementary materials that did not exist or were not complete, overlapping and conflicting requirements), undefined terminology, and unimplementable requirements.

Examples

Related

• W3C Editor's Home Page [EDITOR]
• Manual of Style [MANUAL-STYLE]

Examples

3.3 Accessibility, Internationalization, and Device Independence Considerations

First and foremost, W3C specifications need to frame and definetechnologies that meet the requirements of the particulardeliverable, fulfill the charter of the Working Group, and advancethe Mission of the Consortium.

The Mission of the Consortium involves extending the exchange ofinformation through the Web to everyone. Thus the requirements ofAccessibility, Internationalization and Device Independence aregeneral requirements that must be considered in the specification ofall Web technologies.

TheW3C Web Accessibility Initiative (WAI is a Domain of the Consortium that pursues accessibility of the Web through technology, guidelines, tools, education and outreach, and research and development. Web accessibility depends on several components working together.Essential Components of Web Accessibility shows how the WAI guidelines address these components and shows the role specifications play in making the Web accessible. Specification developers should consult theTechnical Reports page for an up-to-date profile of W3C publications in all areas. In addition, theWAI Home Page is a helpful starting point.

For some further suggestions on how User Interface formats cansupport these requirements, authors may wish to consult the WorkingDraftXML Accessibility Guidelines [XAG].

Similarly, the Working Group should make sure the defined technology iscompatible with internationalization, i.e. is not specific to aparticular language or culture. The benefit of addressinginternationalization aspects in a specification is to ensure that thedefined formats and protocols do not create barriers for languages,writing systems, character codes, and other local conventions employedby end users of the technology.

For information on interoperable text manipulation for text defined in aspecification, refer to theCharacter Model for the World Wide Web [CHARMOD].For other information about specification "internationalization", referto theW3C Internationalization (I18N) Activity.

Finally, a specification of a Working Group should support deviceindependence to the maximum extent possible and appropriate, to providediversity of interaction with a technology by people. The benefit ofaddressing device independence in a specification is the increasedlikelihood that a specification can be accessed from any device, in anycontext by anyone.

For information about specification device independence, refer to theW3C Device Independence Summary.

For each of these considerations, a Working Group should considerdesignating a participant to monitor their applications to thespecification at the earliest point possible and to be the point ofcontact with the relevant W3C Working Groups to seek feedback on theadopted solutions.