Flylib.com

Books Software

 
 
 

4.7 Conclusion


4.7 Conclusion

With the introduction of software execution capabilities, the complexity of receivers grows. There are countless issues that need to be addressed when designing receivers. Some could be classified as transport issues, application issues, and execution environment issues. Others could be classified as related to a group of (or individual) receiver modules and the relationship between them. It is important to note that regardless of the classification or point of view, these issues must be addressed somehow (e.g., by a business model or by the design). Addressing these issues should not be done in a vacuum , but rather, with the coordination of other participants in the iTV food chain.


4.8 References

[ATSC] Advanced Television Systems Committee (ATSC) www.atsc.org

[DASE] ATSC DTV Application Software Environment Level 1 (DASE-1) www.atsc.org/standards.html

[ETSI] European Telecommunications Standards Institute www.etsi.org

[FTP] File Transfer Protocol, RFC959, 10.1985, IETF ftp://ftp.rfc-editor.org/in-notes/rfc959.txt

[HTTP1.0] Hypertext Transfer Protocol, HTTP/1.0, RFC1945, 05.1996, IETF ftp://ftp.rfc-editor.org/in-notes/rfc1945.txt

[HTTP1.1] Hypertext Transfer Protocol, HTTP/1.1, RFC2616, 06.1999, IETF ftp://ftp.rfc-editor.org/in-notes/rfc2616.txt

[JavaTV] JavaTV API Technical Overview, Version 1.0 java.sun.com.

[JVM] Java Virtual Machine (JVM) java.sun.com

[MHP] Digital Video Broadcast (DVB) Multimedia Home Platform (MHP) www.mhp.org

[MPEG] Moving Picture Expert Group (MPEG) www.mpeg.org

[MPEG2] MPEG-2, ISO/IEC 13818 Parts 1-6 www.mpeg.org

[MPEG4] MPEG-4, ISO/IEC 14496 Parts 1-6 www.mpeg.org

[OCAP] CableLabs, Open Cable Architecture Platform (OCAP) www.cablelabs.com

[OCAP1.0] OCAP 1.0 Profile, OC-OCAP-DS-010430 www.scte.org

[OSGI] Open Services Gateway Initiative (OSGI) www.osgi.org.

[SCTE] Society of Cable Telecommunications Engineers (SCTE) www.scte.org

[SMPTE] Society of Motion Picture and Television Engineers (SMPTE) www.smpte.org

[TLS] The Transport Layer Security (TLS) Protocol version 1.0, RFC 2246, 1999, IETF . ftp://ftp.rfc-editor.org/in-notes/rfc2246.txt

[URI] Uniform Resource Identifiers (URI), RFC 2396, 8.1998, IETF ftp://ftp.rfc-editor.org/in-notes/rfc2396.txt

[UUID] SMPTE 298M, 1997: Universal Labels for Unique Identification of Digital Data www.smpte.org


Chapter 5. Declarative Content

Chapter Objectives

  • Describe SGML, HTML, XML, and their specifications

  • Describe SMPTE Declarative Data Essence

  • Describe cascading style sheets

  • Explain the relationships between these languages

With the advent of the Internet, declarative content, also known as markup content, has emerged as a new content type that complements traditional procedural content. iTV content may utilize this type of content to implement the scenarios described in Chapter 2. This chapter is intended to serve as an introductory overview rather than a complete refecence. The overview surveys several declarative markup content types applicable to iTV. The focus is on describing the specifications of the standards, presentation of some key issues, and the language features that address them.


5.1 Background

5.1.1 History

Declarative content earned its name due to the style of programming that calls for specifying the desired result without specifying how to achieve it . Declarative programming was, and still is, a discipline. One of the early goals of declarative programming was the development of techniques that allow specifying layout of documents and constraints on this layout, using markup languages, without specifying the algorithms with which this layout is achieved. This background motivation instilled the name markup content .

Document layout software vendors were developing their own document structure, format and encoding, giving rise to interpretability issues. For example, proprietary markup languages have been used by word processors to address their need to describe how each part of the document was to look. Today, in the context of iTV and the Internet, declarative content and markup content refer to the same type of content. Standardization efforts were launched to address this problem. The first widely accepted declarative content language is the Standard Generalized Markup Language (SGML), defined in ISO 8879 [SGML]. SGML served as the foundation on which Hyper Text Markup Language (HTML) [HTML], eXtensible Markup Language (XML) [XML], and all other markup content formats were built. As of the writing of this text, some vendors , such as Adobe, still support SGML.

5.1.2 Anatomy

The basic building block of all documents written using markup languages is the element. It is essentially a portion of the document that can be associated with layout attributes such as color , size, alignment, and so on. An element typically consists of three parts : a start tag, content, and an end tag. The start tag is written "<paren-name>", and the end tag is written as "</paren-name>" (adding the '/' characters ), where paren-name is the name of the element. This notation is an extension of parentheses notation commonly used to group words, in which the parentheses are given a name. For example, the markup representation of "(see Figure 5)" would be "<paren-name>see Figure 5</paren-name>" where <paren-name> is the name given to the pair of parentheses surrounding the text.

Each element is associated with a list of attributes, each with a name and a value assigned by the document author. Attribute value pairs appear before the final ">" of an element's start tag. As an example, one could use "<paren-name color='red'>see Figure 5</paren-name>" to indicate that the text should be printed in red.

In addition to SGML, the developers of the Internet were familiar with the LISt Processing (LISP) language, used by Artificial Intelligence (AI) programmers. In LISP, the parentheses notation is commonly used to specify expressions, declarations, functions, and program blocks. On the one hand, the SGML markup notation had the advantage that the parentheses were given names , and that opening parentheses (i.e., tags) could be associated with attributes. On the other hand, some were concerned about efficiency of encoding. Eventually, with the understanding that computing power would increase exponentially over time marginalizing the encoding efficiency issue (e.g., Moore's law predicts doubling of power every 18 months), the markup notation was selected as the foundation for standardization and subsequent development.

To enable automation of document processing, however, some standard structure was needed. In the same way that forms enable organization to improve the efficiency of their operation, document structure enables computers to automatically process documents. As it turns out, SGML has already induced an element tree structure with a single root element. Additional constraints on the structure that enable interoperability are specified by the Document Type Definition (DTD), which associates with each element the list of its attributes and the list of its possible child elements. As with forms, knowledge of the DTD enables writing efficient programs, such as search engines, that process large volumes of documents.

The parts of a document written in an SGML-based language are as follows :

  • Declaration : Specifies the characters and diameters to be used by the document.

  • DTD : Specifies constraints on the syntax of the document in terms of the elements, their attributes, and their tree structure.

  • Semantics : Describes the semantics of markup and introduces additional constraints beyond the DTD.

  • Instance : The document itself, the syntax and semantics of which are specified in the preceding parts.

Typically, for the documents written in a given markup language, the first three parts are fixed. In other words, two documents in which all four parts are identical are written in the same language; the reverse, however, might not be true as it is possible that a markup language uses multiple character sets of DTDs.

5.1.3 Architecture

SGML processors have a three-layered architecture depicted in Figure 5.1. In the first layer, the parser takes, as input, a markup document, and optionally , a DTD, and produces a document structure, which is typically the DOM [DOM]. Subsequently, the document structure is fed into flow analysis, resulting in flow-tree. Next, the flow tree is fed into a layout engine, resulting in a layout structure known as an area tree . This structure is a tree in which parent rectangles typically subsume children rectangles, and sibling rectangles do not overlap. Subsequently, each leaf in the area tree is rendered by media handlers; the media handler assigned to each area and the rendering varies according to the type of the content within each rectangle. Finally, the final details of the GUI are drawn on the graphic device.

Figure 5.1. A simplified conceptual architecture of an SGML document processor.