3. Conformance Definition

Contents

3.1. Module Conformance
3.2. Naming Rules
- 3.2.1. Rationale for Naming Rules

This section is normative.

In order to ensure that XHTML modules are maximally portable, this specification rigidly defines conformance requirements. While the conformance definitions can be found in this section, they necessarily reference normative text within this document, within the base XHTML specification [XHTML1], and within other related specifications. It is only possible to fully comprehend the conformance requirements of XHTML through a complete reading of all normative references.

3.1. Module Conformance

This specification defines a method for defining XHTML-conforming modules. A module conforms to this specification when it meets all of the following criteria:

The module must be defined using one of the implementation methods identified in this specification (currently on XML DTDs are defined).
The module must have a unique identifier as defined in Naming Rules.
When the module is implemented using an XML DTD, the module must insulate its parameter entity names through the use of unique prefixes or other, similar methods.
The module must have a prose definition that describes the syntactic and semantic requirements of the elements, attributes, and/or content models that it declares.
The module must not reuse any element names that are defined in other W3C-defined modules, except when the content model and semantics of those elements are either identical to the original or an extension of the original.

Note: There really should be a defined restriction on the reuse of elements that are specified in other W3C-defined modules. However, this restriction should be moderated such that, for example, the li element can be reused under a new list-style element (e.g. mylist).

3.2. Naming Rules

Names for XHTML-conforming document types must adhere to strict naming conventions so that it is possible for software and users to readily determine the relationship of document types to XHTML. The names for modules are defined through XML Formal Public Identifiers (FPIs). Within FPIs, fields are separated by double slash character sequences (//). The various fields MUST be composed as follows:

The leading field identifies the resources relationship to a formal standard. For privately defined resources, this field MUST be "-". For formal standards, this field MUST be the formal reference to the standard (e.g. ISO/IEC 15445:1999).
The second field MUST contain the name of the organization responsible for maintaining the named item. There is no formal registry for these organization names. Each organization SHOULD define a name that is unique. The name used by the W3C is, for example, W3C.
The third field MUST take the form ELEMENTS XHTML- followed by an organization-defined unique identifier (e.g. MyML 1.0). This identifier is SHOULD be composed of a unique name and a version identifier that can be updated as the document type evolves.
The fourth field defines the language in which the item is developed (e.g. EN).

Using these rules, the name for an XHTML conforming module might be -//MyCompany//ELEMENTS XHTML-MyModule 1.0//EN.

3.2.1. Rationale for Naming Rules

Naming Rules are critical for portability of user agents and XHTML-conforming tools. These rules need to be simple enough that they can be readily adhered to, and need to convey upon document type and module designers the power to readily associate their creations with XHTML (for marketing purposes, if nothing else). The above rules address these concerns. There were some other possibilities for naming conventions, and they were not used for the following reasons:

Use the XHTML version in the identifier.
In the case of new modules, there is no need to associate the module with a specific version of XHTML - the name does not need to identify version dependencies.