5. Module Definition Conventions

Contents

This section is normative.

This document defines a variety of XHTML modules and the semantics of those modules. This section describes the conventions used in those module definitions.

5.1. Module Structure

Each module in this document is structured in the following way:

5.2. Abstract Module Definitions

An abstract module is a definition of an XHTML module using prose text and some informal markup conventions. While such a definition is not generally useful in the machine processing of document types, it is critical in helping people understand what is contained in a module. This section defines the way in which XHTML abstract modules are defined. An XHTML-conforming module is not required to provide an abstract module definition. However, anyone developing an XHTML module is encouraged to provide an abstraction to ease in the use of that module.

5.3. Syntactic Conventions

The abstract modules are not defined in a formal grammar. However, the definitions do adhere to the following syntactic conventions. These conventions are similar to those of XML DTDs, and should be familiar to XML DTD authors. Each discrete syntactic element can be combined with others to make more complex expressions that conform to the algebra defined here.

element name
When an element is included in a content model, its explicit name will be listed.
content set
Some modules define lists of explicit element names called content sets. When a content set is included in a content model, its name will be listed.
expr ?
Zero or one instances of expr are permitted.
expr +
One or more instances of expr are required.
expr *
Zero or more instances of expr are permitted.
a , b
Expression a is required, followed by expression b.
a | b
Either expression a or expression b is required.
a - b
Expression a is permitted, omitting elements in expression b.
parentheses
When an expression is contained within parentheses, evaluation of any subexpressions within the parentheses take place before evaluation of expressions outside of the parentheses (starting at the deepest level of nesting first).
extending pre-defined elements
In some instances, a module adds attributes to an element. In these instances, the element name is followed by an ampersand (&).
defining required attributes
When an element requires the definition of an attribute, that attribute name is followed by an asterisk (*).
defining the type of attribute values
When a module defines the type of an attribute value, it does so by listing the type in parentheses after the attribute name.
defining the legal values of attributes
When a module defines the legal values for an attribute, it does so by listing the explicit legal values (enclosed in quotation marks), separated by vertical bars (|), inside of parentheses following the attribute name. If the attribute has a default value, that value is followed by an asterisk (*). If the attribute has a fixed value, the attribute name is followed by an equals sign (=) and the fixed value enclosed in quotation marks.

5.4. Content Models

Abstract module definitions define minimal, atomic content models for each module. These minimal content models reference the elements in the module itself. They may also reference elements in other modules upon which the abstract module depends. Finally, the content model in many cases requires that text be permitted as content to one or more elements. In these cases, the symbol used for text is PCDATA (parsed characted data). This is a term, defined in the XML 1.0 Recommendation, that refers to processed character data. A content type can also be defined as EMPTY, meaning the element has no content in its minimal content model.

5.5. Attribute Types

In some instances, it is necessary to define the types of attribute values or the explicit set of permitted values for attributes. The following attribute types (defined in the XML 1.0 Recommendation) are used in the definitions of the abstract modules:

Attribute Type Definition
CDATA Character data
ID A document-unique identifier
IDREF A reference to a document-unique identifier
IDREFS A space-separated list of references to document-unique identifiers
NMTOKEN A name composed of only name tokens as defined in XML 1.0 [XML].
NMTOKENS One or more white space separated NMTOKEN values
NUMBER Sequence of one or more digits ([0-9])

In addition to these pre-defined data types, XHTML Modularization defines the following data types and their semantics (as appropriate):

Data type Description
Character A single character, as per section 2.2 of [XML].
Encodings A comma-separated list of 'charset's with optional q parameters, as defined in section 14.2 of [RFC2616] as the field value of the Accept-Charset request header.
ContentType A media type, as per [RFC2045].
ContentTypes Attributes of this type identify the allowable content type(s) of an associated URI (usually a value of another attribute on the same element). At its most general, it is a comma-separated list of media ranges with optional accept parameters, as defined in section 14.1 of [RFC2616] as the field value of the accept request header.

In its simplest case, this is just a media type, such as "image/png" or "application/xml", but it may also contain asterisks, such as "image/*" or "*/*", or lists of acceptable media types, such as "image/png, image/gif, image/jpeg".

The user agent must combine this list with its own list of acceptable media types by taking the intersection, and then use the resulting list as the field value of the accept request header when requesting the resource using HTTP.

For instance, if the attribute specifies the value "image/png, image/gif, image/jpeg", but the user agent does not accept images of type "image/gif" then the resultant accept header would contain "image/png, image/jpeg".

A user agent must imitate similar behavior when using other methods than HTTP. For instance, when accessing files in a local filestore, <p src="logo" srctype="image/png, image/jpeg"> might cause the user agent first to look for a file logo.png, and then for logo.jpg.

If a value for the content type is not given, "*/*" must be used for its value.

For the current list of registered content types, please consult [MIMETYPES].

Coordinates Comma separated list of Lengths used in defining areas.
CURIE A Compact URI (see Compact URIs).
CURIEs One or more white space separated CURIE values
Datetime Date and time information, as defined by the type dateTime in [XMLSCHEMA] except that the timezone part is required.
HrefTarget Name used as destination for results of certain actions, with legal values as defined by NMTOKEN.
LanguageCode A language code. The values should conform to [RFC3066] or its successors.
LanguageCodes A comma-separated list of language ranges with optional q parameters, as defined in section 14.4 of [RFC2616] as the field value of the Accept-Language request header. Individual language codes should conform to [RFC3066] or its successors.
Length Either a number, representing a number of pixels, or a percentage, representing a percentage of the available horizontal or vertical space. Thus, the value "50%" means half of the available space.
LocationPath A location path as defined in [XPATH].
MediaDesc

A comma-separated list of media descriptors as described by [CSS2]. The default is all.

Number One or more digits
QName An [XMLNS]-qualified name. See QName for a formal definition.
QNames One or more white space separated QName values
Text A character string.
URI An Internationalized Resource Identifier Reference, as defined by [IRI].
URIorCURIE A URI (as defined above) or Safe Compact URI.
URIs A space-separated list of URIs as defined above.

5.6. Compact URI Syntax Definition

This section is normative.

XHTML 2 supports a mechanism by which URIs can be abbreviated, called 'compact URIs' or simply, CURIEs.

A CURIE is comprised of two components, a prefix which maps to a URI, and a reference. The prefix is separated from the reference by a colon (:). It is possible to omit the prefix, and make use of the default prefix. It is also possible to omit both the prefix and the colon, leaving just a reference.

curie       :=   [ [ prefix ] ':' ] reference

prefix      :=   NCName

reference   :=   irelative-ref (as defined in [IRI])

In some situations an attribute will allow either a CURIE, or a normal IRI. Since it is difficult to distinguish between CURIEs and IRIs, RDFa adds the notion of a [safe CURIE]. The syntax is simply to surround the CURIE with square brackets:

safe_curie  :=   '[' curie ']'

The prefix value MUST be defined using the 'xmlns:' syntax specified in [XMLNAMES].

If the prefix is omitted from a CURIE, the default value of http://www.w3.org/1999/xhtml MUST be used.

A CURIE is a representation of a full IRI. This IRI is obtained by taking the currently in-scope mapping that is associated with prefix, and concatenating it with the reference. The result MUST be a syntactically valid IRI [IRI].

5.7. Issues

Fw: [XHTML 2] Section 5.5 quality values. PR #7799
State: Open
Resolution: None
User: None

Notes:
Discussed this a bit. What we mean is that it is an intersection of media types, and that quality values in the document should take precedence. Will continue to work on this and craft wording.

Fw: [XHTML 2] Section 5.5 intersection of mime-types PR #7800
State: Open
Resolution: None
User: None

Notes: