5. Specifying XHTML Profiles

Contents

    5.1.  Framework for Content Negotiation
    5.2.  Expressing Profiles
    5.3.  Syntax for Representing XHTML Modules

This section is informative.

Modularization of XHTML provides building blocks for language, application, and platform developers. This document recognizes that, in addition to semantic modules, there exists the notion of profiles.

In addition to the definition of modules and profiles, a framework is necessary for two or more devices to negotiate when there is a mismatch in profiles supported (or required by content be transmitted).

This section focuses on modules and the process in which modules may be combined into a profile (using the document type definition language).

5.1. Framework for Content Negotiation

Content negotiation is the process in which two or more devices select content (or a set of content) to transmit from a sender to a receiver. This selection is based upon:

In the general case, a sender will transmit content to a receiver along a transmission path; this is illustrated in Figure 5-1.

Fig 5-1 -- Three elements of negotiation

Sometimes there will be a mismatch of capabilities between the sender, the content to send, and the potential receiver of the content; content negotiation is the reconciliation of these mismatches. As identified in [FRMWRK], content negotiation covers three elements:

  1. expressing the capabilities of the sender and the content to be transmitted
  2. expressing the capabilities of the receiver, and
  3. the protocol by which the capabilities are exchanged.

These elements are consistent with a broadcast scenario in which there is a uni-directional link between the originator of the content and the destination of the content, the client device; this is illustrated in Figure 5-2:

Fig 5-2 -- Unidirectional Channel

In Figure 5-2, the receiver does not have a direct connection to the sender, rather a proxy serves to represent the capabilities of the receiver. Where the proxy also has reformatting, transformation, or translation capability, the proxy's capabilities may also be represented.

As [FRMWRK] indicates, negotiation between the sender and the receiver (which may be carried out in abstentia by a proxy) consists of a series of negotiation exchanges that proceeds until either party (the sender or receiver) determines that a specific data file or content be transmitted. As Figure 5-2 illustrates, not every network architecture will support this process in a general sense, but an implementation of content negotiation should be a subset of this framework. The W3C Note on the CC/PP exchange protocol [CCPP] supports a subset of this framework that describes the capabilities and preferences associated with users and user agents accessing the World Wide Web.

The HTML Working Group will identify how the XHTML profiles can be specified (in terms of expressiveness and syntax) and the requirements placed upon an appropriate negotiation protocol.

5.2. Expressing Profiles

A profile is a collection of XHTML modules (particular to an application domain), specification of style sheet and scripting support, preferences, and other user agent and/or document properties.

Typically, a key component of the profile is a document type definition (DTD). This DTD may be represented using a URL or the profile may include the DTD itself. The problem with this approach is that if a URL is used, the actual DTD may not be available (due to network unavailability, perhaps), including the entire DTD with every document may require too much bandwidth, and a device that wishes to process the profile may not have the resources or capabilities to process a DTD.

Therefore, there is a need to define a more general purpose solution for specifying a profile's features or feature sets (the elements, attributes, and modules contained in a profile). As predicted in [FRMWRK], this solution should provide:

In some cases, multiple representations of the same data may be available (for example, this can be realized through CSS media rules or nested object elements). These multiple representations raise additional requirements, also predicted by [FRMWRK], including:

Functionally, profiles must be able to express:

Varying syntaxes may be used for representing these profiles: CC/PP [CCPP] is specifying a syntax based on RDF [RDF], [SYNTAX] proposes a syntax built upon mathematical relationships, and [SYNURL] provides extensions to [SYNTAX] for dereferencing (essentially abbreviating) the proposed syntax with URLs.

5.3. Syntax for Representing XHTML Modules

The syntax chosen for representing an XHTML Modules should satisfy the following functional requirements:

This is not a complete list of functional requirements for a content negotiation syntax -- additional functionality is required to handle declaration of variant resources (related content with different capabilities or features) and user preferences -- but these are beyond the scope of the HTML Working Group.