**SMPTE Declarative Data Essence:**

**Comparison to ATSC DASE**

**John Barkley,  Michael Dolan,**

           NIST             Chair, SMPTE DDE

jbarkley@nist.govmiked@tbt.com

**Michael Koo,  Andrew McCaffrey,  Len Gebase,  and Murugiah Souppaya**

NIST

Gaithersburg, MD 20899

# 1 Introduction

Interactive TV (ITV) can be characterized as a convergence of TV and the Internet. Both TV and the Internet, as separate technologies, have already had a profound effect on the economy [BW70]. The effect on the economy of their convergence is expected to be significant. 

Neither TV nor the Internet would have been so successful without standards. Likewise, their convergence, ITV, needs standards in order to succeed. ITV standards are needed in the following areas:

· Content: standards specifying ITV content types. Content producers must know which content types to use in developing ITV applications so that the creation and distribution packages are interoperable.

· Receivers: standards specifying receiver behavior so that content displays the same on all receivers.

· Application Initiation/Termination: standards specifying how ITV applications are initiated and terminated. Content producers must know how to start/stop their applications, and how to ensure that applications do not interfere with each other. 

· Synchronization: standards specifying how content is synchronized with the video/audio broadcast. Content producers must be able to synchronize their ITV applications to the broadcast video/audio so that the same interactive experience is provided to the viewer on all receivers.

· Delivery: standards specifying how content is delivered to the receiver.

The Declarative Data Essence (DDE) Ad-hoc Group of the D27 Technical Committee of the Society for Motion Picture and Television Engineers [SMPTE] is developing ITV standards that provide basic functionality for ITV embodying current practice, known collectively as 

DDE-1. The Advanced Television Enhancement Forum [ATVEF] specification is the basis for the DDE-1 effort. The T3/S17 Specialist Group within the Advanced Television Standards Committee [ATSC] is developing the DTV Application Software Environment (DASE) standard for the next generation of ITV. 

This paper summarizes the SMPTE DDE-1 specifications and compares DDE-1 to DASE. In addition, this paper describes the functionality specified within DDE-1 and DASE that enable content developers to present and manage ITV applications. This paper compares DDE-1 and DASE with regard to: content types, application initiation/termination, synchronization, and content delivery.

Content developers include producers of TV programs and commercials. TV programming consists of entertainment segments interspersed with commercials. Entertainment and commercial segments are usually produced independently from each other. ITV Content developers need to be able to develop content that runs on all receivers, and that does not interfere with content developed independently by others. Both DDE-1 and DASE specify functionality needed for sequencing ITV applications synchronized with a TV broadcast. This paper compares DDE-1 applications (called “enhancements”) and DASE applications, and gives examples of ITV applications. 

# 2 DDE-1 Compared to DASE: Overview

Table 1 provides a summary comparison between DDE-1 and DASE. DDE-1 consists of seven specifications, three for content ([DDE1], [DDE1-DOM0], [DDE1-lid]), and four for binding content to broadcast streams ([DDE1-UHTTP], [DDE1-IPM], [DDE1-NTSC], [DDE1-PAL]). DASE consists of eight specifications ([DASE], [DASE-DA], [DASE-PA], [DASE-API], [DASE-FONT], [DASE-SEC], [DASE-CONF], [ATSC-ARM]). 

In DASE, ITV applications are characterized as either declarative applications (DA), whose content types are primarily Web pages, or procedural applications (PA), whose content types are primarily Java. More specifically, in DASE, a DA is a collection of resources whose “root,” as identified by ATSC A/90 [ATSC-A90] application signaling [ATSC-ARM] (see section 6) is of type application/xdml+xml. A PA is a collection of resources whose root is of type application/javatv-xlet. 

DDE-1 specifies a DA type application. More specifically, DDE-1 applications, commonly called an “enhancements,” are analogous to DASE Purely Declarative Applications (PDA). PDAs are DASE DAs where every resource has a declarative content type. 

Table 1: DDE-1 vs. DASE

Receivers capable of running DDE-1 enhancements have two basic design concepts:

· Embedded within the receiver is Web browser software. The broadcast video and audio can be referenced within the HTML document as the URL “tv:”.

· The two media, TV and the Internet, are synchronized by embedding “triggers” within the broadcast. Triggers are content which upon receipt, signal enhancements to be initiated/terminated, or ECMAScript code to be executed within an enhancement already running.

Every resource in a DDE-1 enhancement or DASE application is one of the content types as shown in table 1. Within the DDE-1 specifications, there is no equivalent to a DASE PA. For more information on differences in content types between DDE-1 and DASE, see section 3.

Both DDE-1 and DASE specify functionality for the initiation and termination of an application. In DDE-1, enhancements are initiated/terminated by triggers. In DASE, applications are initiated by ATSC A/90 application signaling, and terminated by triggers. See Section 4 for more information.

Both DDE-1 and DASE specify functionality, by means of triggers, for synchronizing running ITV applications with the video/audio. However, DDE-1 and DASE triggers have a different format. See section 5 for more information about synchronization.

DDE-1 specifies the delivery of interactive content by either the broadcast or by means of a backchannel, typically an Internet connection. DDE-1 specifies a content binding for NTSC and PAL/SECAM analog systems.  Additionally, 3rd parties have specified its binding to ATSC and DVB.  In all cases, the binding relies on an IP Multicast encapsulation of the data, as defined in DDE-1. DASE specifies interactive content delivery by means of the ATSC A/90 Standard. See section 6 for more information.

# 3 DDE-1 Content Compared to DASE Content

Table 1 shows the content types specified in DDE-1 and DASE. DDE-1 specifies content currently in widespread use not only in ITV, but also on the Web. DASE specifies content more recently adopted and under development by the [W3C], as well as additional types. In addition, DASE specifies Java content types for PAs, which can also be part of DASE DAs. The following subsections compare DDE-1 and DASE content in the categories of content markup, stylesheet, script, and document object model.

## 3.1 Markup Content

DDE-1 specifies HTML 4.0 [HTML4]. DASE DA specifies the content type application/xdml+xml which consists of a subset of  XHTML 1.0. The markup content for both DDE-1 and DASE DAs are very similar. The content type of the root of a DASE DA must be application/xdml+xml. Although markup content for DASE DAs is specified primarily as an XML DTD, the receiver is not required in DASE to be a validating XML processor, i.e., to be capable of validating content relative to any arbitrary DTD. A DASE receiver is only required to validate markup content according to the DTDs defining the content type application/xdml+xml.

## 3.2 Stylesheet Content

DDE-1 specifies Cascading Style Sheets level 1 [CSS1]. DASE DA specifies a subset of Cascading Style Sheets level 2 [CSS2]. CSS2 includes the functionality of CSS1, and  specifies additional selectors. These include new pseudo-elements, e.g., the first letter of a paragraph, and new pseudo-classes, e.g., a link which has been visited. In addition, CSS2 specifies new types of selectors, such as attribute selectors, which can identify markup elements by the presence of an attribute and/or attribute value, and parent/child selectors which can identify markup elements based on a parent/child relationships.

## 3.3 Script Content

DDE-1 specifies ECMAScript 2nd Edition [ES2]. DASE DA specifies ECMAScript 3rd  Edition [ES3], which includes the functionality of ECMAScript 2nd Edition. In addition, ECMAScript 3rd Edition specifies a “switch” statement, try/catch exception handling, and native regular expression objects. The functionality of these regular expression objects is modeled after regular expressions in Perl 5. 

## 3.4 Document Object Model

The document object model for DDE-1 is Document Object Model Level 0 (DOM-0) [DDE1-DOM0]. DOM-0 generally has the functionality of the object model common to both Microsoft Internet Explorer 3.0 and Netscape Navigator 3.0. This functionality is currently in widespread use on the Web today. Figure 1 shows the DOM-0 Objects and their relationships. For these objects, DOM-0 specifies basic functionality for reading/mutating, and processing of events.

DASE DA specifies a subset of the DOM Level 2 (DOM-2) Object Model, specifically, [DOM2-CORE], [DOM2-HTML], [DOM2-VIEWS], [DOM2-STYLE], and [DOM2-EVENTS]. Although the DOM-0 and DOM-2 object models are different, the DOM-2 object model includes most of the functionality of DOM-0 and more. DOM-2 specifies the reading/mutation of almost all elements of an HTML document, in particular scripts and stylesheets. With DOM-2, changing information on a page can be accomplished by mutation, rather than by replacing an entire frame. This is particularly useful when the amount of information to be changed is small, e.g., a number in a table.

The DOM-0 event model is based on intrinsic events as specified in HTML 4 syntax.  In contrast, the DOM-2 event model is more robust and its behavior more well defined. While not technically part of the DOM, both DDE-1 and DASE specify native objects in support of current practice. These are the “Window,” “Location,” “History,” and “Navigator” objects.

Table 2: ITV Application Initiation/Termination

# 4 Application Initiation/Termination

TV programming usually consists of entertainment interspersed with commercials. Content developers for ITV include producers of both kinds of content. Entertainment and commercial segments are usually produced independently. ITV content developers need to be able to develop content that runs on all receivers, and that does not interfere with content developed by others independently. 

DDE-1 specifies a simple ITV application initiation/termination capability, while DASE specifies a more complex capability of initiation, termination, and suspension (see 

[ATSC-ARM], section 5). For example, in DASE, when a viewer changes channel, a DASE application is suspended, and may resume under certain circumstances when the viewer returns to that channel. 

Table 2 summarizes the functionality within DDE-1 and DASE for initiating and terminating an application. The term “producer” refers to the content developer and the term “viewer” refers to the end-user interacting with the content. Within DASE, there is functionality for the producer to craft the application in such a manner so that the viewer can be granted the option for initiating/terminating an application. Within DDE-1, only the producer can initiate an enhancement.

Both DDE-1 and DASE specify receivers minimally capable of running only one DA at a time. Because entertainment and commercial segments of a broadcast are interspersed, producers of ITV applications need to be able to initiate content for their segment, and then, at the end of the segment, terminate their content in order to allow the next segment the opportunity to run. For producers, two approaches to accomplishing this are as follows.

The first approach is for segment producers to develop a DA that establishes control of the receiver at the beginning of their segment, and releases this control at the end of the segment so that the application for the next segment can run (see table 2). In this approach, a DDE-1 enhancement (an HTML document) or a DASE PDA (an XDML document) is instantiated and displayed by the receiver. In DDE-1, this is accomplished by the producer creating an appropriate SDP (Session Description Protocol) record if Transport B (see section 6) and sending a trigger referencing the URL of the new enhancement. In DASE, the producer uses ATSC A/90 application signaling to initiate a new PDA.  In DASE, the producer can also provide the viewer a link within the currently running application to initiate a new application. 

When a segment ends, DDE-1 enhancements can be terminated by a trigger that navigates to the URL “tv:” from the topmost page of the enhancement, or by a producer provided viewer selection within the currently running application that navigates to “tv:” from the topmost page. Navigation to “tv:” from the topmost page also displays full screen video.

Termination of a DASE DA can be accomplished by a trigger that results in the execution of a window::close() within the root top level window object, or by a viewer selection within the currently running application which causes the application root top level window object to execute window::close(). In addition, viewer navigation from the root top level window object to a root entity, which is either content of the type video/mpeg or application/xdml+xml, terminates the current DA. If the content type is video/mpeg, then full screen video is displayed. If the content type is application/xdml+xml, then that content becomes the new DA. 

The second approach is for producers of several sequential segments to share the topmost page of an application. For this approach, content for each segment is presented by means of frames subordinate to the shared single topmost page, which serves as an “executive” for frames associated with the segments. The first approach, described above, is used for initiation/termination of the topmost page of the application. Both DDE-1 and DASE specify functionality which allows an application to be present in the background while the viewer sees the video full screen, as though there were no application running. This is a particularly useful feature for this second approach. The viewer is given the choice of opting out of the interactive experience while the application continues in the background, ready to receive the frames for the next segment.

# 5 Synchronization

In DDE-1, triggers consists of a required URL, the required “tve” attribute which identifies the version of DDE-1 content to which the trigger conforms, optional name/value attributes (“name”, “expires”, “script”), and depending on the means of delivery, a checksum. The URL of the trigger identifies the topmost page, i.e., the root in DASE terminology, of the application. If the URL equals the URL of the root of the currently running application, then the trigger signals the running application; otherwise, the trigger may initiate a new application and must have a “name” attribute to be valid. The “expires” attribute indicates the time after which the trigger is no longer valid. The “script” attribute contains the script text to be executed upon receipt of the trigger. DDE-1 triggers deliver a single signal, i.e., a single script. The target of the script is the trigger’s URL, i.e., the root of the application. For details, see [DDE-1], appendix E.

In DASE, triggers are the content type application/dase-trigger. Like all DASE content, triggers are delivered by means of the ATSC A/90 framework (see section 6). The DASE trigger mechanism is built upon the functionality of DOM-2 Events [DOM2-EVENTS]. A DASE trigger consists of several events of type “script”, i.e., a single DASE trigger can deliver several signals to an application. The target of the script event can be any URI identifying declarative content within the application, and can make use to the “bubbles” and “cancelable” features of DOM-2 Events. Each script event is invoked by means of the DOM-2 Events infrastructure. For details, see [DASE-DA], section 4.5.

# 6 DDE-1 Content Delivery Compared to DASE 

DDE-1 specifies two types of interactive content delivery: Transport A, and Transport B. With Transport A, only triggers are delivered with the broadcast stream. Other primary content is actively acquired by the receiver by means of a backchannel, usually an Internet connection.  DDE-1 specifies an interface that enables an enhancement to obtain information about the availability of a backchannel and whether it is currently connected. The URLs in DDE-1 Transport A triggers identify the content to be fetched over the backchannel using HTTP Version 1.1.

With Transport B, all content, including triggers, are delivered by means of the broadcast stream. A backchannel may optionally be present for transactions or general Web browsing, but content for applications is delivered via the broadcast. DDE-1 Unidirectional Hypertext Transport Protocol (UHTTP) [DDE1-UHTTP] is the protocol used for content delivery in Transport B. The binding of application announcement metadata and UHTTP to IP Multicast is specified in DDE IP Multicast Encapsulation [DDE1-IPM]. The binding of DDE-1 content for both Transport A and Transport B to the NTSC video standard is specified in DDE-1 NTSC IP and Trigger Binding to VBI [DDE1-NTSC]. The binding of DDE-1 content for both Transport A and Transport B to the PAL/SECAM system is specified in DDE-1 TRIGGERS and IP Binding to PAL/SECAM SYSTEM [DDE1-PAL].

In DASE, all content is delivered in the broadcast stream according to ATSC A/90 [ATSC-A90] and the Application Reference Model [ATSC-ARM]. Three types of information about an application are delivered: announcement, signaling, and content. Application announcement information indicates the future availability of an application, and consists of metadata about the application, such as, name, description, availability time and duration. Application signaling information indicates the imminent arrival of an application’s content, and includes the identification of the application’s root entity. Following application announcement and signaling information is the application’s content. Each content element is delivered with its identifier and content type. 

ATSC, in addition to more native generic resource carriage in A/90, also includes a specification for IP Multicast binding [ATSC-IPM]. Thus, with the A/90 and DDE-1 IP Multicast specifications, there is a standard way of broadcasting DDE-1 content with A/90.

For more information about data broadcasting applications, specifically within the ATSC data framework, see [ATSC-DATA].

# 7 Example ITV Applications

Figure 2: Educational ITV Application

ITV applications range in complexity from the very simple to the very sophisticated. An example of a simple ITV application is one which offers the viewer a pizza delivery. This application could be synchronized with the broadcast of a sporting event or a commercial for the pizza retailer. This example illustrates a simple e-commerce application. It is an example of an ITV application designed for the functionality of the backchannel informatively defined in DDE-1. The backchannel, an Internet connection or possibly some form of proprietary phone connection, is the means of completing the real-time transaction implied in this example. 

ITV applications can also provide a richer viewing experience. One such example is an application that provides the viewer the opportunity to interactively obtain additional information about a sporting event during the broadcast. Consider the broadcast of a golf tournament. The viewer is offered the opportunity to browse information about the score for the current player, the details of the current green, player statistics, and information about the tour. This application is an example of an application that can be designed for the functionality of either DDE-1 or DASE. This application requires neither backchannel nor high performance procedural environment.

Figure 2 shows a sophisticated ITV application. It is an educational program for learning about constellations. Developed at NIST, it is an example of an ITV application designed for the functionality specified in DASE. In the application, a narrator first describes several constellations while the outline of the constellation is shown against the star field in the night sky. Then, the viewer is shown a picture of a constellation’s star field, and encouraged to draw the outline of the constellation on the star field shown. The current outline is then displayed along with the viewer’s drawing so that the viewer can compare. Figure 2 shows the narrator along with a viewer’s drawing (shaded lines) of the Big Dipper overlaid with the correct outline (straight white lines).  This application requires local interactivity by the user with a pointing device, such as a mouse, and a high performance procedural application environment.  Hence the need for a DASE-PA like system. 

# 8 Summary

This paper summarized the SMPTE DDE-1 specifications and compared DDE-1 to DASE. In addition, this paper compared DDE-1 applications (“enhancements”) and DASE applications, and summarized the functionality specified within DDE-1 and DASE to enable content developers to present and manage ITV applications. This paper also gave examples of ITV applications.

**Acknowledgements**

The authors would like to thank Dr. Alan Mink and Mary Laamanen of NIST for their reviews of this paper.

# 9 References

[ATSC] Advanced Television Systems Committee, http://www.atsc.org

[ATSC-A90] ATSC Data Broadcast Standard, A/90, Advanced Television Systems Committee, 26 July 2000

[ATSC-ARM] ATSC Data Application Reference Model, ATSC ARM001R1, 17 Apr 2001

[ATSC-DATA] Chernock, et al, “Data Broadcasting: Understanding the ATSC Data Broadcast Standard”, McGraw-Hill, 2001

[ATSC-IPM] DELIVERY OF IP MULTICAST SESSIONS OVER ATSC DATA BROADCAST, ATSC T3/S13-012

[ATVEF] Enhanced Content Specification, v1.1 r26, Advanced Television Enhancement Forum, http://www.atvef.com

[BW70] Business Week, October 4, 1999

[CSS1] Cascading Style Sheets, Level 1, W3C Recommendation

[CSS2] Cascading Style Sheets, Level 2, W3C Recommendation 

DASE Documents: 

ftp://atsc:atsc1080i@ftp.atsc.org/S17/T3/

ftp://atsc:atsc1080i@ftp.atsc.org/S17/

[DASE] DASE Part 1: Introduction, Architecture, and Common Facilities, ATSC T3/528, 9 Feb 2001

[DASE-API] DASE Part 4: Application Programming Interfaces, ATSC T3/531

[DASE-DA] DASE Part 2: Declarative Applications and Environment, ATSC T3/529, 9 Feb 2001

[DASE-CONF] DASE Part 8: Conformance Statement, ATSC T3/S17-xxx

[DASE-FONT] DASE Part 5: Portable Font Resource, ATSC T3/532, 9 Feb 2001

[DASE-PA] DASE Part 3: Procedural Applications and Environment, ATSC T3/530, 9 Feb 2001

[DASE-SEC] DASE Part 6: Security, ATSC T3/S17-xxx

DDE Documents: ftp://smpte.vwh.net/pub/d27/dde.htm

[DDE1] Declarative Data Essence, Content Level 1, SMPTE 363M 

[DDE1-DOM0] Document Object Model Level 0 (DOM-0) and Related Object Environment, SMPT Draft q, 15 March 2001

[DDE1-IPM] Declarative Data Essence - IP Multicast Encapsulation, SMPTE 357M

[DDE1-lid] The Local Identifier (lid:) URI Scheme for Referencing Locally Stored Content Resources, SMPTE Draft g, 18 Apr 2001

[DDE1-NTSC] NTSC IP and Trigger Binding to VBI, DDE-1, SMPTE 361M

[DDE1-PAL] TRIGGERS and IP Binding to PAL/SECAM SYSTEM, SMPTE Draft a, March 2001

[DDE1-UHTTP] Unidirectional Hypertext Transport Protocol, SMPTE 364M

[DOM2-CORE] Document Object Model (DOM) Level 2 Core, W3C Recommendation

[DOM2-EVENTS] Document Object Model (DOM) Level 2 Events, W3C Recommendation

[DOM2-HTML] Document Object Model (DOM) Level 2 HTML, W3C Working Draft

[DOM2-STYLE] Document Object Model (DOM) Level 2 Style, W3C Recommendation

[DOM2-VIEWS] Document Object Model (DOM) Level 2 Views, W3C Recommendation

[ES2] ISO 16262, ECMAScript Language Specification, 2ed Edition

[ES3] ECMAScript Language Specification, 3rd Edition, ECMA

NIST DASE Development Environment:

http://www.itl.nist.gov/div895/cmr/dase/index.html

NIST DDE-1 Trigger Test Materials:

Abstract Test Suite: http://xw2k.sdct.itl.nist.gov/koo/trigger/

Sample Tape Documentation: http://xw2k.sdct.itl.nist.gov/koo/test_suite/

Sample Tape Test Cases: http://xw2k.sdct.itl.nist.gov/koo/test_suite/sample_tape.htm

[SMPTE] Society of Motion Picture and Television Engineers, http://www.smpte.org

[W3C] World Wide Web Consortium, http://www.w3.org

Figure 1: DOM-0 Objects and Their Relationships

images[]

Instances of 

these objects may be

within elements[]

Select

options[]

Button

Checkbox

Text

Textarea

Submit

Reset

Radio

Password

Hidden

elements[]

Navigator

anchors[]

links[]

Location

History

frames[]

Document

forms[]

Window

� EMBED PBrush  ���

� Because of the nature of this paper, it is necessary to mention vendors and commercial products. The presence or absence of a particular trade name product does not imply criticism or endorsement by the National Institute of Standards and Technology, nor does it imply that the products identified are necessarily the best available.

� The descriptions of DDE-1 and DASE functionality in this paper are based on the DDE-1 and DASE specifications available at the time of publication. Some of these specifications may undergo revision subsequent to this paper’s publication. Moreover, the descriptions of DDE-1 and DASE functionality in this paper are summaries. For details, see the specifications.

� In this paper, features described as “specified” within DDE-1 or DASE means that behavior semantics for these features are specified within the DDE-1 or DASE standards. If features are identified as “not specified,” content developers should be aware that such features might not be supported in a particular implementation of a standard.

� DASE Security is very much a work in progress and is not described in this paper. DDE-1 does not specify security features.

� In addition to the DASE content types listed in this table, the DASE Security specification under development defines the additional content types: application/dase-manifest, application/dase-permission, application/dase-signature

� DASE Common Facilities consist of the content types: application/dase-trigger, image/jpg, image/png, video/mng, audio/basic, video/mpeg, video/mpv, audio/ac3, application/font-tdpfr, application/jar.

� DDE-1 informatively defines  “backchannel” as “a connection from a receiver to the Internet or back to some server.” 

� Backchannel functionality may be included in the next version of DASE, commonly referred to as “DASE-2.”

� Note that, depending on the implementation, a trigger for a new enhancement that arrives before the termination of the current enhancement may also terminate an application.

�PAGE \# "'Page: '#'�'"  �� Major differences: 

DDE-1: backchannel; frames needed to modify page; no high performance procedural environment.

DASE: no backchannel; mutate almost all HTML tagged content with DOM2 (includes <DIV> visibility property; high performace procedural environment.

PAGE  

1

# _1029326759