HTML5 was specified with the target of creating convergence among a wide range of interoperable browsers, which resulted from proprietary extensions of earlier HTML versions to fill identified gaps. HTML5 also defines and for the first time error handling procedures to deal with document processing errors to help circumvent minor but common syntactical mistakes. As part of the simplicity goal, HTML5 aims at operating in a plugin-free environment by providing APIs to fulfil most of the plugin needs. Finally, HTML5 aims at simplifying the syntax to ease authoring of web applications.

HTML5 defines a set of new elements that are discussed in the following list:

• Video: a standard way to embed video content on a web page without using browser plugins. The playback controls are provided through Javascript.
• Audio: a standard way to embed audio content on a web page without using browser plugins.
• Canvas: a resolution-dependent bitmap canvas together with scripts that are used for rendering graphs, game graphics, or other visual images on the fly.
• Svg: HTML5 provides support for inline SVG fragments as well as a fallback mechanism for browsers that do not support SVG.
• Article: specifies independent self-contained content. An article should make sense on its own and should be distributable independently from the rest of the site.
• Header: specifies a header for a document or section. This element should be used as a container for introductory content or set of navigational links.
• Footer: defines a footer for a document or section. A footer element should contain information about its containing element.
• Output: represents the result of a calculation.
• Source: is used to specify multiple media resources for media elements such as video and audio. The source tag allows to specific alternative video/audio files, which the browser may choose from, based on its media type or codec support.
• Time: defines either a time or a date in the Gregorian calendar, optionally with a time and time-zone.
• Input/capture: although the <input> tag is not new for HTML5, the capture attribute is. This allows for media capture and file upload [21].

3GPP services do not have a common solution for a presentation layer. This fragmentation in the scene description landscape for 3GPP services complicates content preparation and UE implementation. A common and modern scene description solution is due in Release 12 to make use of the modern multimedia capabilities of UEs. Table 1 shows the different presentation solutions and in which 3GPP services they are used.

XHTML Mobile Profile was defined by the Open Mobile Alliance as a markup language that is designed for resource-constrained web clients, such as the ones on mobile phones and set-top boxes. The XHTML Mobile Profile is based on the XHTML Basic profile. XHTML Mobile Profile requires support for the following modules:

• XHTML Structure module: defines the major structural elements for XHTML (e.g. body, head, html, and title).
• XHTML Text module: defines all the basic text container elements, attributes and their content model (e.g. h1, br, and div).
• XHTML Hypertext module: defines the "a" element to define hypertext links to other resources.
• XHTML List module: provides the elements that enable creating lists (e.g. li).
• XHTML Forms module: provides the form-related elements (e.g. form and input).
• XHTML Basic Tables module: defines the table-related elements (e.g. table, tr, and td).
• XHTML Image module: defines the "img" element to enable embedding images in the document.
• XHTML Object module: provides elements for general-purpose object embedding.
• XHTML Metainformation module: defines the "meta" element that describes information within the declarative portion of a document.
• XHTML Link module: defines the "link" element that can be used to link external resources.
• XHTML Base module: defines the "base" element that can be used to define a base URI against which relative URIs in the document will be resolved.
• XHTML Intrinsic module: defines a set of intrinsic events and attributes that pertain to elements that fire those events (e.g. onload or onsubmit).
• XHTML Style Sheet module: defines the "style" element to be used when declaring internal style sheets.
• XHTML Style Attribute module: defines the "style" attribute.
• XHTML Scripting module: defines elements that are used to contain information related to executable scripts (e.g. script element).
• XHTML Presentation module: defines elements and attributes for simple presentation-related markup (e.g. b and hr).
• XHTML Target module: adds the "target" attribute to control the window where the link is to be opened.
• XHTML inputmode Attribute module: defines a new attribute that is used to indicate the input mode to certain editable fields.

XHTML Mobile Profile supports the use of CSS styles to control the presentation. Style information may be associated with a document as external style sheets, internal style sheets, or as internal style information. XHTML Mobile Profile supports scripting through the Scripting Module defined by XHTMLMod. The Scripting Module defines elements and attributes used to contain information pertaining to executable scripts. The syntax and semantics of these elements and attributes are defined by HTML4. User agents complying to this profile support ECMAScript and Javascript scripts. The XHTML Mobile Profile defines a profile of the W3C DOM event model. In particular, several events have been excluded in the Mobile Profile. For instance, event capture and event dispatching have been excluded for simplicity.

Dynamic and Interactive Multimedia Scenes (DIMS) defines a scene description framework that supports dynamic and interactive scenes. DIMS allows frame-accurate media synchronization. DIMS services are comprised of a scene description and a set of discrete and continuous media. DIMS defines means to store and stream a media scene description, its updates, and the related events. The scene description is based on the SVG Tiny 1.2 format. DIMS adds several extensions on top of SVG Tiny 1.2 that are borrowed from other specifications such as LASeR and SMIL. DIMS defines its own mechanism for supporting scene updates. It defines the "updates" element as part of a DIMS namespace to link the scene update stream to the main scene. DIMS also defines two new events to signal orientation changes in mobile devices. The signals may be used by the scene to adjust the content according to the orientation. To enable tune-in at random points, the concept of RAPs in scene updates is defined. Scene updates are a set of update commands that tell the client how to modify the current DOM and at which time this modification needs to be done. The commands include Insert, Delete, Replace, and Add command, which apply directly to the DOM. In addition, some state management command are also introduced. These are the Save, Restore, and Clean commands, which are used to control persistent storage and caching of media scenes at the client side. Finally, an Activate and a Deactivate command are defined to temporarily enable or disable elements in the DOM tree. DIMS supports scripting through the usage of the mobile profile of the ECMAScript scripting language. DIMS events and event handling are inherited from SVG and XML events. To support streaming of dynamic media scenes, an RTP payload format is defined in DIMS. The RTP payload format enables tune-in at RAPs as well as error resilience tools to recover from lost update fragments.

3GPP SMIL is a markup language based on SMIL Basic and SMIL Scalability Framework. In addition to the modules that are required by the SMIL Basic profile, a set of additional modules are required by the 3GPP SMIL profile. The following sets of modules are included in the 3GPP SMIL profile:

• SMIL 2.0 Content Control Modules: BasicContentControl, SkipContentControl and PrefetchControl
• SMIL 2.0 Layout Module: BasicLayout
• SMIL 2.0 Linking Module: BasicLinking, LinkingAttributes
• SMIL 2.0 Media Object Modules: BasicMedia, MediaClipping, MediaParameter, MediaAccessibility and MediaDescription
• SMIL 2.0 Metainformation Module: Metainformation
• SMIL 2.0 Structure Module: Structure
• SMIL 2.0 Timing and Synchronization Modules: BasicInlineTiming, MinMaxTiming, BasicTimeContainers, RepeatTiming and EventTiming
• SMIL 2.0 Transition Effects Module: BasicTransitions

The Content Control Modules defines elements and attributes for content control. The Layout module defines attributes to control the spatial layout. The Linking module defines elements and attributes for providing hyperlinks between documents and document fragments. The Media Object modules include the basic media elements and the control attributes. The Metainformation module defines the "meta" and "metadata" elements that are included as part of the head element. The Structure module defines the top-level structure elements of the SMIL document. The Timing and Synchronization modules define attributes for timing and synchronizing the playback of media elements. Finally, the Transition Effects module defines a set of transition effects for images and media elements.

HTML5 provides an API for performing scene updates in the background. XMLHttpRequest (usually named as AJAX) is used in a scripting environment to load resources in the background. The information loaded may then be used to update the scene using Javascript operations on the DOM. The new presentation layer using HTML5 should require support for XMLHttpRequest. In addition, for eMBMS services the delivery of scene updates through MBMS download delivery needs to be enabled. In eMBMS services, it needs to be possible to provide scene updates over the unidirectional channel as is the case with DIMS over MBMS.

The scene updates are in fact DOM updates to the DOM tree of the HTML5 document, which constitutes the scene. The scene updates may be related to the media, related to the spatial layout, or related to the presentation style of particular parts of the document. The scene update solution should support all three sorts of updates. Scene updates can be described in different ways. A simple solution is to programmatically hard-code all DOM tree updates using scripting, i.e. Javascript (i.e. the scene updates are provided as Javascript instructions and not as an external file). This has several drawbacks such as the inadequate support for dynamic scenes as the updates would need to be known a-priori, the complex scene authoring as it requires programming skills and a customized script for every single program or presentation. Javascript instruction itself may include HTTP requests that enable updates to the DOM where the instruction format may remain proprietary. The open issue here is that the delivery formats are transparent to the delivery and the delivery through 3GPP user services such as in MBMS and PSS is to be defined. Another way of describing DOM updates is to use XHTML and deliver the changes to the actual XHTML as deltas, e.g. using XML patch as described in RFC 5261. This approach handles the HTML5 document as a regular XML document, which results on restrictions on the subset of tools and features that can be supported. This approach would also result in inefficiencies as the target is not to update the HTML5 document itself, but instead to update the DOM that results from parsing the HTML5. The receiver would have to first generate the new HTML5 and then generate the updated DOM. In the worst case, this would even refresh the whole scene as would be the case with updating the HTML5 document itself. Another approach is to describe the DOM updates in a separate document that can be updated and modified without having to update the actual HTML5 document. The update of the present document would also not require programming skills and can be automated or supported by authoring tools fairly easily. We recommend that support for dynamic scene updates be provided for the 3GPP services.

Once the scene update is authored, it has to be made available to the UEs. The distribution of the update may happen in-band or out of band of the media streaming session. One approach for doing in-band delivery is to handle the scene updates as sparse timed media. In that case, the updates are streamed as a component of the media session. This approach has been followed by the DIMS solution. In band channels may be a Representation that exclusively carries the scene updates as timed metadata items or that are encoded as timed text (such as WebVTT or 3GPP timed text). This solution may have implications on the client, as it requires the client to dig into the media data to extract the scene update and then pass it to the HtML5 application. Another way is to send it in band as a separate file, as would be the case when using FLUTE in MBMS environment. For the case of unicast, periodic polling using HTTP where the scene update files are made available via regular web servers is appropriate.