Introduction to DTD. Mario Arrigoni Neri

Transcription

1 Introduction to DTD Mario Arrigoni Neri 1

2 Well formed and valid XML documents 2 Different levels in standardization for different levels of correctness : Well formed document: an XML document is well formed if respects all XML general rules, like correct element nesting, single root element and no sintax errors valid XML : in order to be valid a document must be well formed and must use the right elements of the specific language propertly Ex: <title><book/><book> Titolo </book></title> is well formed but, it is probably non valid Well formation (or good formation) can be evaluated using XML general rules only Validation depends on the specific language the document declares to use

3 DTD DTD (Document Type Definition) in a part of original XML standard definition and is used to describe validation rules for a specific language The core of an XML application is the parser, that is the responsible of acquiring the document and building some high level representation of contained data A validating parser, if a DTD schema definition is available, can validate the document A non validating parser, even if a DTD is present is able to check only if the document is well-formed DTD describes XML shape in term of elements, tags, attributes, entities, PCDATA ad CDATA fragments 3

4 <!DOCTYPE> DOCTYPE directive indicates the type of the document, that is the type of its root DTD dlanguage definition can be both external and internal to the XML instance document. internal (or in-line) DTD: <!DOCTYPE <doctype> [.. DTD code..]> external: DOCTYPE tag provides a reference <!DOCTYPE <doctype> SYSTEM dtd file url > Example: <?xml version= 1.0?> <!DOCTYPE note SYSTEM note.dtd > <note> </note> The type of the document 4

5 elements 5 DTD defines the types of the elements that can occur in instance documents For each element type the type of content must be defined: Any content: no constraint is placed on the content Ex: <!ELEMENT memo ANY> Empty content: the element must be empty, so it is usually serialized as an empty tag Ex: <!ELEMENT br EMPTY> Simple content: is an elemnt which content iconsists in plain text. #PCDATA stays for Parsed Character Data. Ex: <!ELEMENT message (#PCDATA)> Element content: in this cate che element contains a sequence of other sumelements Ex: <!ELEMENT note (to, from, title, message)> Mixed content: is the type of the elements that contain text fragments interleaved with other subelements.

6 element content - sequence An element of type sequence contains a list of exactly the subelements specified by the constructor, in the same order Subelements list is comma separated DTD <!ELEMENT note (to, from, title, message)> valid XML <note> <to/><from/> <title/><message/> </note> 6

7 element content - choice The content in actual instance documents must be choosed from the list of suitable elements Subelements are divided by pipes DTD <!ELEMENT a (b c d) > valid XML <a> <b></b> </a> 7

8 element content - iteration Different ways to define cardinality of each subelement: No modification: argument must occur exactly once <!ELEMENT a (b)> the fragment must be <a><b/></a>?: option. The subelement is not mandatory <!ELEMENT a (b?)> both <a/> and <a><b/></a> +: repeating. Suelement must occur at least once <!ELEMENT a (b+)> <a><b/></a>, <a><b/><b/></a>, etc... *: repeating. Subelement can occur zero, one or more times <!ELEMENT a (b*)> <a/>, <a><b/></a>, <a><b/><b/></a>, etc... 8

9 Complex element contents 9 Simple constructors combines in regular expressions <!ELEMENT section (title, abstract?, para+)> each section has a title, can optionally have an abstract and must ave at least one paragraph <!ELEMENT section (title, (abstract para)+)> each section must have a title, followed by at least one abstract or a paragraph. Abstracts and paragraphs can then follow in any order <!ELEMENT section (title, abstract*, para+)> sections are composed of a title, an optional sequence of abstracts and a sequence of at least one paragraph <!ELEMENT section (title, (subtitle abstract)?, para+)> a section has a title, one between subtitle and abstract, which can be omitted, and a sequence of at least one paragraph <!ELEMENT section (title, subtitle?, abstract?, para+> similar to the previous one, but...

10 mixed contents Differently from SGML, in XML DTD simple text content expressed by #PCDATA and the content composed of subelements can combine only in the canonical form: <!ELEMENT para (#PCDATA bold italic)*> 10 Each paragraph contains text in which we can insert, optionally, <bold> and <italic> subelements Es: <para> <bold>this</bold> text contains sections written in <bold>bold</bold> and <italic>italic</italic>, but could have none </para>

11 attributes using DTD we can constraint the attributes of each element and the values they can assume <!ATTLIST elementname attribute1 type1 modifier1 attribute2 type2 modifier2 attribute-n type-n modifier-n> Type defines the set or the kind of values the attribute can assume Modifier describes if the attribute is mandatory or optional, if it has a default value, etc. 11

12 String attributes <!ATTLIST messagge lang CDATA Italian > Lang attribute is a string If it is present in instance document, the value is specified Otherwise the default value Italian is assumed <note> <message lang= English > Remember the date </message> </note> <note> <message> Ricordati l appuntamento </message> </note> 12

13 Attributes by enumeration <!ATTLIST person salutation (Mr Mrs Miss Dr) Mr > Salutation of a person must assume a foreseen value If the value is missing in the instance, default value Mr is assumed <person salutation= Dr > <name>luke</name> <surname>brown</name> </person> 13

14 Special attribute types DTD defines some special attribute types ID: unique identifier (key) <!ATTLIST User login ID #REQUIRED> IDREF: reference to an existing identifier from the same file (intra-file foreign key) <!ATTLIST User userclass IDREF #REQUIRED> 14 IDREFS: like IDREF, but can include list of values NMTOKEN or NMTOKENS: a character string (or a list of strings) with no spaces or separators ENTITY or ENTITIES: the value must be obtained expanding an entity

15 modifiers 15 Default value: expressed by a string, is the value the parser will return to application layer if the attribute is missing Fixed value: defined by #FIXED followed by the value. Each occurrence of this attribute must assume the value specified in the schema. XML instances can omit it or repeat the same value <!ATTLIST person parents CDATA #FIXED 2 > obligatory: #REQUIRED. The attribute must be specified in each applicable element <!ATTLIST measure value CDATA #REQUIRED> optional: #IMPLIED. The attribute is optional and can be omitted with no impact. If combined with ID attribute type the parser will generate a new unique identifier

16 entities DTD entities are recurrent fragments of text. A simple identifier is associated to the text fragment, which can be expanded like a macro before the document actual parsing Entity definition: <!ENTITY entityname value> Entity is placed in the document with the sequence: &entityname; Example: <!ENTITY autor Mario Arrigoni Neri > 16 <document> <title>introduction to XML</title> <author>&autor;</author> </document>

17 External entities External entities are read from independent files <!ENTITY entityname SYSTEM source XML url > Ex: <!ENTITY text SYSTEM book.txt > <book> <title>..</title> <text>&text;</text> </book> In some particular cases entities may not be parsed, this expecially applies to binary data 17 <!ENTITY image SYSTEM image.gif NDATA gif>

18 Predefined entities Single unicode characters. For example represents ASCII 10. Some dangerous characters, like < and &, < < > > & & &apos; " Equivalent to : <![CDATA [<]]> 18

19 Parametric entities Are entities defined in the DTD and consumed by the DTD itself Are Expanded while loading DTD Contains recurrent fragments of the model of the content Example: centralize the definition of bold sectioned text type: <!ENTITY %text #PCDATA > <!ENTITY %boldedtext (%text; bold)* > <!ELEMENT text %boldedtext;> 19