3. Conformance Definition

This section is normative.

In order to ensure that XHTML-family documents are maximally portable among XHTML-family user agents, this specification rigidly defines conformance requirements for both of these and for XHTML-family document types. While the conformance definitions can be found in this section, they necessarily reference normative text within this document 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.

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

3.1. XHTML Host Language Document Type Conformance

It is possible to modify existing document types and define wholly new document types using both modules defined in this specification and other modules. Such a document type is "XHTML Host Language Conforming" when it meets the following criteria:

1. The document type MUST be defined using one of the implementation methods defined by the W3C. Currently this is limited to Relad NG, XML DTDs and XML Schema.
2. The schema which defines the document type MUST have a unique identifier as defined in Naming Rules that begins with the character sequence "XHTML".
3. The schema which defines the document type must include, at a minimum, the Document, Structural, Text, Hypertext, Text, List, Core Attribute, Hypertext Attributes, and I18N Attribute modules defined in this specification.
4. For each of the W3C-defined modules that are included, all of the elements, attributes, types of attributes (including any required enumerated value lists), and any required minimal content models must be included (and optionally extended) in the document type's content model. When content models are extended, all of the elements and attributes (along with their types or any required enumerated value lists) required in the original content model must continue to be required.
5. The schema that defines the document type may define additional elements and attributes. However, these MUST be in their own XML namespace [XMLNAMES]. If additional elements are defined by a module, the attributes defined in included XHTML modules are available for use on those elements, but SHOULD be referenced using their namespace-qualified identifier (e.g., xhtml:class). The semantics of the attributes remain the same as when used on an XHTML-namespace element.

3.2. XHTML Integration Set Document Type Conformance

It is also possible to define document types that are based upon XHTML, but do not adhere to its structure. Such a document type is "XHTML Integration Set Conforming" when it meets the following criteria:

1. The document type MUST be defined using one of the implementation methods defined by the W3C. Currently this is limited to Relax NG, XML DTDs and XML Schemas.
2. The schema that defines the document type MUST have a unique identifier as defined in Naming Rules. This identifier MUST contain the character sequence "XHTML", but MUST NOT start with that character sequence.
3. The schema which defines the document type MUST include, at a minimum, the Structural, Hypertext, Text, and List modules defined in this specification.
4. For each of the W3C-defined modules that are included, all of the elements, attributes, types of attributes (including any required enumerated lists), and any required minimal content models MUST be included (and optionally extended) in the document type's content model. When content models are extended, all of the elements and attributes (along with their types or any required enumerated value lists) required in the original content model MUST continue to be required.
5. The schema that defines the document type MAY define additional elements and attributes. However, these MUST be in their own XML namespace [XMLNAMES]. If additional elements are defined by a module, the attributes defined in included XHTML modules are available for use on those elements, but SHOULD be referenced using their namespace-qualified identifier (e.g., xhtml:class). The semantics of the attributes remain the same as when used on an XHTML-namespace element.

3.3. XHTML Family 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:

1. The document type MUST be defined using one of the implementation methods defined by the W3C. Currently this is limited to Relax NG, XML DTDs and XML Schemas.
2. The schema that defines the module MUST have a unique identifier as defined in Naming Rules.
3. When the module is defined using an XML DTD, the module MUST isolate its parameter entity names through the use of unique prefixes or other, similar methods.
4. The module definition MUST have a prose definition that describes the syntactic and semantic requirements of the elements, attributes, and/or content models that it declares. For the avoidance of doubt, if there is any discrepancy between the prose definition of a module and its schema implementation(s), the prose definition MUST take precedence.
5. The module definition 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, or when the reused element names are within their own XML namespace (see below).
6. The module definition's elements and attributes MUST be part of an XML namespace [XMLNAMES]. If the module is defined by an organization other than the W3C, this namespace MUST NOT be the same as the namespace in which other W3C modules are defined.

3.4. XHTML Family Document Conformance

A conforming XHTML family document is a valid instance of an XHTML Host Language Conforming Document Type. For the avoidance of doubt, the behavior of User Agents in the presence of invalid documents is undefined.

3.5. XHTML Family User Agent Conformance

A conforming user agent must meet all of the following criteria (as defined in [XHTML1]):

1. In order to be consistent with the XML 1.0 Recommendation [XML], the user agent MUST parse and evaluate an XHTML document for well-formedness. If the user agent claims to be a validating user agent, it MUST also validate documents against their referenced schemas.
2. When the user agent claims to support facilities defined within this specification or required by this specification through normative reference, it MUST do so in ways consistent with the facilities' definition.
3. When a user agent processes an XHTML document as generic [XML], it MUST recognize only attributes of type ID (e.g., the id attribute on most XHTML elements) as fragment identifiers.
4. If a user agent encounters an element it does not recognize, it MUST continue to process the children of that element.
5. If a user agent encounters an attribute it does not recognize, it MUST ignore the entire attribute specification (i.e., the attribute and its value).
6. If it encounters an entity reference (other than one of the predefined entities) for which the user agent has processed no declaration (which could happen if the declaration is in the external subset which the user agent hasn't read), the entity reference SHOULD be rendered as the characters (starting with the ampersand and ending with the semi-colon) that make up the entity reference.
7. When rendering content, user agents that encounter characters or character entity references that are recognized but not renderable SHOULD display the document in such a way that it is obvious to the user that normal rendering has not taken place.
8. Whitespace is defined as in [XML]. On input all whitespace is preserved - this is exactly as if the value of xml:space, as defined in [XML], is set to "preserve". If the value of that attribute is set to "default", that is the same as if it were set to "preserve". On rendering, whitespace is processed according to the rules of [CSS2].

3.6. Naming Rules

XHTML Host Language 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 document types implemented as XML Document Type Definitions are defined through Formal Public Identifiers (FPIs). Within FPIs, fields are separated by double slash character sequences (//). The various fields must be composed as follows:

1. The leading field must be "-" to indicate a privately defined resource.
2. 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.
3. The third field contains two constructs: the public text class followed by the public text description. The first token in the third field is the public text class which should adhere to ISO 8879 Clause 10.2.2.1 Public Text Class. Only XHTML Host Language conforming documents should begin the public text description with the token XHTML. The public text description should contain the string XHTML if the document type is Integration Set conforming. The field must also contain an organization-defined unique identifier (e.g., MyML 1.0). This identifier should be composed of a unique name and a version identifier that can be updated as the document type evolves.
4. The fourth field defines the language in which the item is developed (e.g., EN).

Using these rules, the name for an XHTML Host Language conforming document type might be -//MyCompany//DTD XHTML MyML 1.0//EN. The name for an XHTML family conforming module might be -//MyCompany//ELEMENTS XHTML MyElements 1.0//EN. The name for an XHTML Integration Set conforming document type might be -//MyCompany//DTD Special Markup with XHTML//EN.

3.7. XHTML Module Evolution

Each module defined in this specification is given a unique identifier that adheres to the naming rules in the previous section. Over time, a module may evolve. A logical ramification of such evolution may be that some aspects of the module are no longer compatible with its previous definition. To help ensure that document types defined against modules defined in this specification continue to operate, the identifiers associated with a module that changes will be updated. Specifically, the Formal Public Identifier and System Identifier of the module will be changed by modifying the version identifier included in each. Document types that wish to incorporate the updated functionality will need to be similarly updated.

In addition, the earlier version(s) of the module will continue to be available via its earlier, unique identifier(s). In this way, document types developed using XHTML modules will continue to function seamlessly using their original definitions even as the collection expands and evolves. Similarly, document instances written against such document types will continue to validate using the earlier module definitions.

Other XHTML Family Module and Document Type authors are encouraged to adopt a similar strategy to ensure the continued functioning of document types based upon those modules and document instances based upon those document types.