4. Defining Web Document Types

Document Types
Document Type Definitions (DTDs)
Valid XML
Valid XHTML
DTD syntax
Examples of DTD element declarations
DTD syntax
DTD for RSS
Validation of XML Documents
Referencing a DTD
Declaring an Internal DTD
Declaring an External DTD (1)
Declaring an External DTD (2)
Attributes
Some Attribute Types
Attribute Defaults
Mixed Content Models
Some exercises
Family example DTD
Family example: XML document
A valid family
An invalid family
Entities
Example using Entities
General Entities
Parameter Entities
Limitations of DTDs
Exercises
Links to more information

4.1. Document Types

a document type is defined by specifying the constraints which any document which is an instance of the type must satisfy
for example,
- in an HTML document, one paragraph cannot be nested inside another
- in an SVG document, every circle element must have an r (radius) attribute
document types are
- useful for restricting authors to use particular representations
- important for correct processing of documents by software
there are many languages for defining document types on the Web, e.g.,
- document type definitions (DTDs)
- XML schema definition language (XSDL)
- relaxNG
- schematron
we will consider only DTDs

4.2. Document Type Definitions (DTDs)

DTD defines a class of documents
specified using an extended context-free grammar
defines
- element names and their allowed contents
- attribute names and their allowed values
- entity names and their allowed values

4.3. Valid XML

a valid document
- is well-formed and
- has been validated against a DTD (specified in the document - see later)

XML parser checking document is valid

4.4. Valid XHTML

XHTML parser checking document is valid

all XHTML element names (tags) must be in lowercase
empty elements must use abbreviated closing tag
- e.g., <hr> must appear as <hr/> (or <hr /> to fool old browsers)
must conform to one of 3 DTDs: strict, transitional or frameset
- strict: presentation must use CSS
- transitional: presentation information can be embedded in document
- frameset: for documents using frames (not covered)
XHTML document can be validated using the W3C validator service

4.5. DTD syntax

syntax for an element declaration in a DTD is:
```
<!ELEMENT name    (model) >
```
where
- ELEMENT is a keyword
- name is the element name being declared
- model is the element content model (the allowed contents of the element)
content model specified using a regular expression over element names
regular expression specifies the permitted sequences of element names

4.6. Examples of DTD element declarations

an html element must contain a head element followed by a body element:
```
<!ELEMENT html    (head, body) >
```
where "," is the sequence (or concatenation) operator
a list element (not in HTML) must contain either a ul element or an ol element (but not both):
```
<!ELEMENT list    (ul|ol) >
```
where "|" is the alternation (or "exclusive or") operator
a ul element must contain zero or more li elements:
```
<!ELEMENT ul    (li)* >
```
where "*" is the repetition (or "Kleene star") operator

4.7. DTD syntax

DTD Syntax	Meaning
`b`	element `b` must occur
`b,c`	both `b` and `c` must occur, in the order specified
`b\|c`	one (and only one) of `b` or `c` must occur
`b*`	zero or more occurrences of `b` must occur
`b+`	one or more occurrences of `b` must occur
`b?`	zero or one occurrence of `b` must occur
`EMPTY`	no element content is allowed
`ANY`	any content (of declared elements and text) is allowed
`#PCDATA`	content is text rather than an element

element names in above table are b and c
parentheses can be used for grouping, e.g., (a,b)*
b+ is short for (b,b*)
b? is short for (b|EMPTY)

#PCDATA stands for "parsed character data", meaning an XML parser should parse the characters to resolve character and entity references.

4.8. DTD for RSS

a fragment of a simplified DTD for RSS might be

<!ELEMENT rss         (channel) >
<!ELEMENT channel     (title,link,description,item+) >
<!ELEMENT item        (title,description,link,pubDate?) >
<!ELEMENT title       (#PCDATA) >
<!ELEMENT link        (#PCDATA) >
<!ELEMENT description (#PCDATA) >
<!ELEMENT pubDate     (#PCDATA) >

4.9. Validation of XML Documents

recall that an XML document is called valid if it is well-formed and has been validated against a DTD
validation is essentially checking that the XML document, viewed as a tree, is a parse tree in the language specified by the DTD
can use an online XML validator
each of the following has the same DTD specified (as on the previous slide):
- rss-fragment-dtd-invalid.xml giving results
- rss-fragment-dtd-valid.xml giving results

4.10. Referencing a DTD

DTD to be used to validate a document can be specified
- internally (part of document)
- externally (in another file)
done using a document type declaration
declare document to be of type given in DTD
e.g., <!DOCTYPE rss ... >

4.11. Declaring an Internal DTD

<?xml version="1.0"?>
<!DOCTYPE rss [
    <!-- all declarations for rss DTD go here -->
    ...
    <!ELEMENT rss ... >
    ...
]>
<rss>
   <!-- This is an instance of a document of type rss -->
   ...
</rss>

element rss must be defined in the DTD
name after DOCTYPE (i.e., rss) must match root element of document

4.12. Declaring an External DTD (1)

<?xml version="1.0"?>
<!DOCTYPE rss SYSTEM "rss.dtd">
<rss>
   <!-- This is an instance of a document of type rss -->
   ...
</rss>

what follows SYSTEM is a URI
rss.dtd is a relative URI, assumed to be in same directory as source document

4.13. Declaring an External DTD (2)

<?xml version="1.0"?>
<!DOCTYPE math PUBLIC "-//W3C//DTD MathML 2.0//EN"
     "http://www.w3.org/TR/MathML2/dtd/mathml2.dtd">
<math>
   <!-- This is an instance of a mathML document type -->
   ...
</math>

PUBLIC means what follows is a formal public identifier with 4 fields:
1. ISO for ISO standard, + for approval by other standards body, and - for everything else
2. owner of the DTD: e.g., W3C
3. title of the DTD: e.g., DTD MathML 2.0
4. language abbreviation: e.g., EN
URI gives location of DTD

Formal public identifiers are meant for widely used entities. They should be unique world-wide. Processing software might either come with such entities already installed or it might know the most efficient sites form which to download them. If not, the URI is used to retrieve the DTD.

4.14. Attributes

recall that attribute name-value pairs are allowed in start tags
e.g., href="file.html" in an HTML a start tag
allowed attributes for an element are defined in an attribute list declaration

e.g., for rss and guid elements, these might be

<!ATTLIST rss
   version CDATA #FIXED "2.0" >
<!ATTLIST guid
   isPermaLink (true|false) "true" >

attribute definition comprises
- attribute name, e.g., version
- type, e.g., CDATA
- default, e.g., "true"

4.15. Some Attribute Types

CDATA: any valid character data
ID: an identifier unique within the document
IDREF: a reference to a unique identifier
IDREFS: a reference to several unique identifiers (separated by white-space)
(a|b|c), e.g.: (enumerated attribute type) possible values are one of a, b or c

4.16. Attribute Defaults

#IMPLIED: attribute may be omitted (optional)
#REQUIRED: attribute must be present
#FIXED "x", e.g.: attribute optional; if present, value must be x
"x", e.g.: value will be x if attribute is omitted

4.17. Mixed Content Models

in rss DTD all content models comprise only elements or only text
in HTML, paragraph elements, e.g., allow text interleaved with various in-line elements, such as em, img, b, etc.
such a model is said to have mixed content
if we want to mix text with elements em, img and b as contents of element p:
```
<!ELEMENT p (#PCDATA | em | img | b)* >
```
#PCDATA must be first (in the definition)
followed by other elements separated by |
all must have * applied to them
this limits our ability to constrain the content model

4.18. Some exercises

Consider the content models (zero, one)* and (zero | one)*. Give an example of a sequence of elements allowed by the one model but not by the other.
Consider the elements day, month and year. Produce a content model which allows for each of the sequences
```
year
month year
day month year
```
but no others.

4.19. Family example DTD

<!ELEMENT family (parent, (parent)?, (child)*)>
<!ELEMENT parent (name)>
<!ELEMENT child  (name)>
<!ELEMENT name   (#PCDATA)>

<!ATTLIST parent
  pno     ID               #IMPLIED
  role    (mother|father)  #IMPLIED
  spouse  IDREF            #IMPLIED>

<!ATTLIST  child
  cno           ID      #IMPLIED
  date-of-birth CDATA   #IMPLIED
  siblings      IDREFS  #IMPLIED>

spouse attribute is meant to be interpreted as a reference to a pno attribute
siblings attribute is meant to be interpreted as a set of references to cno attributes

4.20. Family example: XML document

<?xml version="1.0"?>
<!-- <!DOCTYPE family [ ... DTD goes here ... ]> -->
<family>
  <parent pno="p1" role="mother" spouse="p2">
    <name>Janet</name>
  </parent>
  <parent pno="p2" role="father" spouse="p1">
    <name>John</name>
  </parent>
  <child cno="c1" siblings="c2 c3">
    <name>Tom</name>
  </child>
  <child cno="c2" siblings="c1 c3">
    <name>Dick</name>
  </child>
  <child cno="c3" siblings="c1 c2">
    <name>Harry</name>
  </child>
</family>

4.21. A valid family

<?xml version="1.0"?>
<!-- <!DOCTYPE family [ ... DTD goes here ... ]> -->
<family>
  <parent pno="janet">
    <name>Janet</name>
  </parent>
  <child date-of-birth="yesterday">
    <name>Tom</name>
  </child>
</family>

no need for an attribute of type ID to be referenced
date-of-birth cannot be restricted to a valid date by a DTD

4.22. An invalid family

<family>
  <parent role="stepmother" spouse="john jim">
    <name>Janet</name>
  </parent>
  <parent pno="john" spouse="janet"></parent>
  <parent pno="jim" spouse="janet"></parent>
</family>

if role is given, must be mother or father
spouse must refer to only one value of type ID
spouse must refer to a value of type ID which exists
each parent must have a name
at most two parent elements allowed
checking the file invalid-family.xml using the online XML validator gives results

4.23. Entities

entity is a physical unit such as a character, string or file
entities allow
- references to non-keyboard characters
- abbreviations for frequently used strings
- documents to be broken up into multiple parts
entity declaration in a DTD associates a name with an entity, e.g.,
<!ENTITY BBK "Birkbeck, University of London">
entity reference, e.g., &BBK; substitutes value of entity for its name in document
entity must be declared before it is referenced

4.24. Example using Entities

the rhyme xmas.xml can be produced by

<!DOCTYPE xmas [
<!ENTITY  on        "On the">
<!ENTITY  day       "day of Christmas my true love sent to me">
<!ENTITY  partridge "<line>a partridge in a pear tree.</line>">
<!ENTITY  doves     "<line>two turtle doves and</line> &partridge;">
<!ENTITY  hens      "<line>three French hens,</line> &doves;">
<!ELEMENT xmas      (verse+)>
<!ELEMENT verse     (line+)>
<!ELEMENT line      (#PCDATA)>
]>
<xmas>
  <verse><line>&on; first  &day;</line> &partridge;</verse>
  <verse><line>&on; second &day;</line> &doves;</verse>
  <verse><line>&on; third  &day;</line> &hens;</verse>
</xmas>

4.25. General Entities

BBK is an example of a general entity
can also be used for non-keyboard characters, i.e, a character entity reference (see slide 3.23)
in XML, only 5 general entity declarations are built-in
- & (&), < (<), > (>), " ("), ' ('),
contents of internal entities are defined in same document as references to them
contents of external entities are defined elsewhere, e.g.,
<!ENTITY HTML-chapter SYSTEM "html.xml" >
- then &HTML-chapter; includes contents of file html.xml at point of reference
- must include standalone="no" in XML declaration

4.26. Parameter Entities

parameter entities are
- used only within XML markup declarations
- declared by inserting % between ENTITY and name, e.g.,
```
<!ENTITY % list     "OL | UL" >
<!ENTITY % heading  "H1 | H2 | H3 | H4 | H5 | H6" >
```
- referenced using % and ; delimiters, e.g.,
```
<!ENTITY % block  "P | %list; | %heading; | ..." >
```
as an example. see the HTML 4.01 DTD

4.27. Limitations of DTDs

non-XML syntax
no data typing, especially for element content
only marginally compatible with namespaces
cannot use mixed content and enforce order and number of child elements
clumsy to enforce presence of child elements without also enforcing order (i.e. no & operator from SGML)
element names in a DTD are global
XML Schema Definition Language, e.g., addresses these limitations

4.28. Exercises

Write an XML DTD which will define the following structure for documents of type exam. An exam has a course code, a title and a date, which comprises only the month and year. These are followed by a list of questions. Exams consist of either 5 or 6 questions. Each question has one or more parts. Parts of questions can themselves comprise parts along with text.

Give an instance of an exam document which is valid with respect to your DTD and two instances which are invalid, explaining why they are invalid. Check your answers using an on-line XML validator.

Write an XML DTD for representing information about students on an MSc programme. All information should be represented using elements rather than attributes. The root element of the document is programme. A programme has a degree and a year. These elements are followed by the results for the programme. The results are partitioned into distinction, merit, pass and fail. Within each is a sequence of name elements, each containing the name of a person having achieved the corresponding result for the programme.

Consider a relational database containing a relation teaches with attributes course and lecturer, representing the relationship between courses taught on an MSc programme and the lecturers who teach them. Give an XML DTD for representing this information.

4.29. Links to more information

www.w3.org/TR/REC-xml.html
the latest version of the XML 1.0 specification (includes specification of DTDs)
www.w3schools.com/dtd
DTD tutorials and examples
validator.w3.org
XML validator
en.wikipedia.org/wiki/Chomsky_hierarchy
Wikipedia entry for formal grammars and Chomsky hierarchy

DTDs are covered in Chapter 4 of [Moller and Schwartzbach] and briefly in Chapter 2 of [Jacobs].