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, 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.
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 conforms to this specification when it meets the following criteria:
xmlnsattribute and that is defined as the
FIXEDvalue of the
xmlnsattribute of the
htmlelement defined in the Structure Module. When this identifier is expressed as a URI, the URI must dereference to the implementation of the document type.
Documents that rely upon XHTML-family document types are considered XHTML conforming if they validate against their referenced document type.
A conforming user agent must meet all of the following criteria (as defined in [XHTML1]):
text/xml, it shall only recognize attributes of type
idattribute on most XHTML elements) as fragment identifiers.
xml:spaceattribute is set to
default. For all such elements, XHTML User Agents are required to suppress line breaks occurring immediately after the start tag or immediately prior to the end tag.
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 document types implemented as
XML Document Type Definitions are defined through XML Formal
Public Identifiers (FPIs). Within FPIs, fields are separated
by double slash character sequences (
various fields MUST be composed as follows:
-". For formal standards, this field MUST be the formal reference to the standard (e.g.
DTD XHTML-followed by 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.
Using these rules, the name for an XHTML family conforming
document type might be
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:
In the case of new modules, there is no need to associate the module iwth a specific version of XHTML - the name does not need to identify version dependencies. In the case of new document types, the new type does not necessarily have any relationship to a specific version of XHTML. Instead, the new document type should itself have versioning that will help iun its evolution. Document types will necessarily evolve out of step with XHTML from the W3C.