XEP-0071: XHTML-IM

NOTICE: The protocol defined herein is a Draft Standard of the XMPP Standards Foundation. Implementations are encouraged and the protocol is appropriate for deployment in production systems, but some changes to the protocol are possible before it becomes a Final Standard.

Table of Contents

1. Introduction

This document defines methods for exchanging instant messages that contain lightweight text markup. In the context of this document, "lightweight text markup" is to be understood as a combination of minimal structural elements and presentational styles that can easily be rendered on a wide variety of devices without requiring a full rich-text rendering engine such as a web browser. Examples of lightweight text markup include basic text blocks (e.g., paragraphs and blockquotes), structural elements (e.g., emphasis and strength), lists, hyperlinks, image references, and font styles (e.g., sizes and colors).

Note: This specification essentially defines a recommended set of XHTML elements and attributes for use in instant messaging by applying a series of "filters" to the wealth of XHTML features; however, developers of Jabber/XMPP clients mainly need to pay attention to the Summary of Recommendations rather than the complexities of how the recommendations are derived.

2. Choice of Technology

In the past, there have existed several incompatible methods within the Jabber community for exchanging instant messages that contain lightweight text markup. The most notable such methods have included derivatives of XHTML 1.0 [1] as well as of Rich Text Format (RTF) [2].

Although it is sometimes easier for client developers to implement RTF support (this is especially true on certain Microsoft Windows operating systems), there are several reasons (consistent with the XMPP Design Guidelines [3]) for the XMPP Standards Foundation (XSF) [4] to avoid the use of RTF in developing a protocol for lightweight text markup. Specifically:

1. RTF is not a structured vocabulary derived from SGML (as is HTML 4.0 [5]) or, more relevantly, from XML (as is XHTML 1.0).
2. RTF is under the control of the Microsoft Corporation and thus is not an open standard maintained by a recognized standards development organization; therefore the XSF is unable to contribute to or influence its development if necessary, and any protocol the XSF developed using RTF would introduce unwanted dependencies.

Conversely, there are several reasons to prefer XHTML for lightweight text markup:

1. XHTML is a structured format that is defined as an application of XML 1.0 [6], making it especially appropriate for sending over Jabber/XMPP, which is at root a technology for streaming XML (see XMPP Core [7]).
2. XHTML is an open standard developed by the World Wide Web Consortium (W3C) [8], a recognized standards development organization.

Therefore, this document defines support for lightweight text markup in the form of an XMPP extension that encapsulates content defined by an XHTML 1.0 Integration Set that we label "XHTML-IM". The remainder of this document discusses lightweight text markup in terms of XHTML 1.0 only and does not further consider RTF or other technologies.

3. Requirements

HTML was originally designed for authoring and presenting stuctured documents on the World Wide Web, and was subsequently extended to handle more advanced functionality such as image maps and interactive forms. However, the requirements for publishing documents (or developing transactional websites) for presentation by dedicated XHTML user agents on traditional computers or small-screen devices are fundamentally different from the requirements for lightweight text markup of instant messages; for this reason, only a reduced set of XHTML features is needed for XHTML-IM. In particular:

1. IM clients are not XHTML clients: their primary purpose is not to read pre-existing XHTML documents, but to read and generate relatively large numbers of fairly small instant messages.

2. The underlying context for XHTML content in Jabber/XMPP instant messaging is provided not by a full XHTML document, but by an XML stream, and specifically by a message stanza within that stream. Thus the <head/> element and all its children are unnecessary. Only the <body/> element and some of its children are appropriate for use in instant messaging.

3. The XHTML content that is read by one's IM client is normally generated on the fly by one's conversation partner (or, to be precise, by his or her IM client). Thus there is an inherent limit to the sophistication of the XHTML markup involved. Even in normal XHTML documents, fairly basic structural and rendering elements such as definition lists, abbreviations, addresses, and computer input handling (e.g., <kbd/> and <var/>) are relatively rare. There is little or no foreseeable need for such elements within the context of instant messaging.

4. The foregoing is doubly true of more advanced markup such as tables, frames, and forms (however, there exists an XMPP extension that provides an instant messaging equivalent of the latter, as defined in Data Forms [9]).

5. Although ad-hoc styles are useful for messaging (by means of the 'style' attribute), full support for Cascading Style Sheets [10] (defined by the <style/> element or a standalone .css file, and implemented via the 'class' attribute) would be overkill since many CSS1 properties (e.g., box, classification, and text properties) were developed especially for sophisticated page layout.

6. Background images, audio, animated text, layers, applets, scripts, and other multimedia content types are unnecessary, especially given the existence of XMPP extensions such as SI File Transfer [11], Jingle [12], and Jingle File Transfer [13].

7. Content transformations such as those defined by XSL Transformations [14] must not be necessary in order for an instant messaging application to present lightweight text markup to an end user.

As explained below, some of these requirements are addressed by the definition of the XHTML-IM Integration Set itself, while others are addressed by a recommended "profile" for that Integration Set in the context of instant messaging applications.

4. Concepts and Approach

This document defines an adaptation of XHTML 1.0 (specifically, an XHTML 1.0 Integration Set) that makes it possible to provide lightweight text markup of instant messages (mainly for Jabber/XMPP instant messages, although the Integration Set defined herein could be used by other protocols). This pattern is familiar from email, wherein the HTML-formatted version of the message supplements but does not supersede the text-only version of the message. [15]

In Jabber/XMPP communications, the meaning (as opposed to markup) of the message MUST always be represented as best as possible in the normal <body/> child element or elements of the <message/> stanza qualified by the 'jabber:client' (or 'jabber:server') namespace. Lightweight text markup is then provided within an <html/> element qualified by the 'http://jabber.org/protocol/xhtml-im' namespace. [16] However, this <html/> element is used solely as a "wrapper" for the XHTML content itself, which content is encapsulated via one or more <body/> elements qualified by the 'http://www.w3.org/1999/xhtml' namespace, along with appropriate child elements thereof.

The following example illustrates this approach.

Example 1. A simple example

<message>
  <body>hi!</body>
  <html xmlns='http://jabber.org/protocol/xhtml-im'>
    <body xmlns='http://www.w3.org/1999/xhtml'>
      <p style='font-weight:bold'>hi!</p>
    </body>
  </html>
</message>
  

Technically speaking, there are three aspects to the approach taken herein:

1. Definition of the <html/> "wrapper" element, which functions as an XMPP extension within XMPP <message/> stanzas.
2. Definition of the XHTML-IM Integration Set itself in terms of supported XHTML 1.0 modules, using the concepts defined in Modularization of XHTML [17].
3. A recommended "profile" regarding the specific XHTML 1.0 elements and attributes to be supported from each XHTML 1.0 module.

These three aspects are defined in the three document sections that follow.

5. Wrapper Element

The root element for including XHTML content within XMPP stanzas is <html/>. This element is qualified by the 'http://jabber.org/protocol/xhtml-im' namespace. From the perspective of XMPP, the wrapper element functions as an XMPP extension element; from the perspective of XHTML, it functions as a wrapper for XHTML 1.0 content qualified by the 'http://www.w3.org/1999/xhtml' namespace. Such XHTML content MUST be contained in one or more <body/> elements qualified by the 'http://www.w3.org/1999/xhtml' namespace and MUST conform to the XHTML-IM Integration Set defined in the following section. If more than one <body/> element is included in the <html/> wrapper element, each <body/> element MUST possess an 'xml:lang' attribute with a distinct value, where the value of that attribute MUST adhere to the rules defined in RFC 5646 [18]. A formal definition of the <html/> element is provided in the XHTML-IM Wrapper Schema.

The XHTML <body/> element is not to be confused with the XMPP <body/> element, which is a child of a <message/> stanza and is qualified by the 'jabber:client' or 'jabber:server' namespace as described in XMPP IM [19]. The <html/> wrapper element is intended for inclusion only as a direct child element of the XMPP <message/> stanza and only in order to specify a marked-up version of the message <body/> element or elements, but MAY be included elsewhere in accordance with the "extended namespace" rules defined in the XMPP IM specification.

Until and unless (1) additional integration sets are defined and (2) mechanisms are specified for discovering or negotiating which integration sets are supported, the XHTML markup contained within the <html/> wrapper element:

1. MUST NOT include elements and attributes that are not part of the XHTML-IM Integration Set defined in Section 6 of this document; any such elements and attributes MUST be ignored if received.
2. SHOULD NOT include elements and attributes that are not part of the recommended profile of the XHTML-IM Integration Set defined in Section 7 of this document; any such elements and attributes SHOULD be ignored if received.

Note: In the foregoing restrictions, the meaning of "ignore" is defined by the conformance requirements of Modularization of XHTML, as summarized in the User Agent Conformance section of this document).

6. XHTML-IM Integration Set

This section defines an XHTML 1.0 Integration Set for use in the context of instant messaging. Given its intended usage, we label it "XHTML-IM".

Modularization of XHTML provides the ability to formally define subsets of XHTML 1.0 via the concept of "modularization" (which may be familiar from XHTML Basic [20]). Many of the defined modules are not necessary or useful in the context of instant messaging, and in the context of Jabber/XMPP instant messaging specifically some modules have been superseded by well-defined XMPP extensions. This document specifies that XHTML-IM shall be based on the following XHTML 1.0 modules:

• Core Modules
  • Structure Module
  • Text Module
  • Hypertext Module
  • List Module
• Image Module
• Style Attribute Module

Modularization of XHTML defines many additional modules, such as Table Modules, Form Modules, Object Modules, and Frame Modules. None of these modules is part of the XHTML-IM Integration Set. If support for such modules is desired, it MUST be defined in a separate and distinct integration set.

7. Recommended Profile

Even within the restricted set of modules specified as defining the XHTML-IM Integration Set (see preceding section), some elements and attributes are inappropriate or unnecessary for the purpose of instant messaging; although such elements and attributes MAY be included in accordance with the XHTML-IM Integration Set, further recommended restrictions regarding which elements and attributes to include in XHTML content are specified below.

8. Business Rules

The following rules apply to the generation and processing of XHTML content by Jabber clients or other XMPP entities.

1. XHTML-IM content is designed to provide a formatted version of the XML character data provided in the <body/> of an XMPP <message/> stanza; if such content is included in an XMPP message, the <html/> element MUST be a direct child of the <message/> stanza and the XHTML-IM content MUST be understood as a formatted version of the message body. XHTML-IM content MAY be included within XMPP <iq/> stanzas (or children thereof), but any such usage is undefined. In order to preserve bandwidth, XHTML-IM content SHOULD NOT be included within XMPP <presence/> stanzas; however, if it is so included, the <html/> element MUST be a direct child of the <presence/> stanza and the XHTML-IM content MUST be understood as a formatted version of the XML character data provided in the <status/> element.

2. The sending client MUST ensure that, if XHTML content is sent, its meaning is the same as that of the plaintext version, and that the two versions differ only in markup rather than meaning.

3. XHTML-IM is a reduced set of XHTML 1.0 and thus also of XML 1.0. Therefore all opening tags MUST be completed by inclusion of an appropriate closing tag.

4. XMPP Core specifies that an XMPP <message/> MAY contain more than one <body/> child as long as each <body/> possesses an 'xml:lang' attribute with a distinct value. In order to ensure correct internationalization, if an XMPP <message/> stanza contains more than one <body/> child and is also sent as XHTML-IM, the <html/> element SHOULD also contain more than one <body/> child, with one such element for each <body/> child of the <message/> stanza (distinguished by an appropriate 'xml:lang' attribute).

5. Section 11.1 of XMPP Core stipulates that character entities other than the five general entities defined in Section 4.6 of the XML specification (i.e., &lt;, &gt;, &amp;, &apos;, and &quot;) MUST NOT be sent over an XML stream. Therefore implementations of XHTML-IM MUST NOT include predefined XHTML 1.0 entities such as &nbsp; -- instead, implementations MUST use the equivalent character references as specified in Section 4.1 of the XML specification (even in non-obvious places such as URIs that are included in the 'href' attribute).

6. For elements and attributes qualified by the 'http://www.w3.org/1999/xhtml' namespace, user agent conformance is guided by the requirements defined in Modularization of XHTML; for details, refer to the User Agent Conformance section of this document.

7. The use of structural elements is NOT RECOMMENDED where presentational styles are desired, which is why very few structural elements are specified herein. Implementations SHOULD use appropriate 'style' attributes (e.g., <span style='font-weight: bold'>this is bold</span> and <p style='margin-left: 5%'>this is indented</p>) rather than XHTML structural elements (e.g., <strong/> and <blockquote/>) wherever possible.

8. Nesting of block structural elements (<p/>) and list elements (<dl/>, <ol/>, <ul/>) is NOT RECOMMENDED, except within <div/> elements.

9. It is RECOMMENDED for implementations to replace line breaks with the <br/> element and to replace significant whitepace with the appropriate number of non-breaking spaces (via the NO-BREAK SPACE character or its equivalent), where "significant whitespace" means whitespace that makes some material difference (e.g., one or more spaces at the beginning of a line or more than one space anywhere else within a line), not "normal" whitespace separating words or punctuation.

10. When rendering XHTML-IM content, a user agent SHOULD NOT render as a hyperlink text that is not structured via the <a/> element from the Hypertext Module; therefore if the sender wishes text to be linked, the sending user agent MUST represent the text using the <a/> element and appropriate attributes.

9. Examples

The following examples provide an insight into the inclusion of XHTML content in XMPP <message/> stanzas but are by no means exhaustive or definitive.

(Note: The examples might not render correctly in all web browsers, since not all web browsers comply fully with the XHTML 1.0 and CSS1 standards. Markup in the examples may include line breaks for readability. Example renderings are shown with a colored background to set them off from the rest of the text.)

Example 2. Emphasis, font colors, strength

<message>
  <body>Wow, I&apos;m green with envy!</body>
  <html xmlns='http://jabber.org/protocol/xhtml-im'>
    <body xmlns='http://www.w3.org/1999/xhtml'>
      <p style='font-size:large'>
        <em>Wow</em>, I&apos;m <span style='color:green'>green</span>
        with <strong>envy</strong>!
      </p>
    </body>
  </html>
</message>
  

This could be rendered as follows:

Example 3. Blockquote, cite

<message>
  <body>As Emerson said in his essay Self-Reliance:

     &quot;A foolish consistency is the hobgoblin of little minds.&quot;
  </body>
  <html xmlns='http://jabber.org/protocol/xhtml-im'>
    <body xmlns='http://www.w3.org/1999/xhtml'>
      <p>As Emerson said in his essay <cite>Self-Reliance</cite>:</p>
      <blockquote>
        &quot;A foolish consistency is the hobgoblin of little minds.&quot;
      </blockquote>
    </body>
  </html>
</message>
  

This could be rendered as follows:

Example 4. An image and a hyperlink

<message>
  <body>Hey, are you licensed to Jabber?

  http://www.xmpp.org/images/psa-license.jpg
  </body>
  <html xmlns='http://jabber.org/protocol/xhtml-im'>
    <body xmlns='http://www.w3.org/1999/xhtml'>
      <p>Hey, are you licensed to <a href='http://www.jabber.org/'>Jabber</a>?</p>
      <p><img src='http://www.xmpp.org/images/psa-license.jpg'
              alt='A License to Jabber'
              height='261'
              width='537'/></p>
    </body>
  </html>
</message>
  

This could be rendered as follows:

Note the large size of the image. Including the 'height' and 'width' attributes is therefore quite friendly, since it gives the receiving application hints as to whether the image is too large to fit into the current interface (naturally, these are hints only and cannot necessarily be relied upon in determining the size of the image).

Rendering the 'alt' value rather than the image would yield something like the following:

Example 5. Two lists

<message>
  <body>Here&apos;s my .plan for today:
  1. Add the following examples to XEP-0071:
     - ordered and unordered lists
     - more styles (e.g., indentation)
  2. Kick back and relax
  </body>
  <html xmlns='http://jabber.org/protocol/xhtml-im'>
    <body xmlns='http://www.w3.org/1999/xhtml'>
      <p>Here&apos;s my .plan for today:</p>
      <ol>
        <li>Add the following examples to XEP-0071:
          <ul>
            <li>ordered and unordered lists</li>
            <li>more styles (e.g., indentation)</li>
          </ul>
        </li>
        <li>Kick back and relax</li>
      </ol>
    </body>
  </html>
</message>
  

This could be rendered as follows:

Example 6. Quoted text

<message>
  <body>
You wrote:

   I think we have consensus on the following:

   1. Remove <div/>
   2. Nesting is not recommended
   3. Don't preserve whitespace

   Yes, no, maybe?

That seems fine to me.
  </body>
  <html xmlns='http://jabber.org/protocol/xhtml-im'>
    <body xmlns='http://www.w3.org/1999/xhtml'>
      <p>You wrote:</p>
      <blockquote>
        <p>I think we have consensus on the following:</p>
        <ol>
          <li>Remove &lt;div/&gt;</li>
          <li>Nesting is not recommended</li>
          <li>Don't preserve whitespace</li>
        </ol>
        <p>Yes, no, maybe?</p>
      </blockquote>
      <p>That seems fine to me.</p>
    </body>
  </html>
</message>
  

Although quoting received messages is relatively uncommon in IM, it does happen. This could be rendered as follows:

Example 7. Multiple bodies

<message>
  <body xml:lang='en-US'>awesome!</body>
  <body xml:lang='de-DE'>ausgezeichnet!</body>
  <html xmlns='http://jabber.org/protocol/xhtml-im'>
    <body xml:lang='en-US' xmlns='http://www.w3.org/1999/xhtml'>
      <p><strong>awesome!</strong></p>
    </body>
    <body xml:lang='de-DE' xmlns='http://www.w3.org/1999/xhtml'>
      <p><strong>ausgezeichnet!</strong></p>
    </body>
  </html>
</message>
  

How multiple bodies would best be rendered will depend on the user agent and relevant application. For example, a specialized Jabber client that is used in foreign language instruction might show two languages side by side, whereas a dedicated IM client might show content only in a human user's preferred language as captured in the client configuration.

Example 8. Unrecognized Elements and Attributes

<message>
  <body>
    The XHTML user agent conformance requirements say to ignore
    elements and attributes you don't understand, to wit:

      4. If a user agent encounters an element it does 
         not recognize, it must continue to process the 
         children of that element. If the content is text, 
         the text must be presented to the user.

      5. If a user agent encounters an attribute it does 
         not recognize, it must ignore the entire attribute 
         specification (i.e., the attribute and its value).
  </body>
  <html xmlns='http://jabber.org/protocol/xhtml-im'>
    <body xmlns='http://www.w3.org/1999/xhtml'>
      <p>The <acronym>XHTML</acronym> user agent conformance 
         requirements say to ignore elements and attributes 
         you don't understand, to wit:</p>
      <ol type='1' start='4'>
        <li><p>
          If a user agent encounters an element it does 
          not recognize, it must continue to process the 
          children of that element. If the content is text,
          the text must be presented to the user.
        </p></li>
        <li><p>
          If a user agent encounters an attribute it does 
          not recognize, it must ignore the entire attribute 
          specification (i.e., the attribute and its value).
        </p></li>
      </ol>
    </body>
  </html>
</message>
  

Let us assume that the recipient's user agent recognizes neither the <acronym/> element (which is discouraged in XHTML-IM) nor the 'type' and 'start' attributes of the <ol/> element (which, after all, were deprecated in HTML 4.0), and that it does not render nested elements (e.g., the <p/> elements within the <li/> elements); in this case, it could render the content as follows (note that the element value is shown as text and the attribute value is not rendered):

10. Discovering Support for XHTML-IM

This section describes methods for discovering whether a Jabber client or other XMPP entity supports the protocol defined herein.

<iq type='get'
    from='juliet@shakespeare.lit/balcony'
    to='romeo@shakespeare.lit/orchard'
    id='disco1'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
    

<iq type='result'
    from='romeo@shakespeare.lit/orchard'
    to='juliet@shakespeare.lit/balcony'
    id='disco1'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    ...
    <feature var='http://jabber.org/protocol/xhtml-im'/>
    ...
  </query>
</iq>
    

11. Security Considerations

12. W3C Considerations

The usage of XHTML 1.0 defined herein meets the requirements for XHTML 1.0 Integration Set document type conformance as defined in Section 3 ("Conformance Definition") of Modularization of XHTML.

-//JSF//DTD Instant Messaging with XHTML//EN
    

13. IANA Considerations

This document requires no interaction with the Internet Assigned Numbers Authority (IANA) [30].

14. XMPP Registrar Considerations

15. XML Schemas

<?xml version='1.0' encoding='UTF-8'?>

<xs:schema
    xmlns:xs='http://www.w3.org/2001/XMLSchema'
    xmlns:xhtml='http://www.w3.org/1999/xhtml'
    targetNamespace='http://jabber.org/protocol/xhtml-im'
    xmlns='http://jabber.org/protocol/xhtml-im'
    elementFormDefault='qualified'>

  <xs:import namespace='http://www.w3.org/1999/xhtml'
             schemaLocation='http://www.w3.org/2002/08/xhtml/xhtml1-strict.xsd'/>

  <xs:annotation>
    <xs:documentation>

      This schema defines the <html/> element qualified by
      the 'http://jabber.org/protocol/xhtml-im' namespace.
      The only allowable child is a <body/> element qualified
      by the 'http://www.w3.org/1999/xhtml' namespace. Refer 
      to the XHTML-IM schema driver for the definition of the 
      XHTML 1.0 Integration Set.

      Full documentation of this Integration Set is contained in
      "XEP-0071: XHTML-IM", a specification published by the
      XMPP Standards Foundation.

         http://www.xmpp.org/extensions/xep-0071.html

    </xs:documentation>
    <xs:documentation source="http://www.xmpp.org/extensions/xep-0071.html"/>
  </xs:annotation>

  <xs:element name='html'>
    <xs:complexType>
      <xs:sequence>
        <xs:element ref='xhtml:body' 
                    minOccurs='0' 
                    maxOccurs='unbounded'/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

</xs:schema>
    

<?xml version='1.0' encoding='UTF-8'?>

<xs:schema
    xmlns:xs='http://www.w3.org/2001/XMLSchema'
    targetNamespace='http://www.w3.org/1999/xhtml'
    xmlns='http://www.w3.org/1999/xhtml'
    elementFormDefault='qualified'>

  <xs:annotation>
    <xs:documentation>

      This is the XML Schema driver for XHTML-IM, an XHTML 1.0
      Integration Set for use in exchanging marked-up instant
      messages between entities that conform to the Extensible
      Messaging and Presence Protocol (XMPP). This Integration
      Set includes a subset of the modules defined for XHTML 1.0
      but does not redefine any existing modules, nor does it
      define any new modules. Specifically, it includes the
      following modules only:

         - Structure
         - Text
         - Hypertext
         - List
         - Image
         - Style Attribute
     
      The Formal Public Identifier (FPI) for this Integration
      Set is:

         -//JSF//DTD Instant Messaging with XHTML//EN

      Full documentation of this Integration Set is contained in
      "XEP-0071: XHTML-IM", a specification published by the
      XMPP Standards Foundation, which is available at the
      following URL:

         http://www.xmpp.org/extensions/xep-0071.html

    </xs:documentation>
    <xs:documentation source="http://www.xmpp.org/extensions/xep-0071.html"/>
  </xs:annotation>

  <xs:include 
      schemaLocation="http://www.w3.org/MarkUp/SCHEMA/xhtml-blkphras-1.xsd"/>
  <xs:include 
      schemaLocation="http://www.w3.org/MarkUp/SCHEMA/xhtml-blkstruct-1.xsd"/>
  <xs:include 
      schemaLocation="http://www.w3.org/MarkUp/SCHEMA/xhtml-hypertext-1.xsd"/>
  <xs:include 
      schemaLocation="http://www.w3.org/MarkUp/SCHEMA/xhtml-image-1.xsd"/>
  <xs:include 
      schemaLocation="http://www.w3.org/MarkUp/SCHEMA/xhtml-inlphras-1.xsd"/>
  <xs:include 
      schemaLocation="http://www.w3.org/MarkUp/SCHEMA/xhtml-inlstruct-1.xsd"/>
  <xs:include 
      schemaLocation="http://www.w3.org/MarkUp/SCHEMA/xhtml-inlstyle-1.xsd"/>
  <xs:include 
      schemaLocation="http://www.w3.org/MarkUp/SCHEMA/xhtml-list-1.xsd"/>
  <xs:include 
      schemaLocation="http://www.w3.org/MarkUp/SCHEMA/xhtml-struct-1.xsd"/>

</xs:schema>
    

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
           targetNamespace="http://www.w3.org/1999/xhtml"
           xmlns="http://www.w3.org/1999/xhtml">

  <xs:annotation>
    <xs:documentation>

      This is the XML Schema module of named XHTML 1.0 content models 
      for XHTML-IM, an XHTML 1.0 Integration Set for use in exchanging 
      marked-up instant messages between entities that conform to 
      the Extensible Messaging and Presence Protocol (XMPP). This 
      Integration Set includes a subset of the modules defined for 
      XHTML 1.0 but does not redefine any existing modules, nor 
      does it define any new modules. Specifically, it includes the 
      following modules only:

         - Structure
         - Text
         - Hypertext
         - List
         - Image
         - Style Attribute
     
      Therefore XHTML-IM uses the following content models:

          Block.mix;            Block-like elements, e.g., paragraphs
          Flow.mix;             Any block or inline elements
          Inline.mix;           Character-level elements
          InlineNoAnchor.class; Anchor element
          InlinePre.mix;        Pre element

      XHTML-IM also uses the following Attribute Groups:

           Core.extra.attrib
           I18n.extra.attrib
           Common.extra

      Full documentation of this Integration Set is contained in
      "XEP-0071: XHTML-IM", a specification published by the
      XMPP Standards Foundation.

         http://www.xmpp.org/extensions/xep-0071.html

    </xs:documentation>
    <xs:documentation source="http://www.xmpp.org/extensions/xep-0071.html"/>
  </xs:annotation>

  <!-- BEGIN ATTRIBUTE GROUPS -->

  <xs:attributeGroup name="Core.extra.attrib"/>
  <xs:attributeGroup name="I18n.extra.attrib"/>
  <xs:attributeGroup name="Common.extra">
    <xs:attributeGroup ref="style.attrib"/>
  </xs:attributeGroup>

  <!-- END ATTRIBUTE GROUPS -->

  <!-- BEGIN HYPERTEXT MODULE "PRIMITIVES" -->

  <xs:group name="Anchor.class">
    <xs:sequence>
      <xs:element ref="a"/>
    </xs:sequence>
  </xs:group>

  <!-- END HYPERTEXT MODULE "PRIMITIVES" -->

  <!-- BEGIN IMAGE MODULE "PRIMITIVES" -->

  <xs:group name="Image.class">
    <xs:choice>
      <xs:element ref="img"/>
    </xs:choice>
  </xs:group>

  <!-- END IMAGE MODULE "PRIMITIVES" -->

  <!-- BEGIN LIST MODULE "PRIMITIVES" -->

  <xs:group name="List.class">
    <xs:choice>
      <xs:element ref="ul"/>
      <xs:element ref="ol"/>
      <xs:element ref="dl"/>
    </xs:choice>
  </xs:group>

  <!-- END LIST MODULE "PRIMITIVES" -->

  <!-- BEGIN TEXT MODULE "PRIMITIVES" -->

  <xs:group name="BlkPhras.class">
    <xs:choice>
      <xs:element ref="address"/>
      <xs:element ref="blockquote"/>
      <xs:element ref="pre"/>
    </xs:choice>
  </xs:group>

  <xs:group name="BlkStruct.class">
    <xs:choice>
      <xs:element ref="div"/>
      <xs:element ref="p"/>
    </xs:choice>
  </xs:group>

  <xs:group name="Heading.class">
    <xs:choice>
      <xs:element ref="h1"/>
      <xs:element ref="h2"/>
      <xs:element ref="h3"/>
      <xs:element ref="h4"/>
      <xs:element ref="h5"/>
      <xs:element ref="h6"/>
    </xs:choice>
  </xs:group>

  <xs:group name="InlPhras.class">
    <xs:choice>
      <xs:element ref="abbr"/>
      <xs:element ref="acronym"/>
      <xs:element ref="cite"/>
      <xs:element ref="code"/>
      <xs:element ref="dfn"/>
      <xs:element ref="em"/>
      <xs:element ref="kbd"/>
      <xs:element ref="q"/>
      <xs:element ref="samp"/>
      <xs:element ref="strong"/>
      <xs:element ref="var"/>
    </xs:choice>
  </xs:group>

  <xs:group name="InlStruct.class">
    <xs:choice>
      <xs:element ref="br"/>
      <xs:element ref="span"/>
    </xs:choice>
  </xs:group>

  <!-- END TEXT MODULE "PRIMITIVES" -->

  <!-- BEGIN BLOCK COMBINATIONS -->

  <xs:group name="Block.class">
    <xs:choice>
      <xs:group ref="BlkPhras.class"/>
      <xs:group ref="BlkStruct.class"/>
    </xs:choice>
  </xs:group>

  <!-- END BLOCK COMBINATIONS -->

  <!-- BEGIN INLINE COMBINATIONS -->

  <!-- Any inline content -->
  <xs:group name="Inline.class">
    <xs:choice>
      <xs:group ref="Anchor.class"/>
      <xs:group ref="Image.class"/>
      <xs:group ref="InlPhras.class"/>
      <xs:group ref="InlStruct.class"/>
    </xs:choice>
  </xs:group>

  <!-- Inline content contained in a hyperlink -->
  <xs:group name="InlNoAnchor.class">
    <xs:choice>
      <xs:group ref="Image.class"/>
      <xs:group ref="InlStruct.class"/>
      <xs:group ref="InlPhras.class"/>
    </xs:choice>
  </xs:group>

  <!-- END INLINE COMBINATIONS -->

  <!-- BEGIN TOP-LEVEL MIXES -->

  <xs:group name="Block.mix">
    <xs:choice>
      <xs:group ref="Block.class"/>
      <xs:group ref="Heading.class"/>
      <xs:group ref="List.class"/>
    </xs:choice>
  </xs:group>

  <xs:group name="Flow.mix">
    <xs:choice>
      <xs:group ref="Block.class"/>
      <xs:group ref="Heading.class"/>
      <xs:group ref="Inline.class"/>
      <xs:group ref="List.class"/>
    </xs:choice>
  </xs:group>

  <xs:group name="Inline.mix">
    <xs:choice>
      <xs:group ref="Inline.class"/>
    </xs:choice>
  </xs:group>

  <xs:group name="InlNoAnchor.mix">
    <xs:choice>
      <xs:group ref="InlNoAnchor.class"/>
    </xs:choice>
  </xs:group>

  <xs:group name="InlinePre.mix">
    <xs:choice>
      <xs:group ref="Anchor.class"/>
      <xs:group ref="InlPhras.class"/>
      <xs:group ref="InlStruct.class"/>
    </xs:choice>
  </xs:group>

  <!-- END TOP-LEVEL MIXES -->

</xs:schema>
    

16. Acknowledgements

This specification formalizes and extends earlier work by Jeremie Miller and Julian Missig on XHTML formatting of Jabber messages. Many thanks to Shane McCarron for his assistance regarding XHTML modularization and conformance issues. Thanks also to contributors on the discussion list of the XSF's Standards SIG [32] for their feedback and suggestions.

Appendices

Appendix A: Document Information

Series: XEP
Number: 0071
Publisher: XMPP Standards Foundation
Status: Draft
Type: Standards Track
Version: 1.4
Last Updated: 2008-09-03
Approving Body: XMPP Council
Dependencies: XMPP Core, XMPP IM, XHTML 1.0, Modularization of XHTML, XEP-0030
Supersedes: None
Superseded By: None
Short Name: xhtml-im
XML Schema for wrapper namespace namespace: <http://www.xmpp.org/schemas/xhtml-im-wrapper.xsd>
XML Schema for schema driver namespace: <http://www.xmpp.org/schemas/xhtml-im-driver.xsd>
XML Schema for content model namespace: <http://www.xmpp.org/schemas/xhtml-im-model.xsd>
Source Control: HTML
This document in other formats: XML  PDF

Appendix B: Author Information

Appendix C: Legal Notices

Appendix D: Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.

Appendix E: Discussion Venue

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Discussion on other xmpp.org discussion lists might also be appropriate; see <http://xmpp.org/about/discuss.shtml> for a complete list.

Errata can be sent to <editor@xmpp.org>.

Appendix F: Requirements Conformance

The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".

Appendix G: Notes

Appendix H: Revision History

Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/

END