Presentation Technologies
 | |
Team-Fly  |
 | XML, Web Services, and the Data Revolution By Frank P. Coyle |
| Table of Contents | |
| Chapter 2. The XML Technology Family |
| Representing data with XML opens up new possibilities for transport and distribution. XML presentation technologies provide a modular way to deliver and display content to a variety of devices. Here we examine some technologies for display, including CSS, XSL, Xforms, and VoiceXML. CSS
Cascading style sheets is an XML-supporting technology for adding style display properties such as fonts, colors, or spacing to Web documents. CSS origins may be traced to the SGML world, which used a style sheet technology called DSSSL to control the display of SGML documents. Style sheet technology is important because it lets developers separate presentation from content, which greatly enhances software's longevity. As Figure 2.10 shows, a style sheet tells a browser or other display engine how to display content. Each rule is made up of a selector ”typically an element name such as an HTML heading ( H1 ) or paragraph ( P ), or a user -defined XML element ( Book ) ”and the style to be applied to the selector. The CSS specification defines numerous properties ( color , font style, point size , and so on) that may be defined for an element. Each property takes a value which describes how the selector should be presented. Figure 2.10. HTML or XML may be delivered to a browser with CSS, which controls how data is presented on the screen. Style rules have the following syntax. selector { property: value } Multiple style declarations for a single selector are separated by a semicolon. The following code segment shows how a CSS element can be added to an HTML or XML document to define the color and font size properties for TITLE and AUTHOR elements: <STYLE TYPE="text/css"> TITLE { font-size: x-large; color: red } AUTHOR { font-size: large; color: blue } </STYLE> This style sheet tells the browser to show the content of TITLE elements in an extra-large red font, and to show the content of AUTHOR elements in a large blue font. Although CSS technology was designed to allow finer control of how HTML is displayed, CSS makes no assumptions about the tags' names , which is why cascading style sheets can be used just as easily with XML as with HTML.
Because style sheet technology is important for the Web design industry, the CSS specification has undergone significant evolution. The CSS1 specification, which defines all properties and values that can be applied to a Web document, received its W3C Recommendation status in December 1996. It describes the CSS language as well as a simple visual formatting model. CSS2, which itself became a W3C Recommendation in May 1998, builds on CSS1 and adds support for style sheets for specific media such as printers and audio devices, as well as downloadable fonts, element positioning, and tables.
However, there are two drawbacks with CSS that should be noted. The first is that CSS describes only those tags that are to be treated in a special way; the browser decides how to display elements that the style sheet says nothing about. While this typically works fine for HTML, with XML, where it may be desirable not to display certain data, CSS does not help. The second drawback is that with CSS technology it is up to the browser to implement CSS correctly, and some implementations may not always be consistent. XSLXSL 1.0 is a W3C Recommendation that provides users with the ability to describe how XML data and documents are to be formatted. XSL does this by defining "formatting objects," such as footnotes, headers, or columns .
The XSL initiative began as an effort to develop a styling technology more suited to the needs of XML than CSS. However, in pulling together a Working Group to define XSL, something interesting happened . The Working Group realized that the kind of styling per formed by technologies such as CSS was only one instance of a more general "transformation" process of taking an XML document and turning it into another kind of document. After much deliberation the XSL Working Group split into two subgroups, one focused on trying to build a better display-oriented style sheet technology and a second group trying to define a transformation language that could be used to transform XML into a variety of target languages including HTML, other dialects of XML, or any text document, including a program. The result of this effort was XSLT, which achieved W3C Recommendation status in November 1999 and which we discuss in the next section of this chapter.
An XSL style sheet is basically a series of pattern-action rules and looks like an XML document with a mixture of two kinds of elements: those defined by XSL and those defined by the object language. The patterns are similar to CSS's selectors, but the action part may create an arbitrary number of "objects." The action part of the rule is called the "template" in XSL, and a template and a pattern together are referred to as a "template rule." The result of applying all matching patterns to a document recursively is a tree of objects, which is then interpreted top-down according to the definition of each object. For example, if they are HTML objects, an HTML document will be generated; if they are XML objects, XML will be the result. CSS Compared to XSLThe fact that the W3C has started developing XSL in addition to CSS has caused some confusion. Why develop a second style sheet language when implementers haven't even finished the first one? The W3C has answered this question with the information in Table 2.1. In practice, both CSS and XSL may be used in conjunction with each other. Figure 2.11 illustrates some of the different options for using CSS and XSL to create displays based on HTML or XML. The general principle is that if the document is to be simply rendered and not transformed in any way through the addition or deletion of items, then CSS is the more straightforward approach. Figure 2.11. Options for using CSS and XSLT with XML and HTML. [2]
XForms
Soon after HTML began to be used to deliver content from Web sites to browsers, it became apparent that it was also necessary to push data from browsers to servers. The result was HTML forms. Since their introduction in 1993, forms have become a critical aspect of Web-based e-commerce. However, existing mechanisms for form data capture are limited, especially when complex data spanning multipart forms must be collected and complex logic is required. Table 2.1. Comparison of CSS and XSL
XForms is an XML approach that overcomes the limitations of HTML forms. XForms is a GUI toolkit for creating user interfaces and delivering the results in XML. Because XForms separates what the form does from how it looks, XForms can work with a variety of standard or proprietary user interfaces, providing a standard set of visual controls that replaces the primitive forms controls in HTML and XHTML. Included in XForms are a variety of buttons , scrollbars, and menus integrated into a single execution model that generates XML form data as output. Figure 2.12 illustrates how a single device-independent XML form definition, called the XForms Model, has the capability to work with a variety of standard or proprietary user interfaces. For example, the Voice Browser Working Group is looking at developing voice-based user interface components for XForms. Figure 2.12. XForms provides a standard way to collect form data through a variety of device interfaces. There are currently several XForms implementations:
XHTML
XHTML is an effort by the W3C to replace HTML with a more flexible approach to displaying Web content. XHTML differs from HTML in that it is based on XML, not SGML. Thus, XHTML conforms to the XML 1.0 Recommendation. The long- term goal of the XHTML spec is that XHTML will continue to be useful in environments where there are no preconceived notions about how elements should be rendered in a browser. The approach is one in which developers will be able to extend in unanticipated ways as new technologies and display media emerge. Its modular design reflects the realization that a one-size-fits-all approach to the Web no longer works, especially when browsers differ significantly and cell phones have limited memory and screen size for display. XHTML Modularization
The capability of XHTML to be more flexible than HTML is attributable to the use of XHTML modules for creating XHTML-conforming markup languages. New XHTML-compliant languages must use the basic XHTML framework as well as other XHTML modules. As illustrated in Figure 2.13, modules plug together within the XHTML framework to define a markup language that is task or client specific. Documents developed based on the new markup language will be usable on any XHTML-conforming clients . Figure 2.13. The structure of XHTML.
In some instances, people will create complete, proprietary markup languages using XHTML. People may also create new, reusable modules that will find use within their own or other organizations. The architecture and technology behind XHTML are already finding use within the W3C by organizations such as the Organization for the Advancement of Structured Information Standards (OASIS) and Project Gutenberg, which are using XHTML modularization to create new markup languages for industry-specific applications. XHTML is also finding applicability within the wireless industry that sees it as the next-generation language of choice for NTT DoCoMo's i-mode cell phones and as the WAP Forum's replacement technology for WML. VoiceXML
VoiceXML is an emerging standard for speech-enabled applications. Its XML syntax defines elements to control a sequence of interaction dialogs between a user and an implementation platform. The elements defined as part of VoiceXML control dialogs and rules for presenting information to and extracting information from an end-user using speech. For ZwiftBooks, VoiceXML opens up options for extending its service to voice through cellular networks. As Figure 2.14 illustrates, VoiceXML documents are stored on Web servers. Translation from text to voice is carried out either on a specialized server that delivers voice directly to a phone or by the device itself using speech processing technology. Figure 2.14. VoiceXML documents are used to drive voice interactions over conventional or wireless phones. Just as a Web browser interprets HTML and displays it on the screen, a VoiceXML browser understands VoiceXML markup and interprets it for presentation over the telephone or directly to an audio channel. As mobile devices such as cell phones acquire additional processing power, it will be possible to deliver VoiceXML documents directly to cell phones for VoiceXML processing. The VoiceXML document specifies each interaction dialog. User input affects dialog interpretation and is collected into requests that go back to the VoiceXML server. The server may reply with another VoiceXML document to continue the user's session with other dialogs. A VoiceXML document includes tags defining both audio prompts and logic. For example, the content of a prompt tag is converted by a VoiceXML browser to speech. Other VoiceXML tags include form for building a voice-driven form to collect user information and menu , which leads an end-user through a series of menu selections. Forms and Menus
There are two kinds of dialogs: forms and menus. Forms define an interaction that collects values for a group of fields. Each field may specify a grammar that controls the allowable inputs for that field. Menus present the user with a choice of options and then transition to another dialog based on that choice. Forms also contain subdialogs that provide a mechanism for triggering a new interaction and returning to the original form. Subdialogs can be used to create a confirmation sequence that may require a database query, a set of components for sharing among documents in a single application, or a reusable library of dialogs shared across many applications. | ||||||||||||||||||||||||||||||
| | |
| Team-Fly |
| Top |
EAN: 2147483647
Pages: 106