COAP:COAP-2180/week3

Week 3 Summary COAP 2180

On week three you will finish learning how to create your own simple DTD:

• Defining an information architecture (sketching out elements and attributes)
• Defining DTD rules for elements and attributes

This homework can be a prototype for a part of your term project.

Teaching materials

Tour de XML (This week: BPMN)

Defining a DTD

• DTD tutorial (wiki lecture notes)
• xml-dtd.pdf (slides)

Using XML Exchanger

• After each DTD changer close/reopen the XML file.
• Read Exchanger XML Editor, if needed.

Examples files (same as before)

• DTD and XML templates example directory

Textbook chapters

If you find that my lecture notes and slides are incomplete, too short or not good enough, reading either one or both texts is mandatory !

• XML in a Nutshell, Chapter 3 Document Type Definitions (start here)
• Learning XML, Chapter 4 Quality Control with Schemas (additional reading)

These chapters are available through the world classroom.

For the adventurous

• XML Category (All XML-related articles in this wiki)
• XML (on Wikipedia)
• Mix in some XHTML: See this example. You then must declare these tags in your DTD using the same prefix as in the XML file.

<!ELEMENT xhtml:img EMPTY>
<!ATTLIST xhtml:img src CDATA #REQUIRED>

Homework 3 - Week 3

Task

Create a DTD and create an associated XML test file.

• Your DTD should be somewhat text-centric (i.e. be meant for creating documents that can be displayed in some way)
• You can define the purpose of the DTD you wish to model, but it's best to discuss your plans in class.

I strongly suggest to consider a study area you are interested in, and to model for example a process, a document genre, a description of a class of artifacts, etc. Avoid lists of CDs, cars, etc.

If you reuse elements from an other DTD, please tell so (in the comments of the DTD). Plagiarism will be punished, but documented reuse of elements from an existing DTD or even inclusion of a whole DTD (e.g. for formatting) is just fine !

Tips:

• Take into account that you may reuse this DTD in most follow-up projects, including the term project !!
• Do not attempt to define a too simple DTD (lists) or a very complex one. Make it both interesting and reasonable.
• Do not worry about rendering (display). It will be done in homework 4. In week 4/5 you will learn how to add information to a text, e.g. if you have an element like:

<adress>Mr. X., 1 Cool st., Geneva</address>

you will be able to make the result look like: Private Address: Mr X. ,....... In other words: Think about data, not display !

Use of the xngr editor

• The editor reads the DTD when you load the XML file. This implies that you will have to define a skeleton before you can actually use/test the DTD. E.g.

<?xml version="1.0"?>
<!DOCTYPE cd-list SYSTEM "cd-list.dtd">

<cd-list>
	
</cd-list>

This also implies, that you will have to close the XML file and to reload it after making changes to the DTD.

Deadline and submission:

• Monday week 4 (before 9h)
• Use the world classroom
• Submit the *.dtd plus the *.xml test files and an optional report file (see below)

Evaluation criteria

Consult the evaluation grid in the world classroom for details !

Work considered as weak:

• Correct DTD that contains at least 5 elements that you invented yourself and a somewhat valid XML example file

Work considered as minimalist:

• A correct small DTD that fits a purpose (including a valid XML example file)

Good work may include one or several of the following

• Inserted comments in the DTD and that explains the purpose of the DTD, the purpose of each element, authorship, date, etc.
• A DTD that is "interesting" and useful for a given domain, e.g. it should include more than just 5 elements
• Use of attributes
• Use of entities
• A DTD that is more complex than a simple table (e.g. one that contains recursive elements or links)
• A good XML example that uses all elements more than once (i.e. you do information architecture testing)

Excellent work (A-) includes in addition

• A 1-2 page report that discusses your information architecture (the DTD structure) and results (what do you think of it, how could you improve it, etc.). You may include this report as "comment" in the DTD.

Brilliant work (A)

• Does most of the above, i.e. produces a DTD that could be used for real plus a decent documentation.