Many companies and content developers are interested in using HTML to develop applications for MHP. One of the reasons for this is that for some application types, HTML is a simpler choice than Java. In other cases, it’s because companies are more used to using HTML and want to stick with what they know.
Before we go any further in discussing the use of HTML in MHP, there’s a few things that have to be clarified. First of all, it’s not possible to have an MHP 1.0 implementation which supports DVB-HTML. The DVB consortium has specified that only MHP 1.1 implementations may support DVB-HTML, which means that all the mandatory features of MHP 1.1 must also be implemented.
While this may not sound like much, it means that any platform which claims to support DVB-HTML in an MHP 1.0 implementation is not actually MHP, with all the potential interoperability issues that this introduces. There are some products out there claiming this, including at least one which doesn’t even support DVB-HTML correctly. For the time being, beware of any implementation that claims to be DVB-HTML, especially if they don’t support DVB-J as well.
The other major issue is the size and complexity of DVB-HTML. Anyone reading this and thinking that DVB-HTML is a slimmed-down version of the language, designed to execute efficiently on a set-top box, obviously hasn’t been reading the appropriate parts of the spec. DVB-HTML is big. It’s also highly complex. Many of the elements of the standard haven’t been integrated into the main desktop browsers yet, let alone the embedded browsers that are used on set-top boxes.
Finally, there’s the issue of interoperability. Although the core standards are fixed, there is the problem that since no-one’s actually implemented all of them yet, there will be a stage where the ambiguities and bugs in the standards will come to light,and where there will be interoperability issues. DVB-J has already (mostly) worked through this phase through events such as the MHP interoperability workshops in Germany, but DVB-HTML still has a long way to go here.
The adoption of DVB-HTML by the industry for use in real projects still isn’t a certainty, and it’s going to be a case of watching over the next couple of years to see how well-received DVB-HTML actually is. For all people’s enthusiasm for HTML (and there are some application types such as basic information services where it undoubtedly makes life easier for application authors) , it may be that the cost of supporting DVB-HTML is just too high.
The core standards of DVB-HTML
DVB-HTML consists of a number of Internet standards. The most important one of these is XHTML, the XML version of the HTML language. What’s supported in MHP is a modularized version of this – some sets of functionality are supported, while others are not. This allows applications wishing to use XHTML to support a subset of the functionality while being clear about what this subset is, and restricting the available subsets. This has proven useful for DVB-HTML, because it allows a specific subset of the functionality to be defined very easily and quickly.
The following modules are included in the DVB-HTML specification:
| Module | Required |
|---|---|
| Structure | Yes |
| Text | Yes |
| Hypertext | Yes |
| List | Yes |
| Applet | No |
| Presentation | Yes |
| Edit | No |
| Bidirectional text | Yes |
| Basic forms | No |
| Forms | Yes |
| Basic Tables | No |
| Tables | Yes |
| Image | Yes |
| Client side image map | Yes |
| Server side image map | No |
| Object | Yes |
| Frames | Yes |
| Target | Yes |
| Iframe | Yes |
| Intrinsinc events | No |
| DVB intrinsic events | Yes |
| Meta-information | Yes |
| Scripting | Yes |
| Style sheet | Yes |
| Style attribute | Yes |
| Link | Yes |
| Base | Yes |
| Name identification | No |
| Legacy | No |
While it may seem that XHTML is a bad choice because it’s more complex than HTML 4.0 in some cases, there are some major advantages. The fact that it’s based around XML makes it less tolerant of bad practice, and this means that the parser can be simplified because a lot of the ugly shortcuts in HTML simply aren’t allowed any more. This improves reliability, and reduces the code size of the user agent.
The formal public identifier (FPI) for the DVB-HTML doctype is
-//DVB//DTD XHTML DVB-HTML x.y//EN
where x and y are the major and minor version numbers for the version of DVB-HTML. In the case of MHP 1.1, these are 1 and 0 respectively. Each DVB-HTML document must start with the following DOCTYPE declaration:
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//DVB//DTD XHTML DVB-HTML 1.0//EN"
"http://www.dvb.org/mhp/dtd/dvbhtml-1-0.dtd"
>
It’s general good practise to include a DOCTYPE declaration in any HTML document, but it’s more important that ever from the reliability point of view with respect to DVB-HTML. Docuements may include elements that aren’t indicated in the DOCTYPE definition, but these documents aren’t actually valid with respect to the doctype. In this case, the DVB-HTML engine will display the text content of the additional elements, but won’t do anyting else with them.
In addition to XHTML, there are a number of other Internet standards which are used by DVB-HTML. These are:
Cascading Style Sheets, version 2.0
CSS is the recomended way of controlling the formatting and layout of the XHTML pages. There are a few changes from the standard CSS definition, mainly to cope with the limitations of the broadcast medium and TV displays, and also to add a new media type to distinguish DTV set-top boxes where the focus is on the DTV aspect from those devices which are more similar to PCs, where the DTV aspect takes a less important role.
ECMAScript (first edition)
ECMAScript provides the means for enabling interactivity in XHTML documents. For those of you who aren’t familiar with it, ECMAScript is the standardized version of JavaScript. There are some differences from JavaScript, however, so application developers should take care. For instance, while JavaScript 1.3 does met the ECMAScript standard, it also adds some extra features that aren’t found in standard ECMAScript, so developers need to make sure they don’t use proprietary features of the scripting language.
Document Object Model, version 2.0
DOM provides an abstraction that allows ECMAScript code to manipulate the structure and contents of an XHTML document.
The table below lists which DOM modules must be supported by a DVB-HTML user agent:
| DOM module | Required | |
|---|---|---|
| Package | Feature string | |
| Level 2 core | Core | Yes |
| XML | No | |
| Level 2 views | Views | Yes |
| Level 2 stylesheets | StyleSheets | No |
| Level 2 CSS stylesheets | CSS | No |
| CSS2 | Yes | |
| Level 2 events | Events | Yes |
| UIEvents | Yes | |
| MutationEvents | Yes | |
| DVB-HTML | DVBHTML | Yes |
| DVB events | DVBEvents | Yes |
| DVB key events | DVBKeyEvents | Yes |
| DVB CSS | DVBCSS | Yes |
| DVB environment | DVBEnvironment | Yes |
Developing applications in DVB-HTML
DVB-HTML applications are a set of linked XHTML pages, just like a normal web site. The main difference is that there are no links outside those pages – they are completely self-contained.
One of the most important things to remember for developers is that in this case, your pages have to validate. It’s absolutely crucial for the sake of interoperability that they comply exactly with the standard. It’s a lot easier to check this for DVB-HTML applications, since only static checking us needed in a lot of cases, and the technology already exists to do this.
I’m a firm believer in validating your HTML, and this is even more critically important in a consumer environment, where the whole success of DVB-HTML rests on making sure that applications are reliable and behave the same across platforms. Given the unimpressive record of both content developers and user agents in following standards, people had better get used to this. There’s a lot more that could be said on this subject, and since it’s more of a rant than anything specifically related to MHP, I’ve put it here to avoid interrupting the flow of this tutorial too badly.
A DVB-HTML application consists of a set of XHTML pages and ‘triggers’ that allow navigation between them. These triggers may be someone clicking on a link within the page, or they may be built in to an application, or they may be DSM-CC stream events.
In each case, these triggers typically cause the application to move to another page. Usually, the new page will replace the previous one, just like in a standard web browser, but both pages may also be visible at the same time, like opening the page in a separate window.
DVB-HTML pages on their own aren’t necessarily very interesting without some method of adding interactivity. This is why ECMAScript has been added to the specification. Just like JavaScript on web pages, ECMAScript allows some simple interactivity on DVB-HTML pages. More complex interactivity isn’t supported very well in DVB-HTML, because that’s what DVB-J is for. As you have probably worked out by now, DVB-HTML applications are mainly declarative, rather than being procedural like DVB-J applications.
This isn’t a major limitation, despite what some people may tell you – DVB-HTML and DVB-J are complementary, not competing, and if they’re used sensibly then there won’t be any problems with using them. It’s only when the strengths and weaknesses of each are ignored that the problems start. For instance, a highly interactive application such as a game probably isn’t a good candidate for implementing with DVB-HTML. At the same time, an information service where the interactivity is limited and the information is mainly static is a good candidate for DVB-HTML.
Triggers
As we’ve already seen, a DVB-HTML application is driven by a series of events, which may either be caused by the user clicking on links within a DVB-HTML document, by events generated within the application (e.g. a script causing DOM events to be generated) or by external events.
These external events are DSM-CC stream events. To map a stream event on to a specific DOM event, the DVB-HTML engine uses an XML file called an event factory file. An example of the event factory file is shown below:
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC
"-//DVB//DTD DVB HTML Event Factory 1.0//EN"
"http://www.dvb.org/mhp/dtd/htmleventfactoryfile-1-0.dtd">
<trigger-event
stream="dvb://105.40.a9/stockPrice"
event="priceChange"
type="priceChange"
cancelable="false">
<event-attribute
attribute-name="changedSymbol"
attribute-data="/([A-Z]){4}:(\d+)/$1:$2" />
</trigger-event>
The information in the file is used by the DVB-HTML engine to identify a DSM-CC stream event a a trigger and to define which properties and their values shall be set for the corresponding DOM event. Some of the values may be defined by the payload of the stream event (in the above example, the “changedSymbol” attribute is set in this way.
One or more event factory files can be associated with a DVB-HTML document by an event linkage file. This is an XML file that is contained in the same directory as the document in question. The file has the same name as the document, but uses the file extension .lnk to identify it.
An event linkage file looks like this:
<?xml version="1.0"?> <!DOCTYPE linkage "-//DVB//DTD DVB HTML Event Linkage 1.0//EN" "http://www.dvb.org/mhp/dtd/htmleventlinkagefile-1-0.dtd"> <linkage boundary ="*"> <location URI="./events.evt" /> </linkage> <linkage boundary ="news.html"> <location URI="/newsTicker/events.evt" /> </linkage> <linkage boundary ="finance.html"> <location URI="/stockQuotes/events.evt" /> <location URI="/newsTicker/events.evt" /> </linkage> <linkage boundary ="sports.html"> <location URI="/sports/quiz/events.evt" /> <location URI="/sports/scores/events.evt" /> <location URI="/sports/news/events.evt" /> </linkage>
While this may seem unnecessarily complex (and it can be quite complex), it does allow a mapping for an event to be specified once and used in multiple documents. This makes things a little simpler for application developers, since it’s slightly easier to maintain consistent event mappings.
When a document doesn’t have an event linkage file associated with it, events are still be generated for DSM-CC stream events. In this case, the event is generated with its type attribute set to the name of the stream event.
Application boundaries
A DVB-HTML application has a well-defined application boundary. This describes what pages are a part of the application, and which pages are not, and it takes the form of a regular expression similar to that which is used in Unix. This regular expression identifies the set of files that make up the application.
Applications can refer to pages outside their application boundary, but these are treated as separate applications and referencing them may have an effect on the lifecycle of the current application. Like service selection in DVB-J, this is something that should be used with great care unless you want your application to die. The new application and the new one won’t necessarily be active at the same time.
DVB-HTML pages are transmitted as files in a DSM-CC object carousel, just like files for a DVB-J application. The signalling for these applications is a little different, but the method of getting at the application data is exactly the same.
DVB-HTML application signalling
Just like any other application, DVB-HTML applications are signalled in the AIT. As you’d expect, there are a few changes in how this is done. The descriptors for a DVB-HTML application include some extra information that is not needed for a DVB-J application. The DVB-HTML application location descriptor is similar to the applcation location descriptor for a DVB-J application – the biggest difference is that the descriptor refes to the initial HTML file of the application.
The main difference is the addition of the DVB-HTML appliation boundary descriptor. This is not needed for a Java application, since the boundaries of an application are well-defined by the classes it uses. Since a DVB-HTML application can refer to any web page, it uses the mechanism we’ve already discussed for doing this. The DVB-HTML appliation boundary descriptor simply encapsulates the regular expression describing the application boundary.
DVB-HTML and DVB-J applications can coexist, and both types of application can run at the same time (resources permitting). The application listing and launching API handles DVB-HTML applications as well as DVB-J applications, and although there’s no way for a DVB-HTML application to control a DVB-J application, it can select new services.
Inner Applications
It’s even possible to include a DVB-J application within a DVB-HTML application (and vice versa, but we won’t cover that here). These are known as ‘inner applications’ and allows an Xlet to act just like an applet that is embedded in a normal web page, or allows an Xlet to include an HTML component.
The following HTML shows how you can include an Xlet in your DVB-HTML application:
<object
type = "application/dvbj"
id = "myApplication"
codetype = "application/javatv-xlet"
classid = "MyApplication.class"
codebase = "myApplication/"
height = "200"
width = "150">
<param name = "arg_0" value = "param1"/>
<param name = "arg_1" value = "param2"/>
<embed height="200"
width="150"
arg_0="param1"
arg_1="param2"
src="param1">
</embed>
</object>
Some more information about inner applications is given in the MHP 1.1. tutorial, and our book contains even more information about how to develop and use inner applications well.
As we’ve already seen, these application types are complementary, and there are cases where it’s a lot easier to use HTML than Java. As set-top boxes become more powerful, and as more manufacturers start to support DVB-HTML, appication writers will have a choice of ways for developing MHP applications.
The future of DVB-HTML
Although DVB-HTML has been around for a while now, it’s not widely used or deployed. Many people are using HTML to build applications, but DVB-HTML is not in use anywhere.
There are several reasons for this. First, there is the problem that DVB-HTML requires a full MHP 1.1 implementation, and no-one is deploying MHP 1.1 yet. While HTML support is nice, it’s not a big enough reason to move to MHP 1.1. THis brings us on to to the second reason why DVB-HTML is not widely used. Like so many parts of MHP 1.1, DVB-HTML has not been widely tested or debugged, and there is currently no official test suite for either MHP 1.1 or DVB-HTML. Without these, interoperability problems become much more likely and much harder to resolve because you have no official arbiter of what is correct behaviour.
The final reason for not deploying DVB-HTML is very simple: no-one knows how long it will exist in its current form. The ATSC ACAP specification features its own definition of HTML applications for a GEM-based system, and the authors of the ACAP specification care far more about getting HTML support right. Once the final version of the ACAP specification is published, it’s likely that the HTML parts of that specification will be adopted in MHP as a replacement for DVB-HTML.
Most people who are using HTML at the moment are doing so using an HTML user agent that is packaged as a Java Xlet. This approach is used to provide teletext services in a number of countries, and in general it seems to work fairly successfully. The need to download an HTML browser may be outweighted by the fact that every receiver on the network will use the same browser, which makes it much easier to guarantee a consistent experience without the need for a lot of interoperability testing. Many HTML applications do not need fancy dynamic effects, and so a simple browser with a small footprint is often enough for these tasks. This is one area where the complexity of DVB-HTML works against it: it offers a lot of nice features, but many of those are unnecessary for most applications. Taking a simple, reliable solution over a more complex approach is always prefereable in a DTV network, and this is where a downloaded browser wins over DVB-HTML.