XML - Grundlagen, Prinzipien und Anwendungen

Aufgabe 2 (XML DTD)

Verfeinern der DTD

Abgabe bis Dienstag, 25.4.2006

Remark: For questions and/or clarifications about this exercise contact Pascal Kurtansky who is handling this Exercise Session.

In this exercise, you will extend the solution from Exercise 1 with stuff you learnt in today's lecture. The following points are covered:

Parameter Entity Declarations and References
DTD Modularization
Internal Entities and Character References

Task Hints

	Task	Hints
1.	Parameter Entity Declarations and References: Recall from the lecture that for DTDs the Parameter Entity declarations help you in two ways: (a) reuse a set of attributes for several elements and (b) define data types not supported by DTDs, which are then later used as data types for appropriate attributes. Modify the DTD you designed last week such that you invoke the Parameter Entity mechanism at least twice: (at least) once each in the sense of (a) and (b) above.	As a guide to using Parameter Entity mechanism for (a), consider the following: Suppose the elements `length` and `year` (in the figure above) are made attributes of both `track` and `album`. Now, one may create a Parameter Entity which can be used in the declarations of the elements `track` and `album`. Part (b) should be relatively straight forward.
2.	DTD Modularization: When a DTD gets moderately complex, it is useful (and meaningful) to split the definitions into several individual DTD files that cross reference each other. This is similar to developing a medium-to-large sized application in your favourite programming language where you would create individual modules in separate files rather than putting all of them in a single one. For the relatively simple DTD for the Music-list application, modularization would not be necessary. For understanding sake, however, design a modularised version of your DTD such that the definitions are in (a minimum of) three different files. To get you started here is a DTD file that defines the `address` element. You have to modularize your DTD such that this element is referenced in both the other DTD modules. Finally, your XML document should be able to reference all the different DTD modules as if they were one DTD.
3.	Internal Entities and Character References: The XML standard defines that all XML processors must accept the UTF-8 and UTF-16 encodings of Unicode 3.1. This allows all Unicode characters to appear literally in an XML document. However, if we use the US-ASCII character encoding, only ASCII characters may appear literally, and all other characters must be encoded as character references (for example, `ü` for a `ü`). For this last part, we ask you to prepare and submit two versions of your XML document (which represent the same tree using different mechanisms): In the first version, change the default character encoding in the Text Declaration of your document to US-ASCII. Now you cannot include non-ASCII characters literally. To use them anyway, one may use character references directly in the document, for instance, `ü` for a `ü`. This is hard to remember and type. Instead, use these characters in your document through entity references by including an appropriate XHTML Entity Set. In the second version, change the character encoding of the XML document to a character encoding that is able to handle German umlaut characters, and refer to the umlaut characters by their literal equivalents. This makes the document easier to read, but requires an editor which is capable of handling this character encoding.	You will find the umlaut (as well as many other) characters defined in the Entity Set xhtml-lat1.ent from the XHTML DTDs. One possibility for a character encoding that handles the umlaut characters is ISO-8859-1, another is XML's default encoding UTF-8.

Parameter Entity Declarations and References: Recall from the lecture that for DTDs the Parameter Entity declarations help you in two ways: (a) reuse a set of attributes for several elements and (b) define data types not supported by DTDs, which are then later used as data types for appropriate attributes.

Modify the DTD you designed last week such that you invoke the Parameter Entity mechanism at least twice: (at least) once each in the sense of (a) and (b) above.

As a guide to using Parameter Entity mechanism for (a), consider the following: Suppose the elements length and year (in the figure above) are made attributes of both track and album. Now, one may create a Parameter Entity which can be used in the declarations of the elements track and album.

Part (b) should be relatively straight forward.

DTD Modularization: When a DTD gets moderately complex, it is useful (and meaningful) to split the definitions into several individual DTD files that cross reference each other. This is similar to developing a medium-to-large sized application in your favourite programming language where you would create individual modules in separate files rather than putting all of them in a single one. For the relatively simple DTD for the Music-list application, modularization would not be necessary.

For understanding sake, however, design a modularised version of your DTD such that the definitions are in (a minimum of) three different files. To get you started here is a DTD file that defines the address element. You have to modularize your DTD such that this element is referenced in both the other DTD modules. Finally, your XML document should be able to reference all the different DTD modules as if they were one DTD.

Internal Entities and Character References: The XML standard defines that all XML processors must accept the UTF-8 and UTF-16 encodings of Unicode 3.1. This allows all Unicode characters to appear literally in an XML document. However, if we use the US-ASCII character encoding, only ASCII characters may appear literally, and all other characters must be encoded as character references (for example, ü for a ü). For this last part, we ask you to prepare and submit two versions of your XML document (which represent the same tree using different mechanisms):

In the first version, change the default character encoding in the Text Declaration of your document to US-ASCII. Now you cannot include non-ASCII characters literally. To use them anyway, one may use character references directly in the document, for instance, ü for a ü. This is hard to remember and type. Instead, use these characters in your document through entity references by including an appropriate XHTML Entity Set.
In the second version, change the character encoding of the XML document to a character encoding that is able to handle German umlaut characters, and refer to the umlaut characters by their literal equivalents. This makes the document easier to read, but requires an editor which is capable of handling this character encoding.

You will find the umlaut (as well as many other) characters defined in the Entity Set xhtml-lat1.ent from the XHTML DTDs.

One possibility for a character encoding that handles the umlaut characters is ISO-8859-1, another is XML's default encoding UTF-8.

Submission of this exercise has to be done via email. To make it as easy as possible for you, simply follow the Submission of Exercise 2 link ;-)

The email should consist of the URI of the DTDs and your XML instances. The DTDs and XML documents will be checked for syntactical correctness and validity. Furthermore, verification of conformance to the above described specifications will be carried out.

IMPORTANT: The solutions will be validated, as with Exercise 1, with the Validator from Brown University. Please check your submissions there before handing them in. Thanks!

please send comments to xml-vl@dret.net
last modification on Tuesday, 18-Apr-2006 12:42:11 CEST