A Modular Hypertext Markup Language for Broadcast Applications

This specification is currently in DRAFT form. The language specified is based on work prepared for the Advanced Television Systems Committee (ATSC). The ATSC T3/S17 specialist group is in the process of defining the application programming interfaces for a Digital Television Application Software Environment (DASE) compliant receiver.

xHTML specifies a collection of document type definition (DTD) sets that can be combined to specify an xHTML-based platform. Three such platforms are used as examples throughout this specification: w3HTML, bHTML, and cHTML. The w3HTML platform provides support full World Wide Web (WWW) connectivity. The bHTML platform provides a profile for TV-centric products. The cHTML platform provides a compact profile for appliance-oriented products.

This design allows content developers to author content for a variety of platforms and for consumer electronics manufacturers to develop a range of platforms, some with full World Wide Web operability.

The ATSC technical specialist group T3/S17 is defining the software application environment for broadcast digital television (DTV) receivers. T3/S17 (also known as DASE, DTV application software environment) has identified a reference architecturethat specifies an application execution engine, presentation engine, content decoders, and other system services.

T3/S17 selected the Java virtual machine (VM) as the application execution engine. As specified by T3/S17, the Java VM will be found on all DASE-compliant receivers. Procedural applications written in Java will be able to execute on a DASE compliant receiver and access system services through Java based application programming interfaces (APIs). These system services include a presentation service that allows a Java application to draw directly to the screen.

T3/S17 also solicited proposals for the presentation engine (a declarative language machine). In the ensuing discussions, the specialist group was greatly divided between the two HTML-based proposals and a MHEG proposal. Unfortunately, the two sides of the HTML and MHEG debate were along industry lines, which did not bode well for reconciliation. The primary concerns of the consumer electronic manufacturers was that the HTML based proposals were too costly to implement, were less demonstrably integrated than the MHEG proposal, and forced consumer electronic manufacturer's to build Internet connectivity into all of their products.

This latter point is often misunderstood or under-appreciated by non-consumer electronics manufacturers. Consumer manufacturers desire to build a variety of difference products that provide a variety of functions to consumers at a variety of price points. Only by having a variety of products can the consumer electronics manufacturer's better establish a value for the price (and cost) of a feature. In addition, product differentiation between their own products and between competitor's products is quite desireable.

Aninda DasGupta, the T3/S17 chairman, proposed an alternative he called "Broadcast HTML". This alternative uses Internet technologies favored by many T3/S17 members: it is written in XML, scales back HTML elements and attributes, and integrates synchronization functionality as new elements, attributes, and style properties.

This document specifies a language that may serve as the foundation for BHTML. The language is modular so that consumer electronic manufacturer's may deliver a range of products with varying levels of Internet connectivity.

Element names are written in uppercase letters (e.g.,BODY). Attribute names are written in lowercase letters (e.g., lang). xHTML is written in XML, therefore element names are case-sensitive. On implementation, all elements and attributes will use lowercase.

While this document intends to be a full specification, many readers are solely interested in the differences between this specification and HTML 4.0. The differences are summarized in the following sections:

This specification has had contributions and critiques from a number of individuals. A special thanks to Joseph Cozad (Motorola), Aninda DasGupta (Philips), Warner ten Kate (Philips), Chris Marrin (Sony), Petr Peterka (General Instruments), Dave Raggett (Hewlett-Packard and the W3C), Dave Reynolds (Hewlett-Packard), and David Rivas (Sun).

THIS DOCUMENT IS PROVIDED "AS IS," AND COPYRIGHT HOLDERS MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT THE CONTENTS OF THE DOCUMENT ARE SUITABLE FOR ANY PURPOSE; NOR THAT THE IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS. COPYRIGHT HOLDERS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF ANY USE OF THE DOCUMENT OR THE PERFORMANCE OR IMPLEMENTATION OF THE CONTENTS THEREOF.

The name and trademarks of copyright holders may NOT be used in advertising or publicity pertaining to this document or its contents without specific, written prior permission. Title to copyright in this document will at all times remain with copyright holders.

Throughout this document, three profiles of xHTML will be used as examples of how to apply the modular HTML concept:

w3HTML (World Wide Web HTML)

bHTML (Broadcast HTML)

cHTML (Compact HTML)

Each of these profiles differs by the DTD sets it includes and, to a lesser degree, the elements in a DTD set that it supports. The author would prefer that they only differed in terms of the DTD sets they support, but experience suggests that some tailoring of the elements is often required or appropriate due to platform novelties.

While not addressed in this document, a similar subset-ing and profiling should occur regarding style information. xHTML assumes support for external style information (such as cascading style sheets). Subsequently, xHMTL has reduced the amount of style information specified through attributes.

The bHTML profile does not support the docset, frameset, or tableset. In addition, there are some minor changes in the elements supported. For example, bHTML only supports the first three levels of headings (H1, H2, and H3).

The bHTML profile described in this document is based on the "Broadcast HTML" proposal currently under evaluation by the ATSC T3/S17 DASE specialist group.

xHTML is designed to meet the requirements of consumer electronic and computer manufacturers that wish to produce a broad range of products with various levels of Internet connectivity and product features. It is designed based on the following five principals.

Based on the strategic directions taken by the W3C.

xHTML started with HTML 4.0 and HTML 3.2. These elements and attributes were converted to XML, in line with the stated goals of the W3C for future HTML. Then, elements and attributes were added as necessary to meet the needs of interactive television applications, and elements and attributes that were redundant (with other HTML elements and attributes or style information) were removed.

Modular design.

The XML-based markup language was partitioned into DTD sets that correlated with the needs of platform developers to differentiated based on internet connectivity, memory footprint, and power management.

Can be viewed on a range of display types.

One of the greatest differences between consumer electronics platforms is the nature of the display devices. Computers typically display on a progressive scan monitor, set-top boxes typically display on a interlaced television, and information appliances typically display on a small black and white LCD.

Can be easily operated by the users.

In addition to different display devices, platforms typically differ based on the how the user interacts. Computers typically have a mouse and a full function keyboard, set-top boxes typically have a remote control with constrained navigation keys or cursors, and information appliances have fewer navigation keys still.

Various levels of Internet connectivity.

Consumer electronics manufacturers would like to deliver a range of products. Some of these devices will have no return channel to the Internet. Other devices many only have a "batch" mode return to the Internet. Still other will have full-time real-time Internet connectivity. xHTML was designed to support these different levels of Internet connectivity.

which reflects that the bHTML profile does not support the Docset elements (sub, span, and bdo) and the cHTML profile does not support the Eventset and Fontset elements.

See Appendix A for the core DTD entities, elements, and attributes. The contents of the appendix and the contents of Appendix B define the Broadcast HTML DTD; likewise with Appendix C for the Compact HTML DTD and Appendix D for the w3HTML DTD.

The Coreset elements are those elements supported by all xHTML profiles. They generally consist of elements related to the global structure of a xHTML document, hyperlinking, and embedded content (objects).

The class attribute assigns a class name or set of class names to an element. The class name can be used to associate style information to one or more elements. In the following example, the DIV element and the class attribute are used to render and synchronize a document:

Unlike the TITLE element defined below, which provides information about an entire document and may only appear once, the title attribute may annotate any number of elements.

Values of the title attribute may be rendered by user agents in a variety of ways. For instance, visual browsers frequently display the title information as a "tool tip" (a short message that appears when the pointing device pauses over an object).

The style attribute specifies style information for a single element. The style sheet language of inline style rules is given by the default style sheet language. The syntax of style data depends on the style sheet language.

The lang attribute's value is a language code that identifies a natural language spoken, written, or otherwise used for the communication among people. Computer languages are explicitly excluded from language codes.

The dir attribute specifies the base direction of neutral text (i.e., text that does not have inherent directionality as defined in UNICODE and the directionality of tables).

In addition to specifying the language of a document with the lang attribute, content develoeprs may need to specify the base directionality (left-to-right or right-to-left) of portions of a document's text, of table structure, etc. This is done with the dir attribute.

The Unicode specification assigns directionality to characters and defines a (complex) algorithm for determining the proper directionality of text. If a document does not contain a displayable right-to-left character, a conforming user agent is not required to apply the Unicode bidirectional algorithm. If a document contains right-to-left characters, and if the user agent displays these characters, the user agent must use the bidirectional algorithm.

Although Unicode specifies special characters that deal with text direction, xHTML offers higher-level markup constructs that do the same thing: the dir attribute (do not confuse with the DIR element) and the BDO element. Thus, to express a Hebrew quotation, it is more intuitive to write

specifies the character encoding of the resource designated by the link.

type

specifies the content type of a piece of content as a result of dereferencing the URI.

name

specifies the current anchor so that it may be the destination of another link. The value of this attribute must be a unique anchor name. The scope of this name is the current document. Note that this attribute shares the same name space as the id attribute.

href

specifies the location of a resource, thus defining a link between the current element (the source anchor) and the destination defined by the attribute.

hreflang

specifies the base language of the destination resource. This attribute may only be used when the href is specified.

rel

describes the relationship from the current document to the anchor specified by the href attribute. The value of this attribute is a space-separated list of link types.

rev

describes the relationship from the anchor specified by the href attribute to the current document. The value of this attribute is a space-separated list of link types.

restrict

provides a hint to the user agent to limit the linking from destination resources.

The name attribute names the anchor so that it may be the destination of zero or more links.

The href attribute makes this anchor the source anchor of exactly one link.

Content developers may also create an A element that specifies no anchors, i.e., that doesn't specify href, name, or id. Values for these attributes may be set at a later time through procedural applications.

Style sheets can be used to associate a hyperlink to spatial subparts of an element. For example:

the video object is divided into two subintervals with a different hyperlink associated with each subinterval. The style properties are described in Appendix D, Broadcast Style Sheets.

Visiting a linked resource

The default behavior associated with a link is the retrieval or downloading of another xHTML related resource. This behavior is commonly and implicitely obtained by selecting the link (e.g., by clicking, through the remote control, keyboard input, etc.). The EVENT element also provides a mechanism for linking in response to events.

The following xHTML expert contains two links, one whose destination anchor is a xHTML document named "scene2.html" and the other whose destination anchor is a GIF image in the file "forest.gif":

<body&gt
...some text...
<p>You find a lot more in <a href="scene2.html">chapter two</a>. See also this <a href="../images/forest.gif">map of the enchanted forest.</a></p&gt

By activating these links, users may visit these resources. Note that the href attribute in each source anchor specifies the address of the destination anchor with a URI.

The destination anchor of a link may be an element within a xHTML document. The destination anchor must be given an anchor name and any URI addressing this anchor must include the name as its fragment identifier.

Destination anchors in xHTML documents may be specified either by the A element (naming it with the name attribute) or by any other element (naming with the id attribute).

Thus, for example, an author might create a table of contents whose entries link to header elements H2, H3, etc., in the same document. Using the A element to create destination anchors, we would write:

Other link relationships

By far the most common use of a link is to retrieve another xHTML related resource, as illustrated in the previous examples. However, content developers may insert links in their documents that express other relationships between resources than simply "activate this link to visit that related resource". Links that express other types of relationships have one or more link types specified in their source anchor.

The roles of a link defined by A or LINK are specified via the rel and rev attributes.

For instance, links defined by the LINK element may describe the position of a presentation within a series of presentations (much like a collection of scenes). In the following excerpt, links within the presentation entitled "Scene 5" point to the previous and next scenes:

The link type of the first link is "prev" and that of the second is "next" (two of several recognized link types). Links specified by LINK are not rendered with the document's contents, although user agents may render them in other ways (e.g., as navigation tools).

Even if they are not used for navigation, these links may be interpreted in interesting ways. For example, a user agent might pre-load adjacent documents in order to improve perceived performance.

Retrieving resources

The retrieved resource may be handled by the user agent in several ways: by opening a new xHTML document in the same user agent window, opening a new xHTML document in a different window, starting a new program to handle the resource, etc. This behavior is generally specified by the xHTML profile. Since the A element has content (text, images, etc.), user agents may render this content in such a way as to indicate the presence of a link (e.g., by underlining the content).

Link titles

The title attribute may be set for A and LINK to add information about the nature of a link. This information may be spoken by a user agent, rendered as a tool tip, cause a change in cursor image, etc.

Thus, we may augment a previous example by supplying a title for each link:

Internationalization and links

Since links may point to documents encoded with different character encodings, the A and LINK elements support the charset attribute. This attribute allows authors to advise user agents about the encoding of data at the other end of the link.

The hreflang attribute provides user agents with information about the language of a resource at the end of a link, just as the lang attribute provides information about the language of an element's content or attribute values.

Armed with this additional knowledge, user agents should be able to avoid presenting "garbage" to the user. Instead, they may either locate resources necessary for the correct presentation of the document or, if they cannot locate the resources, they should at least warn the user that the document will be unreadable and explain the cause.

The BLOCKQUOTE element designates quoted text. This example formats an excerpt from "Pieces of Time", by Peter Bogdanovich, as a blockquote.

<blockquote cite="http://www.mycom.com/bogdanovich/piecesoftime/bogart.html"&gt
<p>His death came in the early morning and that day the papers carried
the news to the world. Most of the reports were similar. Quite a few of
them told it this way: "Usually he kissed his wife Lauren Bacall and said,
'Good night.' But according to Dr. Michael Flynn, this time he put his hand
on her hand and murmered in his familiar brusque fashion, 'Good-bye, kid.'"</p&gt
</blockquote&gt

The DIV element, in conjunction with the id and class atributes, offers a generic mechanism for adding structure to documents.

Together with the SPAN element, these elements define content to be inline (SPAN) or block-level (DIV), but impose no presentational idioms on the content. Thus, content developers may use these elements in conjunction with style sheets to tailor xHTML to their needs and tastes. Extremely minimal xHTML profiles may provide support for very few structure-related elements, using the DIV and SPAN with absolute positioning to define presentations.

Suppose, for example, that we wanted to generate a document based on a database of movie star information. Since xHTML does not include elements that identify objects such as "actor", "birthdate", etc. we use DIV and SPAN to achieve the desired structural and presentation effects:

The HEAD element contains information about the current document, such as the title, keywords, and other data not considered document content. User agents generally do not render information that appears in the HEAD as content. They may make this information available to users through other mechanisms.

A heading element briefly describes the topic of the section it introduces. The following example shows how to use the DIV element to associate a heading with the document section that follows. Doing so allows the content developer to define a style for the section (color for the background, set the font, etc.) with style sheets.

<div class="section" id="talkies"&gt
<h1>Talkies</h1&gt
<p>Now I'm in Hollywood -- staring in disbelief at Grauman's
Chinese, trying to understand those funny-looking trees -- and it's
all true, everything I'd heard, all the cliches. They make airplanes
out here, and missiles. But, above all, they make movies.</p&gt
</div&gt
<div class="subsection" id="on-hitchcock"&gt
<h2>Alfred Hitchcock</h2&gt
<p>One of my first interviews was with Alfred Hitchcock, the
director, who ushered me gingerly into his expansive office at
Paramount Pictures; he was wearing a dark suit, white shirt, dark
tie, holding a large cigar, and looking very heavy indeed.</p&gt
</div&gt

This structure may be decorated with style information such that each section has a different text alignment and font size.

This element specifies a link. Unlike the A element, it may only appear in the document head, although it may appear any number of times. This example illustrates how several LINK elements may appear in the HEAD section of the document. The current document is "scene2.html".

The link types may be used by user agents in a variety of ways. While several link types are listed below, these types may be significantly tailored to the xHTML profile. Additional information on linking is provided in the section on the A element.

Link Types

Authors may use the following recognized link types, listed here with their conventional interpretations. These link types are case-insensitive, i.e., "Alternate" has the same meaning as "alternate".

User agents, search engines, etc. may interpret these link types in a variety of ways. For example, user agents may provide access to linked documents through a navigation bar.

Alternate

Designates substitute versions for the document in which the link occurs. When used together with the lang attribute, it implies a translated version of the document.

Stylesheet

Refers to an external style sheet. See the section on external style sheets for details. This is used together with the link type "Alternate" for user-selectable alternate style sheets.

Start

Refers to the first document in a collection of documents. This link type tells search engines which document is considered by the author to be the starting point of the collection.

Next

Refers to the next document in an linear sequence of documents. User agents may choose to preload the "next" document, to reduce the perceived load time.

Prev

Refers to the previous document in an ordered series of documents.

Contents

Refers to a document serving as a table of contents.

Index

Refers to a document providing an index for the current document.

Glossary

Refers to a document providing a glossary of terms that pertain to the current document.

Copyright

Refers to a copyright statement for the current document.

Chapter

Refers to a document serving as a chapter in a collection of documents.

Section

Refers to a document serving as a section in a collection of documents.

Subsection

Refers to a document serving as a subsection in a collection of documents.

Appendix

Refers to a document serving as an appendix in a collection of documents.

Help

Refers to a document offering help (more information, links to other sourcesinformation, etc.)

Bookmark

Refers to a bookmark. A bookmark is a link to a key entry point within an extended document. The title attribute may be used, for example, to label the bookmark. Note that several bookmarks may be defined in each document.

The META element can be used to identify properties of a document (e.g., author, expiration date, a list of key words, etc.) and assign values to those properties. This specification does not define a normative set of properties.

Each META element specifies a property/value pair. The name attribute identifies the property and the content attribute specifies the property's value.

For example, the following declaration sets a value for the Author property:

When present, this boolean attribute makes the current OBJECT definition a declaration only. The object must be instantiated by a subsequent OBJECT definition referring to this declaration.

classid

Specifies the location of an object's implementation via a URI. It may be used together with, or as an alternative to the data attribute, depending on the type of object. In the case of bHTML, this attribute may be used if the required content decoder is not available on the receiver.

codebase

Specifies the base path used to resolve relative URIs specified by the classid, data, and archive attributes. When absent, the default value is the base URI of the current document (see the BASE element).

data

Specifies the location of the object's data. For instance, this is the location of the image for an object defining images.

type

Specifies the content type for the data specified by the data attribute. This attribute is optional but recommended when data is specified. The type attribute allows a user agent to avoid loading information for unsupported content types.

codetype

Specifies the content type of data expected when downloading the object specified by the classid. As with the type attribute, this attribute is optional but recommended when the classid is specified.

archive

Specifies a space-separated list of URIs that contain resources relevant to the object. Preloading archives will generally result in reduced load times for objects.

standby

Specifies a message that a user agent may render while loading the object's implementation and data.

resources

Specifies the buffer and resource requirements needed by the content decoder. The content decoder may use information to determine whether it is capable of handling the decode session. The resource attribute differs from the TEST element. The resource attribute puts the burden on the content decoder to determine whether or how to render the object. The TEST element places the burden on the user agent to determine whether to invoke the content decoder.

remain

Specifies a space-separated list of URIs on which this object persists. See persistent objects, below.

xHTML uses the OBJECT element as an all-purpose solution to generic object inclusion. While media-specific names could certainly be used to add clarity in reading a xHTML file, only the OBJECT element is used in this specification. Media-specific elements (such as "audio" and "image") have limited usefulness when many media types are complex (a combination of one or more "mono" media).

The OBJECT, along with the PARAM element, allows xHTML content developers to specify everything required by an object for its presentation by a user agent: source code location, initial values, and run-time data.

A user agent must interpret an OBJECT element according to the following precedence rules:

The user agent must first determine if the object is persistent (see persistent objects, below). If the object is persistent it must send an update to the appropriate content decoder.

If the object is not persistent, the user agent must try to render the object. It should not render the element's contents, but it must examine them in case the element contains any direct children that are a PARAM or A elements.

If the user agent is not able to render the object for whatever reason (configured not to, lack of resources, wrong architecture, etc.), it must try to render its contents.

In the following example, an analog clock program is inserted into a bHTML document via the OBJECT element. The clock program requires no additional data or run-time values. The classid attribute specifies the location of the program (using a proposed digital TV URL naming scheme):

<p><object classid="dtv:/1234/009F/data"/></p&gt

In this example, the clock will be rendered as soon as the user agent interprets the OBJECT declaration and loads the data. It is possible to delay the rendering of an object by using media synchronization style sheet properties.

The remain attribute may be used to specify a list of URIs on which this object remains persistent. The destination location must still define or declare the object with the same id attribute, otherwise the object will not persist. The content decoder will be notified that the document page changed (through an update) and will be providing the initialization parameters. In general,it is the responsibility of the content decoder to respond to the initialization parameters as appropriate to the content type.

Document-centric content developers traditionally divide their thoughts and arguments into sequences or paragraphs. The organization of information into paragraphs is not affected by how the paragraphs are presented: paragraphs that are double-justified contain the same thoughts as those that are left-justified.

In xHTML, the P element defines a paragraph. While this may be simple, the visual presentation of paragraphs is not so simple. A number of issues, both technical and stylistic, must be addressed:

Treatment of white space

Line breaking and word wrapping

Hyphenation

Written language conventions and text directionality

Justification

Formatting of paragraphs with respect to surrounding content

The first of these issues are addressed in the following paragraphs. Written language conventions are addressed with the lang and dir attributes. Justification and formatting of paragraphs is discussed in the appendix on style sheets

The document character set includes a wide variety of white space characters. Many of these are typographic elements used in some applications to produce particular visual spacing effects. In xHTML, only the following characters are defined as white characters:

ASCII space (&#x0020;)

ASCII tab (&#x0009;)

ASCII form feed (&#x000C;)

Zero-width space (&#x200B;)

Line breaks are also white space characters. Note that although &#x2028; and &#x2029; are defined in[ISO10646] to unambiguously separate lines and paragraphs, respectively, these do not constitute line breaks in xHTML, nor does this specification include them in the more general category of white space characters.

This specification does not indicate the behavior, rendering or otherwise, of space characters other than those explicitly identified here as white space characters. For this reason, authors should use appropriate elements and styles to achieve visual formatting effects that involve white space, rather than space characters.

For all xHTML elements except PRE, sequences of white space separate "words" (we use the term "word" here to mean "sequences of non-white space characters"). When formatting text, user agents should identify these words and lay them out according to the conventions of the particular written language (script) and target medium.

This layout may involve putting space between words (called inter-word space), but conventions for inter-word space vary from script to script. For example, in Latin scripts, inter-word space is typically rendered as an ASCII space (&#x0020;), while in Thai it is a zero-width word separator (&#x200B;). In Japanese and Chinese, inter-word space is not typically rendered at all.

Note that a sequence of white spaces between words in the source document may result in an entirely different rendered inter-word spacing (except in the case of the PRE element). In particular, user agents should collapse input white space sequences when producing output inter-word space. This can and should be done even in the absence of language information (from the lang attribute, the HTTP "Content-Language" header field (see [RFC2068], section 14.13), user agent settings, etc.).

The PRE element is used for preformatted text, where white space is significant.

A line break is defined to be a carriage return (?x000D;), a line feed (?x000A;), or a carriage return and line feed pair. All line breaks constitute white space.

Sometimes content developers will want to force a line break or prohibit a line break. The BR element is used to force a line break. The &nbsp; entity (&#160; or &#xA0;) acts as a space where user agents should not cause a line break.

Tthere are two types of hyphens: the plain hyphen and the soft hyphen. The plain hyphen should be interpreted by a user agent as just another character. The soft hyphen tells the user agent where a line break can occur.

Those browsers that interpret soft hyphens must observe the following semantics: If a line is broken at a soft hyphen, a hyphen character must be displayed at the end of the first line. If a line is not broken at a soft hyphen, the user agent must not display a hyphen character. For operations such as searching and sorting, the soft hyphen should always be ignored.

The plain hyphen is represented by the "-" character (&#45; or &#x2D;). The soft hyphen is represented by the character entity reference &shy; (&#173; or &#xAD;)

Assigns a name to the element. The PARAM element's id attribute shares the same namespace and constraints as the id specified previously.

name

Defines the name of a run-time parameter, assumed to be known by the inserted object or inserted object's content decoder. Whether the property name is case-sensitive depends on the specific object (or content decoder) implementation.

value

Specifies the value of a run-time parameter defined by the name attribute. Propety values have no meaning to xHTML; their meaning is determined by the object or content decoder in question.

valuetype

Specifies the type of the value attribute. Possible values include:

data: This is the default value for the valuetype attribute. It means that the value specified by the value attribute will be evaluated and passed to the object;s implementation as a string.

ref: The value specified is a URI that designates a reference where run-time values are stored. The URI must be passed to the object as is (i.e., unresolved).

object: The value specified is an identifier that refers to a OBJECT declaration in the same document. The identifier must be the value of the id attribute set for the declared OBJECT element.

type

Specifies the content type for the resource designated by the value attribute only in the case where valuetype is set to "ref". This attribute thus specifies for the user agent, the type of values that will be found at the URI designated by value.

PARAM elements specify a set of values that may be required by an object for initialization at run-time. Any number of PARAM elements may appear in the content of an OBJECT element, in any order, but must be placed at the start of the content of the enclosing OBJECT element. If the object was initialized on a previous document and is persistent (through the remain attribute), the object is not reinitialized.

The SPAN elements, in conjunction with the id and class attributes, offesr a generic mechanism for adding structure to documents.

Together with the DIV element, these elements define content to be inline (SPAN) or block-level (DIV), but impose no presentational idioms on the content. Thus, content developers may use these elements in conjunction with style sheets to tailor xHTML to their needs and tastes. Extremely minimal xHTML profiles may provide support for very few structure-related elements, using the DIV and SPAN with absolute positioning to define presentations. See the DIV element for additional information and examples of its usage.

specifies the style sheet language of the element's contents and overrides the default style sheet language. The style sheet language is specified as a content type (e.g., "text/bss"). Authors must supply a value for this attribute; there is no default value for this attribute. The bHTML profile only supports the "text/bss" value.

media

specifies the intended destination medium for style information. It may be a single media descriptor or a comma-separated list. The default value for this attribute is "screen".

Although style information may be set for almost every xHTML element, two elements, DIV and SPAN are particularly useful in that they do not impose any presentation semantics (besides block level vs. inline).

When combined with style sheets, these elements allow content developers to extend xHTML indefinitely, particularly when used with the class and id attributes.

In the following example, the DIV and the class attribute are used to set the text justification for a series of paragraphs that make up the abstract section of a scientific article. This style information could be reused for other abstract sections by setting the class attribute elsewhere in the document.

The SWITCH element is used by a content developer to specify alternative presentations. The SWITCH element, based on the SMIL 1.0 element of the same name, is used to specify a set of alternative elements from which only one acceptable element should be chosen. An element is acceptable if the content type can be decoded and all of the TEST elements evaluate to true.

As in SMIL 1.0, the elements are evaluated in the order in which they appear in the SWITCH element. The first acceptable element is selected at the exclusion of all other elements within the SWITCH.

The intended use of the SWITCH element in xHTML is different than that intended for syle sheets. Content developers use style sheets to control how content is rendered on a display; content developers use the SWITCH element to control what content is rendered on the display. For example:

On high profile DASE receivers, the "a" object is rendered, then the "c" object is rendered, and finally the "f" object. On main profile DASE receivers, the "d" object is rendered after the "a" object, followed by the "f" object. On all other platforms, the "e" object is rendered after the "a" object, followed by the "f" object.

The TEST element is a child of the SWITCH and is used to test a platform's capabilities and settings. If the test passes, the encapsulated object should be rendered. This is similar to the SMIL 1.0 attribute of the same name. It is provided in xHTML as an element in order to provide greater extensibility for varying xHTML profiles.

In bHTML, the TEST element can have the following values for the name attribute:

system-captions

specifies whether the user has indicated a preference to see closed captioning type information.

The TITLE element is not considered part of the flow of text and should only be displayed, for example, as the page header or window title. Exactly one title is required per document. Every xHTML document, must have a TITLE element in the HEAD.

Content developers should use the TITLE element to identify the contents of a presentation. Since users often view presentations out of context, content developers should provide context-rich titles. Thus, instead of a title such as "Commercial", which doesn't provide much contextual background, content developers should supply a title such as "Free Coca-Cola T-Shirt" instead.

Titles may contain character entities (for accented characters, special characters, etc.) but may not contain other markup. Here is an example title:

The ABBR and ACRONYM elements allow authors to clearly indicate occurrences of abbreviations and acronyms. Western languages make extensive use of acronyms such as "GmbH", "NATO", and "F.B.I.", as well as abbreviations like "M.", "Inc.", "et al.", "etc.". Both Chinese and Japanese use analogous abbreviation mechanisms, wherein a long name is referred to subsequently with a subset of the Han characters from the original occurrence. Marking up these constructs provides useful information to user agents and tools such as spell checkers, speech synthesizers, translation systems and search-engine indexers.

The content of the ABBR and ACRONYM elements specifies the abbreviated expression itself, as it would normally appear in running text. The title attribute of these elements may be used to provide the full or expanded form of the expression.

Note that abbreviations and acronyms often have idiosyncratic pronunciations. For example, while "IRS" and "BBC" are typically pronounced letter by letter, "NATO" and "UNESCO" are pronounced phonetically. Still other abbreviated forms (e.g., "URI" and "SQL") are spelled out by some people and pronounced as words by other people. When necessary, authors should use style sheets to specify the pronunciation of an abbreviated form.

The bidirectional algorithm and the dir attribute generally suffice to manage embedded direction changes. However, some situations may arise when the bidirectional algorithm results in incorrect presentation. The BDO element allows authors to turn off the bidirectional algorithm for selected fragments of text.

Consider a document containing the text:

english1 HEBREW2 english3 HEBREW4 english5 HEBREW6

but assume that this text has already been put in visual order. One reason for this may be that the MIME standard favors visual order, i.e., that right-to-left character sequences are inserted right-to-left in the byte stream. In an email, the above might be formatted, including line breaks, as:

english1 2WERBEH english3
4WERBEH english5 6WERBEH

This conflicts with the UNICODE bidirectional algorithm, because that algorithm would invert 2WERBEH, 4WERBEH, and 6WERBEH a second time, displaying the Hebrew words left-to-right instead of right-to-left.

The solution in this case is to override the bidirectional algorithm by putting the Email excerpt in a PRE element (to conserve line breaks) and each line in a BDO element, whose dir attribute is set to LTR:

This tells the bidirectional algorithm "Leave me left-to-right!" and would produce the desired presentation:

english1 2WERBEH english3
4WERBEH english5 6WERBEH

The BDO element should be used in scenarios where absolute control over sequence order is required (e.g., multi-language part numbers). The dir attribute is mandatory for this element. More details on the BDO element may be found in the HTML 4.0 specification.

The INS and DEL elements are used to markup sections of the document that have been inserted or deleted with respect to a different version of a document (e.g., in draft legislation where lawmakers need to view the changes).

These two elements are unusual for xHTML in that they may serve as either block-level or inline elements (but not both). They may contain one or more words within a paragraph or contain one or more block-level elements such as paragraphs, lists and tables.

This example could be from a bill to change the legislation for how many deputies a County Sheriff can employ from 3 to 5.

<p&gt
A Sheriff can employ <del>3</del<>ins>5</ins> deputies.
</p&gt

The INS and DEL elements must not contain block-level content when these elements behave as inline elements.

ILLEGAL EXAMPLE:
The following is not legal HTML.
<p&gt
<del><div>...block-level content...</div></del&gt
</p&gt

User agents should render inserted and deleted text in ways that make the change obvious. For instance, inserted text may appear in a special font, deleted text may not be shown at all or be shown as struck-through or with special markings, etc.

The INS and DEL elements must not contain block-level content when these elements behave as inline elements. See the DEL element for an example.

User agents should render inserted and deleted text in ways that make the change obvious. For instance, inserted text may appear in a special font, deleted text may not be shown at all or be shown as struck-through or with special markings, etc.

Both of the following examples correspond to November 5, 1994, 8:15:30 am, US Eastern Standard Time.

1994-11-05T13:15:30Z
1994-11-05T08:15:30-05:00

Used with ins, this gives:

<ins datetime="1994-11-05T08:15:30-05:00"
cite="http://www.foo.org/mydoc/comments.html"&gt
Furthermore, the latest figures from the marketing department
suggest that such practice is on the rise.
</ins&gt

The document "http://www.foo.org/mydoc/comments.html" would contain comments about why information was inserted into the document.

Authors may also make comments about inserted or deleted text by means of the title attribute for the INS and DEL elements. User agents may present this information to the user (e.g., as a popup note). For example:

<ins datetime="1994-11-05T08:15:30-05:00"
title="Changed as a result of Steve B's comments in meeting."&gt
Furthermore, the latest figures from the marketing department
suggest that such practice is on the rise.
</ins&gt

The ACTION element may be used to specify the behavior that occurs in response to an event. An xHTML profile, such as bHTML, may limit the languages that may be used for writing a behavior. For example, in bHTML, only Java may be used for external procedural behaviors.

A function that responds to an "onClick" event may be identified in a manner similar to:

The EVENT element defines a block of behaviors that respond to an event. The events that are available to the system are defined by the profile of the system. In addition, custom events can be encoded through the name attribute. This allows external procedural codes to "insert" events through the document object model (DOM) and trigger behaviors encoded in the xHTML document.

The following bHTML example describes two behaviors. When the channel changes, the "showObject" function is called. When the user clicks on the object, the "hideObject" function is called.

Links may also be associated with a EVENT element. When a link, through the A element, is associated with an event, it is automatically visited when the encapsulating event occurs. For example, when the content decoder reaches the end of the media stream, the user agent hyperlinks to the next xHTML resource.

The NOACTION element allows authors to provide alternate content when procedural code or script is not executed. The content of a NOACTION element should only rendered by an action-aware user agent in the following cases:

The user agent is configured not to evaluate scripts.

The user agent doesn't support a scripting language invoked by a SCRIPT element earlier in the document.

User agents that do not support client-side procedural code or scripts must render this element's contents.

In the following example, a user agent that executes the ACTION will include some dynamically created data in the document. If the user agent doesn't support actions, the user may still retrieve the data through a link.

The ADDRESS element may be used by content developers to supply contact information for document or a major part of a document such as a form. This element often appears at the beginning or end of a document.

The EM element may be used to add structural information to text fragments. Specifically, the EM element is used to indicate an emphasis.

The presentation of phrase elements depends on the user agent. xHTML profiles may specify a particular presentation for compliance. For example, the bHTML profile specifies that text fragments encapsulated by the EM element be italicized.

The KBD element is used to indicate text, keyboard, or remote control keys that are entered by the user.

The presentation of phrase elements depends on the user agent. xHTML profiles may specify a particular presentation for compliance. For example, the bHTML profile specifies that text encapsulated by the KBD element be rendered with a fixed-pitch font.

The STRONG element is used to indicate text with a stronger emphasis than that indicated by the EM element.

The presentation of phrase elements depends on the user agent. xHTML profiles may specify a particular presentation for compliance. For example, the bHTML profile specifies that text encapsulated by the STRONG element be rendered in a bold font.

The Formset elements are those elements pertaining to profiles that support interactive forms. These forms may interact with a server through a return channel, or the server may be located on the same platform.

The FIELDSET element allows content developers to group thematically related controls and labels. Grouping controls makes it easier for users to understand their purpose while simultaneously facilitating tabbing navigation for visual user agents and speech navigation for speech oriented user agents. The proper use of this element makes documents more accessible.

In this example, we create a form that one might fill out at the doctor's office. It is divided into three sections: personal information, medical history, and current medication. Each section contains controls for inputting the appropriate information.

specifies a form processing agent. For example, the value might be a HTTP URI, Java interface (to submit the form to a client program), or a mailto URI (to email the form through a return channel).

method

specifies which HTTP method willbe used to submit the form data set. Possible (case-insensitive) values are "get" (the default) and "post".

enctype

specifies the content type used to submit the form to the "server" (when the value of the method attribute is "post"). The default value for this atribute is "application/x-www-form-urlencoded".

accept-charset

specifies the list of character encodings for input data that must be accepted by the server processing this form. The value is a space-delimited or comma-delimited list of charset values. The server must interpret this list as an exclusive-or list. In other words, the server must be able to accept any single character encoding per entity received. The default value for this attribute is the reserved string "UNKNOWN". User agents may interpret this value as the character encoding that was used to transmit the document containing this FORM element.

specifies the type of control to create. The default value for this attribute is "text".

name

assigns the control name

value

specifies the initial value of the control. It is optional except when the type attribute is "radio".

checked

specifies that the button is on when the type attribute has the value "radio" or "checkbox". User agents must ignore this attribute for other controls.

disabled

specifies that this element is disabled.

readonly

specifies that this element is readonly.

size

specifies the initial width of the control. The width is given in pixels except when the type attribute has the value "text" or "password". In this case, its value refers to the (integer) number of characters.

maxlength

specifies the maximum number of characters the user may enter when the type attribute has the value "text" or "password". This number may exceed the specified size, in which case the user agent should offera scrolling mechanism. The default value for thisattribute is an unlimited number.

src

specifies the location of the image to be used to decorate the graphical submit button when the type attribute has the value of "image."

accept

specifies a comma-separated list of content types that a server processing this form will handle correctly.

The control type defined by the INPUT element depends on the value of the type attribute:

"text"

creates a single-line text input control.

"password"

is similar to "text", but the input text is rendered in such a way as to hide the characters (e.g., a series of asterisks). This control type is often used for sensitive input such as passwords. Note that the current value is the text entered by the user, not the text rendered by the user agent.

"checkbox"

creates a checkbox.

"radio"

creates a radio button.

"submit"

creates a submit button.

"image"

creates a graphical submit button. The value of the src attribute specifies the URI of the image that will decorate the button. For accessiblity reasons, content developers should provide alternate text for the image via the title attribute.

When a pointing device is used to click on the image, the form is submitted and the click coordinates passed to the server or server process. The x value is measured in pixels from the left of the image, and the y value in pixels from the top of the image. The submitted data includes:

name.x=x-value

and

name.y=y-value

where "name" is the value of the name attribute, and the "x-value" and "y-value" are the x and y coordinate values, respectively.

"reset"

creates a reset button.

"button"

creates a push button. User agents should use the value of the value attribute as the button's label.

"hidden"

creates a hidden control.

The following sample xHTML fragment defines a simple form that allows the user to enter a first name, last name, email address, and gender. When the submit button is activated, the form will be sent to the program specified by the action attribute.

explicitely associates the label being defined with another control. When present, the value of this attribute must be the same as the value of the id attribute of some other control on the same document. When absent, the label being defined is associated with the element's contents.

The LABEL element may be used to attach information to controls. Each LABEL element is associated with exactly one form control.

Labels may be associated with a control either explicitly or implicitly. The for attribute explicitly associates a label with another control. The value of the for attribute must be the same as the value of the id attribute of the associated control element. More than one LABEL may be associated with the same control by creating multiple references via the for attribute.

To associate a label with another control implicitly, the control element must be encapsulated by the LABEL element. In this case, the LABEL may only contain one control element. The label itself may be positioned before or after the associated control.

In this example, we implicitly assocate two labels with two text input controls:

The OPTGROUP element allows content developers to group choices logically. This is particularly helpful when the user must choose from a logn list of options; groups of related choices are easier to grasp and remember than a single long list of options. In xHTML, all OPTGROUP elements must be specified directly within a SELECT element (i.e., groups may not be nested).

The label attribute of the OPTGROUP element specifies the label for a group of choices. For example:

specifies a shorter label for an option than the content of the OPTION element. When specified, user agents should use the value of this attribute rather than the content of the OPTION element as the option label.

value

specifies the initial value of the control. If this attribute is not set, the initial value is set to the contents of the OPTION element.

When rendering a menu choice, user agents should use the value of label attribute of the OPTION element as the choice. If this attribute is not specified, user agents should use the contents of the OPTION element.

In this example, we create a menu that allows the user to select which of seven software components to install. The first and second components are pre-selected but may be deselected by the user. The remaining components are not pre-selected. The size attribute states that the menu should only have 4 rows even though the user may select from among 7 options. The other options should be made available through a scrolling mechanism.

If a SELECT element is presented as a scrolled list box, this attribute specifies the number of rows in the list that should be visible at the same time. Visual user agents are not required to present a SELECT element as a list box; they may use any other mechanism, such as a drop-down menu. xHTML profiles, on the other hand, may be more specific.

multiple

allows multiple selections. If not set, the SELECT element only permits single selections.

Only selected options will be successful (using the control name "compont-select"). Note that where the value attribute is set, it determines the control's initial value, otherwise it's the element's contents.

specifies the number of visible text lines. Users should be able to enter more lines than this, so user agents should provide some means to scroll through the contents ofthe control when the contents extend beyond the visible area.

cols

specifies the visible width in average character widths. Users should be able toenter longer lines than this, so user agents ahould provide some means to scroll through the contents of the control when the contents extend beyond the visible area. User agents may wrap visible text lines to keep long lines visible without the need for scrolling.

Setting the readonly attribute allows content developers to display unmodified text in a TEXTAREA. This differs from using standard marked-up text in a document because the value of the TEXTAREA is submitted with the form.

specifies a link to a long description of the frame. This description should supplement the short description provided using the title attribute, and may be particularly useful for non-visual user agents.

name

specifies a name for the current frame. This name may be used as the target for subsequent links.

src

specifies the location of the initial contents to be contained in the frame.

noresize

When present, this boolean attribute tells the user agent that the frame window must not be resizeable.

The FRAMESET element specifies the layout of the main user window in terms of rectangular subspaces.

Rows and columns

Setting the rows attribute defines the number of horizontal subspaces in a frameset. Setting the cols attribute defines the number of vertical subspaces. Both attributes may be set simultaneously to create a grid.

If the rows attribute is not set, each column extends the entire length of the page. If the cols attribute is not set, each row extends the entire width of the page. If neither attribute is set, the frame takes up exactly the size of the page.

Frames are created left-to-right for columns and top-to-bottom for rows. When both attributes are specified, views are created left-to-right in the top row, left-to-right in the second row, etc.

The first example divides the screen vertically in two (i.e., creates a top half and a bottom half).

The next example creates three columns: the second has a fixed width of 250 pixels (useful, for example, to hold an image with a known size). The first receives 25% of the remaining space and the third 75% of the remaining space.

For the next example, suppose the browser window is currently 1000 pixels high. The first view is allotted 30% of the total height (300 pixels). The second view is specified to be exactly 400 pixels high. This leaves 300 pixels to be divided between the other two frames. The fourth frame's height is specified as "2*", so it is twice as high as the third frame, whose height is only "*" (equivalent to 1*). Therefore the third frame will be 100 pixels high and the fourth will be 200 pixels high.

Absolute lengths that do not sum to 100% of the real available space should be adjusted by the user agent. When underspecified, remaining space should be allotted proportionally to each view. When overspecified, each view should be reduced according to its specified proportion of the total space.

Nested frame sets

While, framesets may be nested to any level, xHTML profiles may restrict the number of nesting levels.

In the following example, the outer FRAMESET divides the available space into three equal columns. The inner FRAMESET then divides the second area into two rows of unequal height.

<frameset cols="33%, 33%, 34%"&gt
...contents of first frame...
<frameset rows="40%, 50%"&gt
...contents of second frame, first row...
...contents of second frame, second row...
</frameset&gt
...contents of third frame...
</frameset&gt

Sharing data among frames

Content developers may share data among several frames by including this data via an OBJECT element. Content developers should include the OBJECT element in the HEAD element of a frameset document and name it with the id attribute. Any document that is the contents of a frame in the frameset may refer to this identifier.

The following example illustrates how a script might refer to an OBJECT element defined for an entire frameset:

The IFRAME element allows content developers to insert a frame within a block of text. Inserting an inline frame within a section of text is much like inserting an object via the OBJECT element: they both allow you to insert an xHTML document in the middle of another, they may both be aligned with surrounding text, etc.

The information to be inserted inline is designated by the src attribute of this element. The contents of the IFRAME element, on the other hand, should only be displayed by user agents that do not support frames or are configured not to display frames.

For user agents that support frames, the following example will place an inline frame surrounded by a border in the middle of the text.

<iframe src="foo.html" width="400" height="500"
scrolling="auto" frameborder="1"&gt
[Your user agent does not support frames or is currently configured
not to display frames. However, you may visit
<a href="foo.html">the related document.</a&gt]
</iframe&gt

Inline frames may not be resized (and thus, they do not take the noresize attribute).

The NOFRAMES element specifies content that should be displayed only when frames are not being displayed. User agents that support frames must only display the contents of a NOFRAMES declaration when configured not to display frames. User agents that do not support frames
must display the contents of NOFRAMES in any case.

NOFRAMES can be used in the FRAMESET section of a frameset document. For example:

The Listset elements are those elements pertaining to profiles that support lists. While it is expected that most profiles would support lists, it is conceivable to define a platform with no inline flow algorithms, instead relying on absolute or fixed positioning (through style information). For these profiles, the Listset would not need to be supported.

The DL element specifies a definition list. Definition lists vary only slightly from other types of lists in that list items consist of two parts: a term and a description. The term is given by the DT element and is restricted to inline content. The description is given with the DD element that contains block level content.

Here is an example:

<dl&gt
<dt>Dweeb</dt&gt
<dd>young excitable person who may mature
into a <em>Nerd</em> or <em>Geek</em&gt</dd&gt
<dt>Cracker</dt&gt
<dd>hacker on the Internet</dd&gt
<dt>Nerd</dt&gt
<dd>male so into the Net that he forgets
his wife's birthday</dd&gt
</dl&gt

Here is an example with multiple terms and descriptions:

<dl&gt
<dt>Center</dt&gt
<dt>Centre</dt&gt
<dd>A point equidistant from all points
on the surface of a sphere.</dd&gt
<dd>In some field sports, the player who
holds the middle position on the field, court,
or forward line.</dd&gt
</dl&gt

Another application of DL, for example, is for marking up dialogues, with each DT naming a speaker, and each DD containing his or her words.

specifies the vertical position of data within a cell. Possible values:

top: Cell data is flush with the top of the cell.

middle: Cell data is centered vertically within the cell. This is the default value.

bottom: Cell data is flush with the bottom of the cell.

baseline: All cells in the same row as a cell whose valign attribute has this value should have their textual data positioned so that the first text line occurs on a baseline common to all cells in the row. This constraint does not apply to subsequent text lines in these cells.

specifies a single character within a text fragment to act as an axis for alignment. The default value for this attribute is the decimal point character for the current language as set by the lang attribute (e.g., the period (".") in English and the comma (",") in French). Depending on the xHTML profile, user agents may not be required to support this attribute.

specifies the offset to the first occurrence of the alignment character on each line. If a line doesn't include the alignment character, it should be horizontally shifted to end at the alignment position.

When charoff is used to set the offset of an alignment character, the direction of offset is determined by the current text direction (set by the dir attribute). In left-to-right texts (the default), offset is from the left margin. In right-to-left texts, offset is from the right margin. Depending on the xHTML profile, user agents may not be required to support this attribute.

The table in this example aligns a row of currency values along a decimal point. We set the alignment character to "." explicitly.

When the contents of a cell contain more than one instance of the alignment character specified by char and the contents wrap, user agent behavior is undefined. Authors should therefore be attentive in their use of char.

Note. Visual user agents typically render TH elements vertically and horizontally centered within the cell and with a bold font weight. This behavior may be specified by the xHTML profile.

Inheritance of alignment specifications

The alignment of cell contents can be specified on a cell by cell basis, or inherited from enclosing elements, such as the row, column or the table itself.

The order of precedence (from highest to lowest) for the attributes (and style) align, char, and charoff is the following:

An alignment attribute or style set on an element within a cell's data (e.g., P).

An alignment attribute or style set on a cell (TH and TD).

An alignment attribute or style set on a column grouping element (COL and COLGROUP). When a cell is part of a multi-column span, the alignment property is inherited from the cell definition at the beginning of the span.

An alignment attribute or style set on a row or row grouping element (TR, THEAD, TFOOT, and TBODY). When a cell is part of a multi-row span, the alignment property is inherited from the cell definition at the beginning of the span.

An alignment attribute or style set on the table (TABLE).

The default alignment value.

The order of precedence (from highest to lowest) for the attribute valign (as well as the other inherited attributes lang, dir, and style) is the following:

An attribute set on an element within a cell's data (e.g., P).

An attribute set on a cell (TH and TD).

An attribute set on a row or row grouping element (TR, THEAD, TFOOT, and TBODY). When a cell is part of a multi-row span, the attribute value is inherited from the cell definition at the beginning of the span.

An attribute set on a column grouping element (COL and COLGROUP). When a cell is part of a multi-column span, the attribute value is inherited from the cell definition at the beginning of the span.

An attribute set on the table (TABLE).

The default attribute value.

Furthermore, when rendering cells, horizontal alignment is determined by columns in preference to rows, while for vertical alignment, rows are given preference over columns.

The default alignment for cells depends on the user agent. However, user agents should substitute the default attribute for the current directionality (i.e., not just "left" in all cases).

User agents that do not support the "justify" value of the align attribute should use the value of the inherited directionality in its place.

Note. Note that a cell may inherit an attribute not from its parent but from the first cell in a span. This is an exception to the general attribute inheritance rules.

When present, the CAPTION element's text should describe the nature of the table. The CAPTION element is only permitted immediately after the TABLE start tag. A TABLE element may only contain one CAPTION element.

Visual user agents allow sighted people to quickly grasp the structure of the table from the headings as well as the caption. A consequence of this is that captions will often be inadequate as a summary of the purpose and structure of the table from the perspective of people relying on non-visual user agents.

Content developers should therefore take care to provide additional information summarizing the purpose and structure of the table using the summary attribute of the TABLE element. This is especially important for tables without captions. Examples below illustrate the use of the summary attribute.

Visual user agents should avoid clipping any part of the table including the caption, unless a means is provided to access all parts, e.g., by horizontal or vertical scrolling. We recommend that the caption text be wrapped to the same width as the table. This may be specified by the xHTML profile.

specifies the number of columns "spanned" by the COL element; the COL element shares its attributes with all the columns it spans. The default value for this attribute is 1 (i.e., the COL element refers to a single column) and it must always be >= 1. If the span attribute is set to N > 1, the current COL element shares its attributes with the next N-1 columns.

width

specifies a default width for each column spanned by the current COL element. It has the same meaning as the width attribute for the COLGROUP element and overrides it.

The COL element allows content develoeprs to group together attribute specifications for table columns. The COL does not group columns together structurally -- that is the role of the COLGROUP element. COL elements are empty and serve only as a support for attributes. They may appear inside or outside an explicit column group (i.e., COLGROUP element).

The width attribute for COL refers to the width of each column in the element's span.

There are two ways to determine the number of columns in a table (in order of precedence):

If the TABLE element contains any COLGROUP or COL elements, user agents should calculate the number of columns by summing the following:

For each COL element, take the value of its span attribute (default value 1).

For each COLGROUP element containing at least one COL element, ignore the span attribute for the COLGROUP element. For each COL element, perform the calculation of step 1.

For each empty COLGROUP element, take the value of its span attribute (default value 1).

Otherwise, if the TABLE element contains no COLGROUP or COL elements, user agents should base the number of columns on what is required by the rows. The number of columns is equal to the number of columns required by the row with the most columns, including cells that span multiple columns. For any row that has fewer than this number of columns, the end of that row should be padded with empty cells. The "end" of a row depends on the table directionality.

It is an error if a table contains COLGROUP or COL elements and the two calculations do not result in the same number of columns.

Once the user agent has calculated the number of columns in the table, it may group them into column groups.

For example, for each of the following tables, the two column calculation methods should result in three columns. The first three tables may be rendered incrementally.

A fixed width specification is given in pixels (e.g., width="30"). A fixed-width specification enables incremental rendering.

Percentage

A percentage specification (e.g., width="20%") is based on the percentage of the horizontal space available to the table (between the current left and right margins, including floats). Note that this space does not depend on the table itself, and thus percentage specifications enable incremental rendering.

Proportional

Proportional specifications (e.g., width="3*") refer to portions of the horizontal space required by a table. If the table width is given a fixed value via the width attribute of the TABLE element, user agents may render the table incrementally even with proportional columns.

However, if the table does not have a fixed width, user agents must receive all table data before they can determine the horizontal space required by the table. Only then may this space be allotted to proportional columns.

If a content developer specifies no width information for a column, a user agent may not be able to incrementally format the table since it must wait for the entire column of data to arrive in order to allot an appropriate width.

If column widths prove to be too narrow for the contents of a particular table cell, user agents may choose to reflow the table.

The table in this example contains six columns. The first one does not belong to an explicit column group. The next three belong to the first explicit column group and the last two belong to the second explicit column group. This table cannot be formatted incrementally since it contains proportional column width specifications and no value for the width attribute for the TABLE element.

Once the (visual) user agent has received the table's data, the available horizontal space will be alloted by the user agent as follows: First the user agent will allot 30 pixels to columns one and two. Then, the minimal space required for the third column will be reserved. The remaining horizontal space will be divided into six equal portions (since 2* + 1* + 3* = 6 portions). Column four (2*) will receive two of these portions, column five (1*) will receive one, and column six (3*) will receive three.

We have set the value of the align attribute in the third column group to "center". All cells in every column in this group will inherit this value, but may override it. In fact, the final COL does just that, by specifying that every cell in the column it governs will be aligned along the ":" character.

In the following table, the column width specifications allow the user agent to format the table incrementally:

The first ten columns will be 15 pixels wide each. The last two columns will each receive half of the remaining 50 pixels. Note that the COL elements appear only so that an id value may be specified for the last two columns.

Note. Although the width attribute on the TABLE element is not deprecated, authors are encouraged to use style sheets to specify table widths.

This attribute, which must be an integer > 0, specifies the number of columns in a column group. Values mean the following:

In the absence of a span attribute, each COLGROUP defines a column group containing one column.

If the span attribute is set to N > 0, the current COLGROUP element defines a column group containing N columns.

User agents must ignore this attribute if the COLGROUP element contains one or more COL elements.

width

specifies a default width for each column in the current column group. In addition to the standard pixel, percentage, and relative values, this attribute allows the special form "0*" (zero asterisk) which means that the width of the each column in the group should be the minimum width necessary to hold the column's contents. This implies that a column's entire contents must be known before its width may be correctly computed. Content developers should be aware that specifying "0*" will prevent visual user agents from rendering a table incrementally.

This attribute is overridden for any column in the column group whose width is specified via a COL element.

The COLGROUP element creates an explicit column group. The number of columns in the column group may be specified in two, mutually exclusive ways:

The element's span attribute (default value 1) specifies the number of columns in the group.

Each COL element in the COLGROUP represents one or more columns in the group.

The advantage of using the span attribute is that content developers may group together information about column widths. Thus, if a table contains forty columns, all of which have a width of 20 pixels, it is easier to write:

When it is necessary to single out a column (e.g., for style information, to specify width information, etc.) within a group, content developers must identify that column with a COL element. Thus, to apply special style information to the last column of the previous table, we single it out as follows:

The width attribute of the COLGROUP element is inherited by all 40 columns. The first COL element refers to the first 39 columns (doing nothing special to them) and the second one assigns an id value to the fortieth columns so that style sheets may refer to it.

The table in the following example contains two column groups. The first column group contains 10 columns and the second contains 5 columns. The default width for each column in the first column group is 50 pixels. The width of each column in the second column group will be the minimum required for that column.

This attribute specifies how much space the user agent should leave between the left side of the table and the left-hand side of the leftmost column, the top of the table and the top side of the topmost row, and so on for the right and bottom of the table. The attribute also specifies the amount of space to leave between cells.

cellpadding

This attribute specifies the amount of space between the border of the cell and its contents. If the value of this attribute is a pixel length, all four margins should be this distance from the contents. If the value of the attribute is a percentage length, the top and bottom margins should be equally separated from the content based on a percentage of the available vertical space, and the left and right margins should be equally separated from the content based on a percentage of the available horizontal space.

The border and frame attributes have been deprecated in favor of style sheet properties.

The cellspacing and cellpadding attributes control spacing between and within cells.

In the following example, the cellspacing attribute specifies that cells should be separated from each other and from the table frame by twenty pixels. The cellpadding attribute specifies that the top margin of the cell and the bottom margin of the cell will each be separated from the cell's contents by 10% of the available vertical space (the total being 20%). Similarly, the left margin of the cell and the right margin of the cell will each be separated from the cell's contents by 10% of the available horizontal space (the total being 20%).

If a table or given column has a fixed width, cellspacing and cellpadding may demand more space than assigned. User agents may give these attributes precedence over the width attribute when a conflict occurs, but are not required to.

The TABLE element contains all other elements that specify caption, rows, content, and formatting.

The following informative list describes what operations user agents may carry out when rendering a table:

Make the table summary available to the user. Authors should provide a summary of a table's content and structure so that people using non-visual user agents may better understand it.

Render the caption, if one is defined.

Render the table header, if one is specified. Render the table footer, if one is specified. User agents must know where to render the header and footer. For instance, if the output medium is paged, user agents may put the header at the top of each page and the footer at the bottom. Similarly, if the user agent provides a mechanism to scroll the rows, the header may appear at the top of the scrolled area and the footer at the bottom. This behavior may be specified by the xHTML profile.

Calculate the number of columns in the table. Note that the number of rows in a table is equal to the number of TR elements contained by the TABLE element.

Group the columns according to any column group specifications.

Render the cells, row by row and grouped in appropriate columns, between the header and footer. Visual user agents should format the table according to xHTML attributes and style sheet specification.

The HTML table model has been designed so that, with author assistance, user agents may render tables incrementally (i.e., as table rows arrive) rather than having to wait for all the data before beginning to render.

In order for a user agent to format a table in one pass, authors must tell the user agent:

More precisely, a user agent may render a table in a single pass when the column widths are specified using a combination of COLGROUP and COL elements. If any of the columns are specified in relative or percentage terms (see the section on calculating the width of columns), authors must also specify the width of the table itself.

The directionality of a table is either the inherited directionality (the default is left-to-right) or that specified by the dir attribute for the TABLE element.

For a left-to-right table, column zero is on the left side and row zero is at the top. For a right-to-left table, column zero is on the right side and row zero is at the top.

When a user agent allots extra cells to a row (see the section on calculating the number of columns in a table), extra row cells are added to the right of the table for left-to-right tables and to the left side for right-to-left tables.

Note that TABLE is the only element on which dir reverses the visual order of the columns; a single table row (TR) or a group of columns (COLGROUP) cannot be independently reversed.

When set for the TABLE element, the dir attribute also affects the direction of text within table cells (since the dir attribute is inherited by block-level elements).

To specify a right-to-left table, set the dir attribute as follows:

<table dir="RTL"&gt
...the rest of the table...
</table&gt

The direction of text in individual cells can be changed by setting the dir attribute in an element that defines the cell. Please consult the section on bidirectional text for more information on text direction issues.

Table rows may be grouped into a table head, table foot, and one or more table body sections, using the THEAD, TFOOT and TBODY elements, respectively. This division enables user agents to support scrolling of table bodies independently of the table head and foot. When long tables are printed, the table head and foot information may be repeated on each page that contains table data.

The table head and table foot should contain information about the table's columns. The table body should contain rows of table data.

When present, each THEAD, TFOOT, and TBODY contains a row group. Each row group must contain at least one row, defined by the TR element.

This example illustrates the order and structure of table heads, feet, and bodies.

provides an abbreviated form of the cell's content, and may be rendered by user agents when appropriate in place of the cell's content. Abbreviated names should be short since user agents may render them repeatedly. For instance, speech synthesizers may render the abbreviated headers relating to a particular cell before rendering that cell's content.

axis

places a cell into conceptual categories that can be considered to form axes in an n-dimensional space. User agents may give users access to these categories (e.g., the user may query the user agent for all cells that belong to certain categories, the user agent may present a table in the form of a table of contents, etc.). The value of this attribute is a comma-separated list of category names.

headers

specifies the list of header cells that provide header information for the current data cell. The value of this attribute is a space-separated list of cell names; those cells must be named by setting their id attribute. Content developers generally use the headers attribute to help non-visual user agents render header information about data cells (e.g., header information is spoken prior to the cell data), but the attribute may also be used in conjunction with style sheets. See also the scope attribute.

scope

specifies the set of data cells for which the current header cell provides header information. This attribute may be used in place of the headers attribute, particularly for simple tables. When specified, this attribute must have one of the following values:

row: The current cell provides header information for the rest of the row that contains it (see also the section on table directionality).

col: The current cell provides header information for the rest of the column that contains it.

rowgroup: The header cell provides header information for the rest of the row group that contains it.

colgroup: The header cell provides header information for the rest of the column group that contains it.

rowspan

specifies the number of rows spanned by the current cell. The default value of this attribute is one ("1"). The value zero ("0") means that the cell spans all rows from the current row to the last row of the table.

colspan

specifies the number of columns spanned by the current cell. The default value of this attribute is one ("1"). The value zero ("0") means that the cell spans all columns from the current column to the last column of the table.

Table cells may contain two types of information: header information and data. This distinction enables user agents to render header and data cells distinctly, even in the absence of style sheets. For example, visual user agents may present header cell text with a bold font. Speech synthesizers may render header information with a distinct voice inflection.

The TH element defines a cell that contains header information. The TD element defines a cell that contains data.

Cells may be empty (i.e., contain no data). For example, the following table contains four columns of data, each headed by a column description.

As cell "2" spans the first and second rows, the definition of the second row will take it into account. Thus, the second TD in row two actually defines the row's third cell. Visually, the table might be rendered to a tty device as:

Defining overlapping cells is an error. User agents may vary in how they handle this error (e.g., rendering may vary).

The following illegal example illustrates how one might create overlapping cells. In this table, cell "5" spans two rows and cell "7" spans two columns, so there is overlap in the cell between "7" and "9":

Table rows may be grouped into a table head, table foot, and one or more table body sections, using the THEAD, TFOOT and TBODY elements, respectively. This division enables user agents to support scrolling of table bodies independently of the table head and foot. When long tables are printed, the table head and foot information may be repeated on each page that contains table data.

The table head and table foot should contain information about the table's columns. The table body should contain rows of table data. See the TBODY element for examples of how these elements are used.

provides an abbreviated form of the cell's content, and may be rendered by user agents when appropriate in place of the cell's content. Abbreviated names should be short since user agents may render them repeatedly. For instance, speech synthesizers may render the abbreviated headers relating to a particular cell before rendering that cell's content.

axis

places a cell into conceptual categories that can be considered to form axes in an n-dimensional space. User agents may give users access to these categories (e.g., the user may query the user agent for all cells that belong to certain categories, the user agent may present a table in the form of a table of contents, etc.). The value of this attribute is a comma-separated list of category names.

headers

specifies the list of header cells that provide header information for the current data cell. The value of this attribute is a space-separated list of cell names; those cells must be named by setting their id attribute. Authors generally use the headers attribute to help non-visual user agents render header information about data cells (e.g., header information is spoken prior to the cell data), but the attribute may also be used in conjunction with style sheets. See also the scope attribute.

scope

specifies the set of data cells for which the current header cell provides header information. This attribute may be used in place of the headers attribute, particularly for simple tables. When specified, this attribute must have one of the following values:

row: The current cell provides header information for the rest of the row that contains it (see also the section on table directionality).

col: The current cell provides header information for the rest of the column that contains it.

rowgroup: The header cell provides header information for the rest of the row group that contains it.

colgroup: The header cell provides header information for the rest of the column group that contains it.

rowspan

specifies the number of rows spanned by the current cell. The default value of this attribute is one ("1"). The value zero ("0") means that the cell spans all rows from the current row to the last row of the table.

colspan

specifies the number of columns spanned by the current cell. The default value of this attribute is one ("1"). The value zero ("0") means that the cell spans all columns from the current column to the last column of the table.

The TH element defines a cell that contains header information. User agents have two pieces of header information available: the contents of the TH element and the value of the abbr attribute. User agents must render either the contents of the cell or the value of the abbr attribute. For visual media, the latter may be appropriate when there is insufficient space to render the full contents of the cell. For non-visual media abbr may be used as an abbreviation for table headers when these are rendered along with the contents of the cells to which they apply.

The headers and scope attributes also allow authors to help non-visual user agents process header information. See the TD element for examples of how the TH element is used.

Table rows may be grouped into a table head, table foot, and one or more table body sections, using the THEAD, TFOOT and TBODY elements, respectively. This division enables user agents to support scrolling of table bodies independently of the table head and foot. When long tables are printed, the table head and foot information may be repeated on each page that contains table data.

The table head and table foot should contain information about the table's columns. The table body should contain rows of table data. See the TBODY element for examples of how these elements are used.

<table summary="This table charts the number of cups
of coffee consumed by each senator, the type
of coffee (decaf or regular), and whether
taken with sugar."&gt
<caption>Cups of coffee consumed by each senator</caption&gt
<tr> ...A header row... </tr&gt
<tr&gt ...First row of data... </tr&gt
<tr&gt ...Second row of data... </tr&gt
...the rest of the table...
</table&gt

This appendix defines the entities, elements, and attributes found in all xHTML profile DTDs. This DTD does not "stand alone", rather it is combined with entities defined in following appendices to define a profile's DTD.

Style sheets represent a major breakthrough for content developers, expanding their ability to improve the appearance of their presentations. In the scientific environments in which the Web was conceived, people are more concerned with the content of their documents than the presentation. In broadcast television, however, edge-to-edge control of the presentation is a critical feature for content developers.

Style sheets solve many of the layout problems of HTML and at the same time they supersede the limited range of presentation mechanisms in HTML. Style sheets make it easy to specify the amount of white space between text lines, the amount lines are indented, the colors used for the text and the backgrounds, the font size and style, synchronization of media objects, and a host of other details.

xHTML provides support for inline style information and it provides for a single external style sheet for limited cascading style sheet functionality. See the STYLE element and the style attribute for how style is applied.

bHTML style is based on CSS2. The following style properties are added to CSS2:

specifies whether scaliung or cropping is preferred if the specified width or height does not correspond to the original width and height

active-region

specifies an active region through a sequence of coordinations.

tosafetitle

specifies whether the box should be scaled or cropped to fit within the safe title region. If the box is entirely within the safe title region, there is no effect. If the box is entirely outside the safe title region, if this property is set to any value, the box is not visible. This property may have the value of "scale" or "crop". When scaling, the corners of the box within the safe title region remain fixed.

specifies what color in the image should be interpreted as the transparency color. If more than one value is specified, the additional values are color and value pairs for different levels of transparency.

specifies whether, when rendering of an element, the element is immediately "set" to the aforementioned properties, or whether the element transitions to those properties. For example, does the element go from transparent to opaque (or some level of semi-transparency), from opaque to transparent (dissolving), or immediately opaque.

specifies the time for the explicit begin of an element. This property value can be a delay value, measured in terms of the presentation clock, or an event value.

dur

specifies the explicit duration of an element. This property value can be a clock value or the string "indefinite."

end

specifies the explicit end of an element. This property can contain the same types of values as the begin property.

endsync

specifies the element to which this element should synchronize its end.

repeat

specifies how many times the element is rendered. The property value can be an integer, or the string "indefinite."

synctype

specifies the type of synchronization desired for elements of this style. The property can be "parallel" or "sequential".

sync

specifies the means of synchronization desired for elements of this style. The property can be the strings "clock", "frame", or the string "soft."

The accuracy of synchronization between elements in a DIV or SPAN with the synctype property of parallel is generally implementation-dependent. If the sync property is clock, the content decoders will share the same clock.

In bHTML, content decoders will make presentation timing available to other content decoders. If the sync property is frame, the content decoders for the elements will receive the presentation timing information of the "parent" block level object
(or the television video). For an MPEG-2 content decoder, the frame may correlate to the MPEG-2 presentation time stamp.

If the sync property is not specified (a don't care condition) or is soft, each element has its own clock, which runs independently of the clocks of other elements with the same style.

specifies the position of the current element in the tabbing order for the current presentation. This value must be a number between 0 and 32767. User agents should ignore leading zeros.

up

specifies the tab index of the element above the current element in the tabbing order. The element above the current element would likely be selected when the user selects an "up key" via the keyboard or remote control.

down

specifies the tab index of the element below the current element in the tabbing order. The element below the current element would likely be selected when the user selects a "down key" via the keyboard or remote control.

left

specifies the tab index of the element to the left of the current element in the tabbing order. The element to the left of the current element would likely be selected when the user selects a "left key" via the keyboard or remote control.

right

specifies the tab index of the element to the right the current element in the tabbing order. The element to the right of the current element would likely be selected when the user selects a "right key" via the keyboard or remote control.

accesskey

assigns an access key to an element. An access key is a single character from the document character set. Content developers should consider the input method of the expected reader when specifying an accesskey.

The navigation properties describe the order in which certain objects are selected when either a tab, backwards tab, or up-down-left-right tab event occurs. Navigation properties also describe how certain objects may be selected through keyboard shortcuts and other accessibility options.

Tabbing

The tabbing order defines the order in which elements will receive focus when navigated by the user via the keyboard or remote control. The tabbing order may include elements nested within other elements.

Elements that may receive focus should be navigated by user agents according to the following rules:

Those elements that support the tabindex property and assign a positive value to it are navigated first. Navigation proceeds from the element with the lowest tabindex value to the element with the highest value. Values need not be sequential nor must they begin with any particular value. Elements that have identical tabindex values should be navigated in the order they appear in the character stream.

Those elements that do not support the tabindex property or support it and assign it a value of "0" are navigated next. These elements are navigated in the order they appear in the character stream. If not specified, up and left corresponds to backward tabbing and right and down corresponds to forward tabbing.

Elements that are disabled do not participate in the tabbing order.

The following elements automatically support the tabindex property: A, AREA, INPUT, OBJECT, SELECT, and TEXTAREA. In other words, if the tabindex property these elements is not specified, the tabindex is considered to be "0".

In this example, the tabbing order will be the pushbutton, the form's three INPUT elements in order (note that
"field1" and the button share the same tabindex, but "field1" appears later in the character stream), and finally the link created by the A element. The "up" tab always navigates to the A element (at the top of the presentation) and the "down" tab always navigates the submit button.

The actual key sequence that causes tabbing navigation or element activation depends on the configuration of the user agent (e.g., the "tab" and "arrow" keys are used for navigation, and the "enter" key is used to activate a selected element).

User agents may also define key sequences to navigate the tabbing order in reverse. When the end (or beginning) of the tabbing order is reached, user agents may circle back to the beginning (or end).

Access keys

Pressing an access key assigned to an element gives focus to the element. The action that occurs when an element receives focus depends on the element. For example, when a user activates a link defined by the A element, the user agent generally follows the link. When a user activates a radio button, the user agent changes the value of the radio button. When the user activates a text field, it allows input, etc.

The following elements support the accesskey attribute: A, INPUT, LABEL, LEGEND, and TEXTAREA.

This example assigns the access key "U" to a label associated with an INPUT control. Typing the access key gives focus to the label which in turn gives it to the associated control. The user may then enter text into the INPUT area.

The invocation of access keys depends on the underlying system. For instance, on machines running Microsoft Windows, one generally has to press the "alt" key in addition to the access key. On Apple systems, one generally has to press the "cmd" key in addition to the access key.

The rendering of access keys depends on the user agent. We recommend that content developers include the access key in label text or wherever the access key is to apply. User agents should render the value of an access key in such a way as to emphasize its role and to distinguish it from other characters (e.g., by underlining it).

Content developers should be aware that there is no requirement for a bHTML receiver to have an input device that provides the access key. If the receiver does not provide access keys, the user agent on that platform is not required to render the value of the access key.

xHTML provides a set of elements and attributes that is based on HTML 4.0. These elements are partitioned in a collection of DTD Sets. bHTML is a profile of xHTML that contains a subset of these sets, a subset of xHTML style properties, a set of predefined event types, a set of predefined test types, a set of default content decoders, and a specification of which element attributes are recognized, their default values, and any other constraints.

The EVENT defines a block of behaviors that respond to an event. The name attribute of the EVENT element specifies an event in which their is a behavior. The bHTML profile specifies the following values for the name attribute:

onload

specifies a behavior for when the presentation is loaded.

onunload

specifies a behavior for when the presentation is unloaded.

ontick

specifies a behavior for a system clock tick.

onframe

specifies a behavior for when a frame is presented to the user.

ontimer

specifies a behavior in response to a programmable timer OBJECT element.

oneventstart

specifies a behavior in response to a PSIP event starting.

oneventend

specifies a behavior in response to a PSIP event ending.

oneventchange

specifies a behavior in response to the event changing on the current channel.

onchannelselect

specifies a behavior in response to a channel or service being selected

onchanneldeselect

specifies a behavior in response to a channel or service begin deselected

onchannelchange

specifies a behavior when the channel or service changes.

onclick

specifies a behavior for when the select button is clicked.

ondblclick

specifies a behavior for when the select button is double clicked.

onselectdown

specifies a behavior for when the select button is depressed.

onselectup

specifies a behavior for when the select button is released.

oncursorover

specifies a behavior for when the cursor moves over the element.

oncursormove

specifies a behavior for when the cursor moves within the element.

oncursorout

specifies a behavior for when the cursor moves out of the element.

onkeypress

specifies a behavior for when a key is clicked.

onkeydown

specifies a behavior for when a key is depressed.

onkeyup

specifies a behavior for when a key is released.

onmediastart

specifies a behavior for when a media stream starts.

onmediastop

specifies a behavior for when a media stream stops.

onendofmedia

specifies a behavior for when a media stream ends.

ondecoderplay

specifies a behavior for when a media stream player starts decoding a media stream.

ondecoderpause

specifies a behavior for when a media stream player pauses decoding a media stream.

ondecoderstopattime

specifies a behavior for when a media stream player stops decoding a media stream at a requested time.

ondecoderstopbyrequest

specifies a behavior for when a media stream player stops decoding a media stream upon the request.

The Java Media Framework (JMF) provides a platform-neutral framework for displaying time-based media. The Java Media Player APIs are designed to support most standard time-based media content types, including MPEG-1, MPEG-2, Quicktime, AVI, WAV, AU, and MIDI.

This time-based media may be synchronized and presented from diverse sources using the Java Media Player APIs. Applications create a Player object that reads data from a DataSource object and renders it at a precise time. In addition to supporting preceise synchronization and presentation of time-based media, the Java Media Framework has an effective mechanism for matching DataSource objects with the appropriate Player object to handle the media to be presented.

H.1 How a JMF Player is Created

First, the applications creates a Player object is created by calling the static method createPlayer in the javax.media.Manager class and passing a MediaLocator object:

javax.media.Manager.createPlayer( MediaLocator sourceLocator );

A MediaLocator object describes the media that the Player will display. A URL can be used for the MediaLocator.

The MediaLocator object supplied to the Manager's createPlayer method identifies the DataSource. The DataSource encapsulates the location of the media, the protocol, and the software used to deliver the media.

Second, the Manager creates a search list of DataSource class names using the protocol name contained in the MediaLocator object. Using each class name in the list, the Manager tries to create an actual DataSource object and open a connection to the location represented by the MediaLocator.

Third, once the Manager has created the correct DataSource for the media, it begins to create the actual Player object.

To create the actual player, the Manager creates a search list of MediaHandler class names using the content name from the DataSource object. Using each class name, the Manager tries to create an actual instance of the MediaHandler class and adds the DataSource object to it. Once the Manager has created the correct MediaHandler for the media by successfully adding the DataSource, the Manager tests to see if it is an instance of Player. If so, the Manager returns the object as a Player object, otherwise the process repeats recursively.

Every Player object created implements the Player interface which extends four interfaces:

MediaHandler

Controller

Duration

Clock

The methods defined by the Controller, Duration, and Clock interfaces are not necessary to support non-time based content decoders. Rather, a new interface called Decoder is defined that extends the MediaHandler interface. In addition, a new MediaManager class is defined. The MediaManager class extends the Manager class and contains a createDecoder(MediaLocator) method, similar in function to the Manager.createPlayer(MediaLocator) method but returning a Decoder object.

H.2 Integrating New DataSources and MediaHandlers into the Java Media Framework

The previous section explained how the Java Media Framework uses a lookup mechanism to search for the correct DataSource and matching MediaHandler. This mechanism uses Java interfaces to abstract DataSources and MediaHandlers allowing the addition of new DataSources and MediaHandlers.

In searching for DataSources and MediaHandlers, the Manager calls methods that takes the name of the protocol (or content), and constructs a fully qualified classname. For DataSources:

media.protocol.<protocol_name>.DataSource

and for MediaHandlers:

media.content.<content_name>.Handler

This name, and an associated list of package prefixes, is used to create the lists of DataSources and MediaHandlers available for a given protocol and content type. The package prefix is the top level name of the package (such as org.atsc.dase). Thus, the name of an MediaHandler called "mpeg.sys" would be:

org.atsc.dase.media.content.mpeg.sys

Adding a new DataSource or MediaHandler would involves the following steps, as defined in the Java Media Frameworkj specification:

installing the package containing the new DataSource or MediaHandler.

adding the package prefix to the list controlled by the Java PackageManager.

and in the case of a new MediaHandler, checking a DataSource that is passed to it's setSource method to determine whether the Player can handle the content type.

H.3 Installing New "Static" Content Decoders for Images

The previous section described how to install new content decoders for time-based streaming media types (audio, video, animations, etc.). A great deal of content is neither streaming (it generally arrives on the receiver as a big chunck of data), or closely associated with time (other than when it is displayed or removed, it does not change with respect to time). The most common example of this type of "static" content are images. This section describes how image content decoders are added.

The same look up method used for time-based media can be efficiently used for adding new content decoders for static images. Additional considerations are needed, though, in order for the static image decoders to be accessed through the conventions of the Java standard graphics class library, the Abstract Windowing Toolkit (AWT).

Consider the java.awt.Image class, which represents a displayable image in a platform independent manner. An Image object is returned by the following methods:

Applet.getImage(URL);

which calls AppletContext.getImage(URL);

Component.createImage();

which calls ComponentPeer.createImage(ImageProducer); or Toolkit.createImage(ImageProducer);.

Frame.getIconImage();

which returns a previously stored image.

SimpleBeanInfo.getIcon();

which returns a previously stored image.

SimpleBeanInfo.loadImage();

which calls Toolkit.createImage(ImageProducer).

In addition, the following methods are defined as abstract methods. Abstract methods leave the details of how an Image object is retrieved and decoded to the implementation.

BeanInfo.getIcon(int);

Image.getScaledInstance(int_width, int_height, int_hints);

Toolkit.getImage(URL);

AppletContext.getImage(URL);

Toolkit.createImage(ImageProducer);

ComponentPeer.createImage(ImageProducer);

In the case of the methods that take URL objects, the URL.getContent() method can be used to obtain an ImageProducer object. This object can then be passed to the Toolkit or Component.createImage(ImageProducer) method to obtain an Image object. The ImageProducer interface represents an image source. The ImageConsumer defines the methods necessary for a class that consumes image data to communicate with a class that produces image data.

The primary methods in generating an Image object are from the Toolkit, ComponentPeer, and AppletContext classes and interface. The ImageProducer interface also plays a key role in abstracting the implementation of decoding a static image.

An ImageDecoder interface extends the aforementioned Decoder interface and the ImageProducer interface. In this way, an ImageDecoder can be created with the DataSource representing the static image. The resulting ImageDecoder can then be used in any Java AWT method supporting the ImageProducer interface. In addition, the MediaManager supports the CreateImageDecoder( ImageLocator ); method which returns an ImageDecoder object. The implementation of all methods returning an Image object use the Java Media Framework lookup mechanism described above.