IEC PAS 62292:2001

IEC/PAS 62292
Edition 1.0
2001-12
Draft SMPTE Engineering Guideline
SMPTE XXX –
Declarative Data Essence
PUBLICLY AVAILABLE SPECIFICATION
INTERNATIONAL Reference number
ELECTROTECHNICAL
IEC/PAS 62292
COMMISSION
IEC/PAS 62292
Edition 1.0
2001-12
Draft SMPTE Engineering Guideline
SMPTE XXX –
Declarative Data Essence
PUBLICLY AVAILABLE SPECIFICATION
INTERNATIONAL Reference number
ELECTROTECHNICAL
IEC/PAS 62292
COMMISSION
INTERNATIONAL ELECTROTECHNICAL COMMISSION

____________
DRAFT SMPTE ENGINEERING GUIDELINE SMPTE XXXX –

DECLARATIVE DATA ESSENCE
FOREWORD
A PAS is a technical specification not fulfilling the requirements for a standard, but made available to the

public and established in an organization operating under given procedures.
IEC-PAS 62292 was submitted by the SMPTE (Society of Motion Picture and Television Engineers) and
has been processed by IEC technical committee 100: Audio, video and multimedia systems and
equipment.
The text of this PAS is based on the This PAS was approved for
following document: publication by the P-members of the
committee concerned as indicated in
the following document:
Draft PAS Report on voting
100/398/PAS 100/426/RVD
Following publication of this PAS, the technical committee concerned will investigate the
possibility of transforming the PAS into an International Standard.
1) The IEC (International Electrotechnical Commission) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of the IEC is to promote
international co-operation on all questions concerning standardization in the electrical and electronic fields. To
this end and in addition to other activities, the IEC publishes International Standards. Their preparation is
entrusted to technical committees; any IEC National Committee interested in the subject dealt with may
participate in this preparatory work. International, governmental and non-governmental organizations liaising with
the IEC also participate in this preparation. The IEC collaborates closely with the International Organization for
Standardization (ISO) in accordance with conditions determined by agreement between the two organizations.
2) The formal decisions or agreements of the IEC on technical matters express, as nearly as possible, an
international consensus of opinion on the relevant subjects since each technical committee has representation
from all interested National Committees.
3) The documents produced have the form of recommendations for international use and are published in the form
of standards, technical specifications, technical reports or guides and they are accepted by the National
Committees in that sense.
4) In order to promote international unification, IEC National Committees undertake to apply IEC International
Standards transparently to the maximum extent possible in their national and regional standards. Any divergence
between the IEC Standard and the corresponding national or regional standard shall be clearly indicated in the
latter.
5) The IEC provides no marking procedure to indicate its approval and cannot be rendered responsible for any
equipment declared to be in conformity with one of its standards.
6) Attention is drawn to the possibility that some of the elements of this PAS may be the subject of patent rights.
The IEC shall not be held responsible for identifying any or all such patent rights.
Page i
Draft SMPTE Engineering Guideline D27.111-2425B

17-October- 2001
Declarative Data Essence
1 Scope
This document provides an overview of the Declarative Data Essence Standards, describes how

the various documents and technical components are related, and provides informative material

useful to the users of these standards.
2 Organization
2.1 Table of contents
1SCOPE.1
2 ORGANIZATION .1
2.1 TABLE OF CONTENTS .1
3 INTRODUCTION .2
4 AUTHORING GUIDELINES .4
4.1 HTML4.4
4.2 STYLE SHEETS AND FONTS.4
4.3 ECMASCRIPT .5
4.4 DOM-0 .5
4.5 URI SCHEMES .5
4.6 UUID .5
5 RECEIVER BEHAVIOR .6
5.1 RECEIVER MODEL .6
5.2 ENHANCEMENT CHARACTERIZATION .6
5.3 STATE MODEL.7

5.3.1 New Enhancement Triggers.8
5.3.2 Triggers for the Current Enhancement.8
5.4 CACHE MANAGEMENT .9
5.4.1 Size.9
5.4.2 Behavior.10
5.5 COOKIES.10
5.6 CSS-1 AND FONTS.11
6 DISTRIBUTION ISSUES .11
7 AD INSERTION SCENARIO DETAILS.11
8 EXAMPLES.13
Declarative Data Essence – Engineering Guideline Page 1 of 20

!"#$%&'()*+*,--./*012345*,--./*64!

EQFNBK+>AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4M
YA4 H
YA7 FNBK+>+9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4I
YAM >OH0D+*!EGRK+H9*FNBK+>+9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4V

? 9-96-$*)+%4@''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''!?

E* 6:)%">=@)&":
9:"*(-('(%$*/&51<*56*,'%-2%&2,*="&"*2")"$5<"2*(-*>K39+*@%,"2*5-*':"*B2)%-#"2*9"$")(,(5-
+-:%-#";"-'* F5&1;* ZB9T+F[* ,<"#(6(#%'(5-* \B9T+F]A* * 9:","* %&"* #5$$"#'()"$^* _-5=-* %,
!"#$%&%'()"* !%'%* +,,"-#"* Z!!+[* 2"&()"2* 6&5;* ':"* '"&;(-5$5/^* 2")"$5<"2* (-* ':"* `5(-'
>K39+a+CR*=5&_*651-2*(-*\>K39+Q+CR]A**9:(,*=%,*61&':"&*$%@"$"2*%,*#5-'"-'*$")"$*4*%6'"&
':"*B9T+F*,<"#(6(#%'(5-*65&*b4A8c?*%-2*(-*%-'(#(<%'(5-*56*@5':*$5="&*%-2*:(/:"&*#5-'"-'*$")"$,A
J"-#"?*':"*,:5&':%-2?*b!!+Q4cA
9:"*B9T+F*,<"#(6(#%'(5-*=%,*@&5_"-*(-'5*S*,"<%&%'"*>K39+*25#1;"-',*':%'*#5)"&*':"*5&(/(-%$
B9T+F*,<"#(6(#%'(5-A**9:","*,<"#(6(#%'(5-,*%&"d
!1 \!!+Q4]* >K39+* 3&5<5,"2* >'%-2%&2* MSMK?* b!"#$%&%'()"* !%'%* +,,"-#"?* G5-'"-'
D")"$*4cA
!1 \!EKQ8]*>K39+*3&5<5,"2*>'%-2%&2*MSSK?*b!5#1;"-'*E@`"#'*K52"$*D")"$*8*Z!EKQ8[
%-2*N"$%'"2*E@`"#'*+-)(&5-;"-'cA
!1 \DO!]*>K39+*3&5<5,"2*>'%-2%&2*MIMK?*b9:"*D5#%$*O2"-'(6("&*Z$(2d[*RNO*>#:";"cA
!1 \O3K]* >K39+* 3&5<5,"2* >'%-2%&2* MPVK?* b!"#$%&%'()"* !%'%* +,,"-#"?* O3* K1$'(#%,'
+-#%<,1$%'(5-cA
!1 \RJ993]*>K39+*>'%-2%&2*MSIK?*b!"#$%&%'()"*!%'%*+,,"-#"*Q*R-(2(&"#'(5-%$*J^<"&'"e'
9&%-,<5&'*3&5'5#5$cA
!1 \H9>G]*>K39+*3&5<5,"2*>'%-2%&2*MS4K?*bH9>G*O3*%-2*9&(//"&*C(-2(-/*'5*TCOcA
O-*%22('(5-?*':"&"*(,*%*-"=*3BDa>+GBK*@(-2(-/d

!1 \3BD]*>K39+*!&%6'*>'%-2%&2*eeee?*b3BDa>+GBK*O3*%-2*9&(//"&*C(-2(-/*'5*TCO
ZS7P*D(-"*9"$")(,(5-*>^,'";,[cA
9:"*&"$%'(5-,:(<*56*%$$*V*56*':","*25#1;"-',*#%-*@"*651-2*(-*F(/1&"*MQ4*@"$5=A
!"#$%&%'()"*!%'%*+,,"-#"*.*+-/(-""&(-/*01(2"$(-" 3%/"*7*56*78

And, finally it is worth noting that there is ongoing work (not covered in this document) on

wrappers for this content for carriage in SMPTE KLV. And, there is very early work on a

content level 2.
DDE-1
lid: DOM-0
Wrappers & KLV
UHTTP
Encapsulation*
IPM
SMPTE KLV on MPEG
PAL
MPEG
NTSC Bindings MPEG Bindings
SECAM
Figure 3-1. Relationship of the DDE-1 Standards.
The collection of DDE-1 documents is fully ATVEF compliant, and is collectively known as
“Content Level 1”, or DDE-1. No extensions were designed, and no new functionality was
added. However, a considerable amount of new material was added to more fully specify the
work for the purpose of providing interoperability. Specifically, there was significant additional
work put into the following technology:
• DOM-0
• Triggers (defined in [DDE-1])

• Lid:
The DDE-1 document set is an authoring content standard. As such, it avoided as much as
possible specific receiver behavior. However, expectations of receiver behavior are implied, and
often overtly stated. Some more information on the expected behavior is covered in this
document.
Declarative Data Essence – Engineering Guideline Page 3 of 20

4 Authoring Guidelines
4.1 HTML4
Some operations taken for granted in computer-based browsers that decode HTML

should often be avoided when using DDE-1. In general, anything that would require

extensive use of an input device, such as pull-downs and similar input objects. In addition,

the expectation of scrolling down or to the right to view a page may often result in parts of
the display being unviewable due to limited (or unwilling) user input. It is a good idea to
create pages that are a single screen, and avoid any assumption of input devices, certainly
anything more than can be done on a standard remote control.
Absolute positioning and sizes should be avoided to permit consistent rendering on
displays of varying resolutions. Using pixel coordinates will result in significant undesirable
variations.
DDE-1 does not provide good means to ensure accurate positioning of the HTML
elements with respect to the video. Since the video format can be altered during distribution
from its original format when the DDE-1 was created, this poses interesting registration
challenges at the decoder. For example, it can be as gross a change as a conversion from
16x9 to 4x3 letterbox. Authors are cautioned about making any assumptions about the
registration between the video and the DDE-1 content at the decoder when the distribution is
not well known. Authors should try to stay within the safe area and safe titling areas as
defined in SMPTE RP26.3 [SAFE].
Authors are referred to the general interoperability warnings found within the HTML
specification [HTML].
4.2 Style Sheets and Fonts
There is no default style sheet in DDE-1. And, there is no requirement that a receiver
choose any particular set of styles. Thus, without authoring and sending a style sheet along
with the HTML content, the variation in rendering across manufacturers will be significant
and perhaps undesirable. Authors are encouraged to make explicit use of CSS style sheets

in order to control the display of their content.
As in HTML for positioning, percent sizes should be used wherever possible to provide
display independence.
DDE-1 does not support downloadable fonts, however, there are two default fonts with
specific sizes required to be supported. Authors are encouraged to make use of these fonts
for better display control. The fonts sizes are specified in pixels, so there will be some
amount of display variation if specific sizes are chosen.
Declarative Data Essence – Engineering Guideline Page 4 of 20

4.3 ECMAScript
Authors should avoid using eval() that results in dynamically generated HTML.  Doing

this makes transcoding of the content computationally impossible, and thus may affect the

quality in future generation enhancement systems.

4.4 DOM-0
Authors should avoid using document.write() with arguments other than constants.
Doing this makes transcoding of the content computationally impossible, and thus may
affect the quality in future generation systems.
4.5 URI Schemes
DDE-1 supports the URI schemes, tv: [TV] and lid: [LID]. And, in the case of transport A,
the use of http: [HTTP]. It is important to note that other schemes are specifically not
supported and their use would result in non-interoperable behavior. Authors are
specifically cautioned against using the common schemes, ftp:, https:, and shttp:.
4.6 UUID
UUID’s would normally be generated automatically by the authoring tool through a call to
the operating system to obtain one. UUID’s are often also called guid’s, and are available in
some form on all popular operating systems.
UUID’s are constructed in part from the MAC address of the network adapter being used in
the computer doing the authoring. In the rare occurrence that a UUID needs to be generated
from a device without a network interface, then care must be taken to use an unused MAC
address. This can be done by setting the most significant bit of the MAC address field
(MAC address assignments use this to signal multicast destinations and would never be used
for a real address). Alternatively, a statistically unique value can be generated through the

hash of the field(s) as described further in RFC 2518, Section 6.4.1 [WEBDAV].
Declarative Data Essence – Engineering Guideline Page 5 of 20

5 Receiver Behavior
This section provides information which should be considered when implementing a decoder that

decodes the DDE-1 content. Since DDE-1 content is an authoring standard and not a decoder

standard, this may be helpful to manufacturers of any decoding equipment, including consumer

electronics receivers. The term, “receiver”, here is generally meant to refer to any type of

decoder.
5.1 Receiver Model
Video
Video
Decoder
ECMAScript
Interpretor w
DOM-0
HTML4
Display
& ASCII
HTML4
Renderer
Decoder
OSD
CSS-1
Trigger
Image
Decoder
Processor
Triggers
Renderers
Image
Decoders
HTTP
Data Cache
Get
Internet Data
PCM Audio
Decoder
Transport B Data
Audio Decoder Audio Mixer Audio
Audio
Figure 5-1. Receiver Block Diagram

5.2 Enhancement Characterization
An enhancement is defined as “content added to a video/audio service.” An enhancement can further be described
by its behavioral characteristics as specified in [DDE-1]. From this point of view, an enhancement is a sequence of
topmost HTML documents whose content is specified in [HTML]. The first HTML document of an enhancement,
the initial topmost document, is always instantiated by means of a trigger. Subsequent topmost documents within an
enhancement are instantiated as a result of a navigation from the current document initiated either by a trigger or a
viewer selection (see Figure 5-2).
Declarative Data Essence – Engineering Guideline Page 6 of 20

viewer/trigger
navigation
trigger
Doc 1            Doc 2           …           Doc n-1            Doc n

(Initial)
Figure 5-2. DDE-1
Enhancement
5.3 State Model
new
enhancement
trigger
new
enhancement
trigger
no
enhancement
enhancement
active
active
viewer/trigger
viewer/trigger
navigation to
enhancement’s
navigation
next document
Figure 5-3. Diagram for enhancement behavior.

Figure 5-3 shows the state diagram for enhancement behavior. Table 5-1 describes the basic types of triggers. The
enhancement state model is described from the point of view of the state transition arcs in figure 5-3. Each state
transition can result from either a “new enhancement trigger” or a “trigger for the current enhancement.”
Enhancement
Trigger Type active? Trigger Description

When determining whether two URLs are DIFFERENT or EQUAL, characters in the URLs including and
following the first “?” or “#” are ignored in the comparison.
Declarative Data Essence – Engineering Guideline Page 7 of 20

trigger with “name” attribute, and

URL DIFFERENT from the last
NO topmost document of
immediately preceding
enhancement
New
Enhancement
Trigger
trigger with “name” attribute, and

URL DIFFERENT from current
enhancement’s current topmost
YES
document
Trigger for trigger with URL EQUAL the
Current YES URL of the current
Enhancement enhancement’s current topmost
document
Table 5-1. Basic Trigger Types
5.3.1 New Enhancement Triggers
As shown in table 5-1, a “new enhancement trigger” is a trigger with a “name” attribute, and with either:
• a URL different from the last topmost document of the immediately preceding enhancement if no
enhancement is active; or,
• a URL different from the current enhancement’s current topmost document if an enhancement is active.
New enhancement triggers are used to initiate a new enhancement.
From the “no enhancement active” state, an enhancement is initiated by a new enhancement trigger. An
enhancement can only be initiated by a new enhancement trigger.
From the “enhancement active” state, a new enhancement trigger may replace the current enhancement with a new
enhancement in an implementation specific manner. In order to ensure interoperable behavior, a content developer
should terminate an enhancement by means of a navigation to “tv:” (either by the viewer or by a trigger for the
current enhancement) before sending a new enhancement trigger.

5.3.2 Triggers for the Current Enhancement
As shown in table 5-1, a “trigger for the current enhancement” is a trigger with a URL equal to the URL of the
current enhancement’s current topmost document. Triggers for the current enhancement are used to:
• navigate to an enhancement’s next topmost document,
• terminate an enhancement,
• change the display and/or state of an enhancement.

May result in implementation specific behavior.
Declarative Data Essence – Engineering Guideline Page 8 of 20

In an “enhancement active” state, a “viewer/trigger navigation to enhancement’s next document” replaces the

current topmost document of the enhancement with the contents of the enhancement’s next document. With viewer

initiated navigation, the current topmost document is replaced as the result of a viewer navigation (e.g., by means of

a link) to another HTML document. With trigger initiated navigation, the current topmost document of the

enhancement is replaced as the result of a trigger script (such as: “window.top.location.href=’
enhancement’s next document>’;”) being executed. Such a trigger script is executed upon receipt of a trigger for the
current enhancement. In order for the enhancement to receiver the trigger, the enhancement’s current topmost
document must contain a trigger receiver object.

Even though a new topmost document is being displayed, that document is still part of the current enhancement.

However, note that triggers for the current enhancement delivered subsequent to the activation of the new document

must have a URL equal to the URL of the new document. If this is not the case, then either the trigger is ignored (if
it does not have a “name” attribute), or may initiate a new enhancement in an implementation specific manner (if the
trigger does have a “name” attribute). In order to ensure interoperable behavior, a content developer should
terminate an enhancement by means of a navigation to “tv:” (either by the viewer or by a trigger for the current
enhancement) before sending a new enhancement trigger.
Note that triggers for the current enhancement may have a “name” attribute. A “name” attribute in a trigger for the
current enhancement does not initiate a new enhancement. Including a “name” attribute in a trigger can be used to
achieve the following effect. If a viewer tunes to a program after the initial trigger for the program’s enhancement
was sent, then, by including a “name” attribute in subsequent triggers for that enhancement, the enhancement is
initiated as a result of the receipt of a subsequent trigger.
In the “enhancement active” state, an enhancement can be terminated by “viewer/trigger navigation to “tv:”.” More
specifically, the navigation must replace the current topmost document with “tv:”. With viewer initiated navigation
to “tv:”, the current topmost document is replaced with “tv:” as the result of a viewer navigation (e.g., by means of a
link) to the URL “tv:”. With trigger initiated navigation, the current topmost document of the enhancement is
replaced with “tv:” as the result of a trigger script (such as: “window.top.location.href=’tv:’;”) being executed. Such
a trigger script is executed upon receipt of a trigger for the current enhancement. In order for the enhancement to
receiver the trigger, the enhancement’s current topmost document must contain a trigger receiver object.
An active enhancement may also terminate as a result of the receipt of a trigger to initiate a new enhancement.
Please note that it is implementation specific whether, and in what manner, an enhancement terminates upon the
arrival of a trigger for a new enhancement. In order to ensure interoperable behavior, a content developer should
terminate an enhancement by means of a navigation to “tv:” (either by the viewer or by a trigger for the current
enhancement) before sending a new enhancement trigger.
The display and/or state of an active enhancement can be changed as a result of the receipt of a trigger for the
current enhancement. The enhancement’s display and/or state is changed as a result of the execution of the trigger’s
script.
5.4 Cache Management
5.4.1 Size
Receivers are expected to provide buffering for one megabyte (1 MB) of cached
simultaneous content. Content creators who want to reach the maximum number of receivers
should manage their content such that the instantaneous high-water mark of simultaneous
cached content is no more than 1 MB.

DDE-1 only requires the capability for running one enhancement at a time.
Declarative Data Essence – Engineering Guideline Page 9 of 20

All cache size values are the uncompressed sizes of the content stripped of all transport

headers. Receivers may of course choose to store content compressed to reduce local

memory utilization.
When carried in IP Multicast and announced with SDP, the specific cache size required for

each enhancement is required be specified in the announcement. The value of the SDP

announcement extension, tve-size, represents the maximum size cache needed to hold

content for the current page at any time during the program including all pages reachable by

local links. It is the high water mark during the program, not the total content delivered

during the program.
5.4.2 Behavior
The cache is generally be expected to operate according to RFC 2616 [HTTP], Sections 13
and 14. This provides the semantics for handling the required, as well as optional, HTTP
header fields defined in UHTTP that can affect the cache behavior, such as Expires.
Expired content is not used or displayed, even if it is present in the cache when it was
needed.
The cache is flushed on receiver startup, but not on other conditions, including channel
change, or even receipt of a “new enhancement”.
Content that is delivered as a single entity is not entered into the cache until all sub-
components are received. That is, when using IP Multicast and UHTTP for delivery, and a
multipart entity is received, the individual content items would only be made available to the
executing application if the entire multipart is successfully received and decoded. Partial
cache updates may result in undesired composite page displays (i.e. today’s news headlines
with yesterday’s photos).
5.5 Cookies
The general syntax for cookies is described in RFC 2965 [HTTP-STATE], Section 4.2.2,
which consist of name/value pairs. The names supported in DDE-1 are “name” and

“expires”, with the latter being a date syntax defined as Wdy, DD-Mmm-YY HH:MM:SS
GMT.
On powerup a receiver should set the string to null. And, a new enhancement should reset
the string to null.
The receiver buffer for cookies is 1024 bytes for session cookies.
The cookie string supported by DOM-0 Document object concatenates the two name/value
pairs of multiple cookies into a single string.
Declarative Data Essence – Engineering Guideline Page 10 of 20

!"#$%&'()*+*,--./*012345*,--./*64!

E-*&"#"(<'*56*%*RJ993*#5-'%(-(-/*J993*#55_("*6("$2,?*':"*-%;"*%-2*"e<(&",*-%;"a)%$1",

%&"*%<<"-2"2*'5*':"*"e(,'(-/*)%$1"*56*':"*#55_("*,'&(-/A

f:"-*':"*25#1;"-'A#55_("*<&5<"&'^*(,*&"%2*':&51/:*!EKQ8?*('*&"'1&-,*':"*"-'(&"*,'&(-/A

f:"-*':"*25#1;"-'A#55_("*<&5<"&'^*(,*=&(''"-*'5?*(',*<&")(51,*)%$1"*(,*&"<$%#"2*Z(A"A*('*(,*-5'

%<<"-2"2[A* * 9:"* -"=* ,'&(-/* -""2,* '5* #5-65&;* '5* ':"* #5-,'&%(-',* %@5)"* .* 5-$^* ':"

7*-%;"a)%$1"*<%(&,A
D"I$ ;44B#$&-7$8*-./
B*&"#"()"&*(,*"66"#'()"$^*&"i1(&"2*'5*,1<<5&'*':"*65-',*%-2*,(j",*%,*2"6(-"2*(-*!!+Q4A**H5'"
':%'*':"*;%<<(-/*56*':"*-%;"2*,(j"*)%$1",*Z(A"A*eeQ,;%$$?*"'#A[*,:51$2*@"*25-"*,1#:*':%'*':"
,(j"*#5-,'&%(-',*%&"*)%$(2*5-*':"*/()"-*2(,<$%^*&",5$1'(5-*56*':"*,<"#(6(#*&"#"()"&A
K* 7&B)%&L=)&":*6BB=;B
9:"&"*%&"*)%&(51,*#5-,(2"&%'(5-,*=:"-*"-#52(-/*!!+Q4*#5-'"-'*(-'5*':"*2(,'&(@1'(5-A**f:"-
1,(-/*%*,<"#(6(#*"-#%<,1$%'(5-?*,1#:*%,*O3*K1$'(#%,'?*':"&"*%&"*<&5,*%-2*#5-,*'5*"-#52(-/*('
"%&$^*(-*':"*2(,'&(@1'(5-A**9:"*<&5,*%&"*':%'*21&(-/*':"*<"&(52*=:"&"*':"*(-6&%,'&1#'1&"*(,*-5'
",'%@$(,:"2*'5*#%&&^*2%'%*%,*%*<""&?*1,(-/*O3*K1$'(#%,'*<"&;(',*51'*56*@%-2*2"$()"&^*56*':"
2%'%*,'&"%;*'5*':"*6(-%$*";(,,(5-*6%#($('^A**J5=")"&?*':(,*%$,5*;"%-,*':%'*2"#(,(5-,*%@51'
@%-2=(2':*1'($(j%'(5-?*&"<"'('(5-*&%'"*56*#5-'"-'*('";,?*%-2*5':"&*,1#:*2"#(,(5-,*:%)"*'5*@"
;%2"* 1<,'&"%;* 56* ':"* ";(,,(5-?* %-2* ':1,* <"&:%<,* =(':51'* _-5=$"2/"* 56* @%-2=(2':
#5-,(2"&%'(5-,A
9:"&"*(,*=5&_*(-*<&5#",,*'5*2"6(-"*%*,'%-2%&2*65&*':"*#%&&(%/"*56*2%'%*#5-'"-'?*(-#$12(-/
"-51/:*;"'%2%'%*'5*<&5<"&$^*"-#52"*('A**N"%2"&,*%&"*"-#51&%/"2*'5*_""<*(-*'51#:*=(':*':(,
%#'()('^A
f:($"*#:%$$"-/(-/*%'*':(,*=&('(-/?*%1':5&,*%&"*"-#51&%/"2*'5*2"6"&*"-#52(-/*56*':"*#5-'"-'*'5

%,*#$5,"*%,*<5,,(@$"*'5*6(-%$*";(,,(5-A
M* G>*6:B;%)&":*0@;:8%&"*7;)8&?B
9T*<&5/&%;,*#5-,(,'*56*"-'"&'%(-;"-'*<&5/&%;,*(-'"&,<"&,"2*=(':*#5;;"&#(%$,A*3&5/&%;*%-2*#5;;"&#(%$*,"/;"-',
%&"*1,1%$$^*<&521#"2*(-2"<"-2"-'$^A*9:"&"*(,*':"*5@)(51,*&"i1(&";"-'*':%'*O9T*#5-'"-'*65&*':"*2(66"&"-'*,"/;"-',
,:51$2*-5'*(-'"&6"&"*=(':*"%#:*5':"&A*9:"&"*%&"*'=5*%<<&5%#:",*'5*%##5;<$(,:(-/*':(,A
!"#$%&%'()"*!%'%*+,,"-#"*.*+-/(-""&(-/*01(2"$(-" 3%/"*44*56*78

As shown in figure 7-1, the first approach is to initiate an enhancement at the beginning of a segment, and then,

terminate that enhancement at the end of the segment. As described in the section on the enhancement behavior

state model, a new enhancement trigger initiates a new enhancement, and navigation from the current enhancement

to “tv:” by means of a viewer selection or a trigger, terminates an enhancement.

enhancement i
enhancement i-1             enhancement i+1

broadcast    )(                    )(   )(                    )(

program                 program
commercial
Figure 7-1: Sequential Enhancements
As shown in figure 7-2, the second approach is for several sequential segments to share a single enhancement which
serves as an “executive” for displays associated with each segment. For example, the executive could consist of a
single “main” frame and the displays associated with each segment are sub-frames. Frames for the segments are
displayed and removed by means of triggers at the beginning and end of each segment respectively. The initiation
and termination of the shared enhancement is accomplished in the same manner as the first approach.
Shared Executive Application
seg i display
seg i-1 display             seg i+1 display
broadcast    )(                    )(   )(                    )(
program                 program
commercial
Figure 7-2: Enhancement with Shared Executive
In both approaches, saving enhancement state between program segments may be an important design consideration.
A single TV program has several program segments. It may be necessary for interactive content for the entire
program to appear as a single, integrated, seamless, interactive experience. This means that “state” information for
the interactive experience must be maintained between program segments.
In the Shared Executive Approach, maintaining state information between program segments may be accomplished
by ECMAScript variables. In the Sequential Enhancement approach, there are basically three ways to maintain state:

• In triggers: A trigger’s “script” attribute and the anchor and search fields of a trigger’s URL can contain
state information. In this case, the state information is almost always known when the content is initially
produced. Putting state information in triggers is particularly useful for setting (or resetting) an
enhancement to a known state.
• In a cookie: The cookie property of the document object is commonly used in Web content to maintain
state between document instantiations. The technique is the same with enhancement documents.
• On a server: Maintaining state on a server is a Web technique which can apply to enhancement documents.
This approach requires a backchannel.
Declarative Data Essence – Engineering Guideline Page 12 of 20

These techniques for maintaining state can also be used in combination. One example is to maintain state on a

server, and return state values to the receiver in triggers. No state information need be kept on the receiver.

However, this approach requires a close real-time co-ordination between the servers and the broadcast equipment.

8 Examples
Three enhancement examples are presented. Each example implements the same application, namely, counting

arriving triggers. Each example displays a count of the triggers that are sent in the broadcast stream to the

enhancement. Such triggers take the form:

[v:1][n:count?][s:count_triggers()][checksum] for Transport A, or
[v:1][n:count?][s:count_triggers()] for Transport B.
Each example can run in a limited manner with a Web browser. Each has a link “click here to show trigger arrival
effect” enabling the viewer to see the same effect on the display as though a trigger had arrived. Each also has a link
“Exit Enhancement” to enable the viewer to terminate the enhancement. Selection of this link replaces the topmost
document of the enhancement with “tv:”.
In order to minimize the size of each example, the complexity of the display is kept to a minimum. The goal is to
illustrate the structure of each example to clarify the technique. For esthetic and performance reasons, TV
enhancements may differ from normal Web pages.
8.1 No-Frames
The No-Frames example illustrates an enhancement consisting of a sequence of topmost documents. The display
presented to the viewer changes as a result of reloading a single topmost document.
When the trigger count is incremented, the new value is added to the URL for the enhancement’s document as a
search string, and then, the topmost document is reloaded. The search string in the URL becomes the new trigger
count value displayed. This illustrates the use of a URL’s search string as means of maintaining state between the
sequential instantiations of an enhancement’s documents. Note that this example does not maintain the trigger count
value between instantiations of the No-Frames enhancement.
"http://www.w3.org/TR/REC-html40/transitional.dtd">

DDE-1 No-Frames Example

click here to show trigger arrival effect

Exit Enhancement

Full Screen ----------- Exit Enhancement