[T]o help W3C editors write better specifications, by making a specification easier to interpret without ambiguity and clearer as to what is required in order to conform.
[A]nalyzes how design decisions of a specification's conformance model may affect its implementability and the interoperability of its implementations.
intended to provide a flexible framework within different usage scenarios to semantically represent any type of content, e.g., to deal with the testing and/or repair of content.
Acknowledgements (of individuals or communities that influenced the work)
References (normative, informative)
Appendix
Normative and Informative Content
Common terms from a controlled vocabulary often used in specifications to distinguish normative and informative content. Spec Terms incorporates these concepts.
Normative content
Mandatory rules, requirements, or behaviours that determine conformance.
Often signalled with key words such as “MUST” (“REQUIRED”, “SHALL”), “MUST NOT” (“SHALL NOT”), “SHOULD” (“RECOMMENDED”), and “MAY” (“OPTIONAL”) interpreted according to BCP 14 [RFC2119] [RFC8174].
Informative content
Explanations, examples, diagrams, notes, and guidelines.
Often includes key words such as “strongly encouraged”, “strongly discouraged”, “encouraged”, “discouraged”, “can", “cannot”, “could”, “could not”, “might”, and “might not”.
Interoperability
Which product classes defined by a specification are required to work together?
Are implementations actually interoperating? How can we assess and manage this in practice, including partial or optional features?
Who ensures interoperability as a specification evolves?
