Answers to Exercises, Chapter 15

These are answers to the exercises in the 3rd edition of Digital Multimedia (published February 2009) only. Do not try to use them in conjunction with the 2nd edition.

Test Questions

1. We will only show the details for the first book element, as the others are essentially the same. Our choice of element and attribute names is arbitrary. As an extra exercise, modify the DTD for each of your revised versions.

   (a) The following is not the only way to eliminate attributes. You could, for instance, have sterling-price and euro-price elements, and do away with the enclosing price element.

   <books>
     <book>
       <id>cpp</id>
       <title>The Late Night Guide to C++</title>
       <author>Nigel Chapman</author>
       <price>
         <sterling>29.95</sterling>
         <euro>29.95</euro>
       </price>
       <publisher>John Wiley &amp; Sons</publisher>
       <numberinstock>
         <current>1</current>
         <ordered>6</ordered>
       </numberinstock>
     </book>
    2 more similar book elements
   </books>
   

   (b) There are many ways of turning this fragment into one that only uses empty elements, including making all the content of the inner elements into attributes of the book element. We have done it in a way that preserves the structure of the original.

   <books>
     <book id="cpp">
       <title value="The Late Night Guide to C++"/>
       <author name="Nigel Chapman"/>
       <price sterling="29.95" euro="50"/>
       <publisher company="John Wiley &amp; Sons"/>
       <numberinstock current="1" ordered="6"/>
     </book>
    2 more similar book elements
   </books>
   

   The version that stores all the data in attributes is more compact and arguably easier to read. The long-winded version that eliminates attributes would be easier to process, because of the simpler syntax, and it expresses the data's structure more explicitly. The original version printed in the book is a compromise – but not a very successful one – which uses a mixture of attributes and elements. This makes it more complex to understand and there is no clear rationale for when each is used. (This is because in the book it is intended as an example that shows both, rather than as a practical document.) We will make some more remarks on this subject under Discussion Topic 2.

2. The getElementById method cannot be used successfully with every XML document. It depends on elements having ids. As it is defined in the DOM Level 2, getElementById can retrieve an element which has an attribute of type ID whose value matches the argument passed to the method. The attribute's name doesn't have to be id (and if it is id, its type must be ID). Nevertheless, not every XML-based language uses ID attributes. Furthermore, as the standard admits, a program processing the document may not have access to the DTD or schema, so it may not be able to recognize the ID even if there is one, in which case the method will not work. In general, it is only advisable to use getElementById with XHTML and other XML-based markup languages whose elements have an attribute of type ID called id.
3. An XML document is valid if it is well-formed and, in the words of the XML standard, "it has an associated document type declaration and if the document complies with the constraints expressed in it". It follows that not every well-formed document is valid: a document might be well-formed but violate some of the constraints expressed in an associated document type declaration, or it may be well-formed and not have an associated document type declaration. However, a document cannot be valid unless it is well-formed, so every valid document is well-formed.

4. The first two lines (as the document is laid out in the question) comprise the document type declaration, which declares the root element to be html then provides the public identifier and the URL (system identifier) for the XHTML Strict DTD. These can, in principle, be used by a program to retrieve the DTD and validate the document. The next line is the start tag for the html element, which introduces the document's content. It sets the default namespace to the XHTML namespace, by assigning a URL to the xmlns attribute, so that XHTML elements do not need a namespace prefix.

   You should not expect to find anything after the </html> closing tag. It should be the last thing in the document.

   An XML declaration may precede the document type declaration but rarely does in practice, because it forces IE6 into quirks mode. Other browsers that don't understand XML may simply display the XML declaration, so it is best omitted to ensure that the document is displayed correctly by the largest number of browsers.

5. In addition to the elements and attributes, the DTD is where character references, such as & that can be used in the language are defined. (The XML language definition also permits various other sorts of "entity" to be defined and used within a DTD, but they do not generally have any impact on the users of the language.)
6. Namespace prefixes are not just used for convenience, although using full URLs would be unwieldy. XML's rules defining what constitutes a name that can be used for elements are what makes it necessary to use a namespace prefix that is not the same as the namespace URL. These rules do not permit some characters that can appear in URLs, so names constructed from full namespace URLs would not necessarily be legal XML element (or attribute) names.
7. Namespace prefixes are needed on element names when different XML-based languages are combined, to identify the language to which each element belongs and prevent name clashes. In the case of attributes, there is no need for this: an attribute appears within the start tag of an element, so you know which element it "belongs to" and hence which language it is part of. Namespaces are nevertheless sometimes used with attributes, but in this case their purpose is to identify a collection of related attributes, which should have the same meaning in any language that uses them. This helps people reading the document to understand what the attributes in some namespace mean. It also helps programs processing documents to identify attributes that must be interpreted in some particular way. For instance, the XLink proposal defined a collection of attributes that function as link sources and destinations. These are all placed in the XLink namespace. Any XML-based language that needs to provide links could declare this namespace and then use the attributes with an appropriate prefix (often xlink:). Any program that read a document that used the XLink attributes in this way would know that elements with these attributes were functioning as links, and would be able to interpret them appropriately. For instance, assuming the conventional prefix has been declared, the xlink:href attribute will point to the destination of a simple link when it appears in an a element in SVG, or in almost any element in MathML. The practice is not popular, though, and seems to be dying out. Instead, namespaces are being used to classify the values of attributes, when these lie within a limited set, such as the values of the Dublin Core fields that can be used as the values of the property attribute in RDFa. The Dublin Core namespace holds the values of the fields that are defined by the standard, and documents that declare this namespace can use the fields' names with a namespace prefix, so that they can be identified by any program that processes the document.

8. We have used a hex colour value for the fill, but you can just use the value "red" if you prefer. We have not used all the shortcuts we could have done in the path elements, but we have omitted some superfluous commands, as allowed by SVG.

   (a)

   <rect x="150" y="200" fill="#FF0000"
     width="300" height="400"/>
   

   (b)

   <polygon fill="#FF0000"
     points="150,200 450,200 450,600 150,600"/>
   

   (c) You don't actually need the final point for the polyline, the user agent will fill the shape anyway, but it does no harm.

   <polyline fill="#FF0000"
     points="150,200 450,200 450,600 150,600 150,200"/>
   

   (d)

   <path fill="#FF0000"
     d="M150 200 L450 200 450 600 150 600 150 200"/>
   

   (e)

   <path fill="#FF0000"
     d="M150 200 l300 0 0 400 -300 0 0 -400"/>
   

   (f)

   <path fill="#FF0000"
     d="M150 200 h300 v400 h-300 v-400"/>
   

9. See the errata page for clarification of this question if it puzzles you.

   We will only consider uniform scaling, as scaling the width and height by separate factors introduces a little extra complication without adding any understanding. A scale transformation that multiplies the size by a factor σ will multiply the x and y coordinates of the top left corner by σ too, so the rectangle will move to (x′, y′)=(σx, σy), so we need to add a translate transformation to move it back, by a distance ((1-σ)x, (1-σ)y). When a transformation is applied to an object, it uses the current value of its coordinates, so the translate transformation has to be expressed in terms of the new coordinate system of the scaled rectangle. That means, instead of moving by (-(1-σ)x, -(1-σ)y), we must move by (-(1-σ)/σx, -(1-σ)/σy) to compensate for the scaling.

   For the specific case when x=150, y=200 and σ=1.5, -(1-σ)/σ is equal to -1/3, so we can use the following SVG element to produce the scaled rectangle in place:

   <rect x="150" y="200" fill="#FF0000"
       width="300" height="400"
       transform="scale(1.5) translate(-50,-66.67)"/>
   

   The preceding discussion shows that, to write a general transform to scale rectangles in place, you would need to be able to pass the current coordinates and scaling factor as parameters to the translate transformation. You can't do this in SVG, because the values given to a transformation must be numbers (numeric literals). SVG isn't a programming language. The necessary computation must be done by the program (or person) generating the SVG code.

Discussion Topics: Hints and Tips

1. The HTML5 specification and much of the commentary on it implicitly convey a coherent criticism of XML-based markup languages for the Web. Much of the practical argument is directed against XML's error handling, which you may or may not find too strict for Web use. The arguments against XML are not just concerned with its use as the basis of markup languages, though. Increasingly, it is being supplanted as a data representation too. Look at YAML and JSON, for example. The arguments in this area might serve as a good starting point for the discussion if you are a programmer.

2. The answer to this question depends, of course, on what you mean by "necessary". One way of looking at it is to consider what happens to a document if you strip out all the markup. The attributes, if any, will disappear along with the tags, and what will be left could be considered the document's content. Does a document need anything else? For instance, looking at the books example, is the id for a book part of the content, or is it metadata?

   You may remark that the answer to 1(b) certainly does not demonstrate that elements can always be empty. Attribute values cannot have any structure, whereas the content of an element can contain other elements. Attribute values and element content are certainly not interchangeable.

3. Some programs that generate XHTML automatically from page layouts do so by mapping every paragraph – whether it is a simple paragraph of text, an item in a list, or a header – to a p element with a class attribute whose value is the paragraph's style, so evidently some people believe that class attributes can be used to define a document's structure. This isn't what the HTML standard says, though. However, "semantic markup" may not be an entirely simple concept. Does using a ul element for a navbar really express the semantics of navbars, or is it just a convention? What if you don't know what ul stands for, or don't speak English?
4. Since no known Web browser works in the way described, there must be some problem with the approach. Or are there other reasons why browsers do not use DTDs?
5. Consider other metalanguages, such as the extended BNF notation used to define the syntax of programming languages.
6. "Don't use the same name in different languages" may be an answer, but how do you avoid doing so? Is it really difficult, or do the problems that namespaces are supposed to prevent never actually crop up?
7. Consider another way of looking at this question: if XHTML were abolished and SVG was used to create Web pages, in what ways would the Web be different? What would be the impact on accessibility or search engines, for example?

Practical Tasks: Hints and Tips

1. There should be adequate guidance in the question for you to do this task.

2. At the risk of being obvious, we advise you to sketch the smiley face on squared paper before writing the SVG code.

   In the book, we only describe SVG's Bézier paths, so you will find it easiest to use a Bézier curve as the smile on your face. If you think that the smile must be a circular arc, you will have to look up the elliptical arc curve commands, which can be used in paths, in the SVG specification.