This table gives the changes made to the numbering scheme between Specification Guidelines (2004-11-22) and the actual version.
| 1.1 Req A | Requirement 01: | Include a conformance clause. |
| 1.1 GP B | Good Practice 01: | Define the specification's conformance model in the conformance clause. |
| 1.1 GP C | Good Practice 02: | Specify in the conformance clause how to distinguish normative from informative content. |
| 1.2 GP A | Good Practice 03: | Provide the wording for conformance claims. |
| 1.2 GP B | Good Practice 04: | Provide an Implementation Conformance Statement Proforma. |
| 1.2 GP C | Good Practice 05: | Require an Implementation Conformance Statement as part of valid conformance claims. |
| 2.1 Req A | Requirement 02: | Define the scope. |
| 2.1 GP B | Good Practice 06: | Provide examples, use cases, and graphics. |
| 5 GP C | Good Practice 07: | Write sample code or tests. |
| 2.2 Req A | Requirement 03: | Identify who or what will implement the specification. |
| 2.3 Req A | Requirement 04: | Make a list of normative references. |
| 2.3 GP B | Good Practice 08: | Do systematic reviews of normative references and their implications. |
| 3.1 Req A | Requirement 05: | Define the terms used in the normative parts of the specification. |
| 3.1 Req B | Requirement 06: | Create conformance labels for each part of the conformance model. |
| 3.1 GP C | Good Practice 09: | Define the unfamiliar terms in-line, and consolidate the definitions in a glossary section. |
| 3.1 GP D | Good Practice 10: | Use terms already defined without changing their definition. |
| 3.2 Req A | Requirement 07: | Use a consistent style for conformance requirements and explain how to distinguish them. |
| 3.2 Req B | Requirement 08: | Indicate which conformance requirements are mandatory, which are recommended and which are optional. |
| 5 GP E | Good Practice 11: | Use formal languages when possible |
| 5 GP D | Good Practice 12: | Write Test Assertions. |
| 4.1 GP A | Good Practice 13: | Create subdivisions of the technology when warranted. |
| 4.1 Req B | Requirement 09: | If the technology is subdivided, then indicate which subdivisions are mandatory for conformance. |
| 4.1 Req C | Requirement 10: | If the technology is subdivided, then address subdivision constraints. |
| 4.1 GP D | Good Practice 14: | If the technology is profiled, define rules for creating new profiles. |
| 4.2 GP A | Good Practice 15: | Use optional features as warranted. |
| 4.2 GP B | Good Practice 16: | Clearly identify optional features. |
| 4.2 GP C | Good Practice 17: | Indicate any limitations or constraints on optional features. |
| 4.3 Req A | Requirement 11: | Address Extensibility. |
| 4.3 GP B | Good Practice 18: | If extensibility is allowed, define an extension mechanism. |
| 4.3 GP C | Good Practice 19: | Warn extension creators to create extensions that do not interfere with conformance. |
| 4.3 GP D | Good Practice 20: | Define error handling for unknown extensions. |
| 4.4 Req A | Requirement 12: | Identify deprecated features. |
| 4.4 Req B | Requirement 13: | Define how each deprecated feature is handled by each class of product. |
| 4.4 GP C | Good Practice 21: | Explain how to avoid using a deprecated feature. |
| 4.4 GP D | Good Practice 22: | Identify obsolete features. |
| 4.5 GP A | Good Practice 23: | Define an error handling mechanism. |
| 5 GP A | Beyond Conformance | Define an internal publication and review process. |
| 5 GP B | Beyond Conformance | Do a systematic and thorough review. |