Contents
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:
xmlns
attribute and that is defined as the
FIXED
value of the xmlns
attribute of
the html
element 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 ID
(e.g. the
id
attribute on most XHTML elements) as fragment
identifiers.
xml:space
attribute 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 (//
). The
various fields MUST be composed as follows:
-
". For formal standards, this
field MUST be the formal reference to the standard (e.g.
ISO/IEC 15445:1999
).
W3C
.
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.
EN
).
Using these rules, the name for an XHTML family conforming
document type might be -//MyCompany//DTD XHTML-MyML
1.0//EN
.
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.