See what "DTD" is in other dictionaries. Element Type Declaration

In this example, for the element article three attributes are defined: id, about And type, which have types ID(identifier), CDATA and a list of possible values, respectively. There are a total of six possible attribute value types:

• CDATA- the contents of the document can be any character data
• ID- defines a unique identifier of an element in a document
• IDREF(IDREFS) - indicates that the attribute value should be the name (or several such names, separated by spaces in the second case) of the unique identifier of the element defined in this document
• ENTITY(ENTITIES) - the attribute value must be a title (or a list of titles, if used ENTITIES) component (macro definition) defined in the document
• NMTOKEN (NMTOKENS) - the content of the element can only be one single word (i.e. this parameter is a limited option CDATA)
• List of valid values ​​- defines a list of values ​​that this attribute can have.

You can also use the following parameters in an attribute definition:

• #REQUIRED- defines a required attribute that must be set in all elements of this type
• #IMPLIED- the attribute is optional
• #FIXED“value” - indicates that the attribute must have only the specified value, however, the attribute definition itself is not mandatory, but during the parsing process its value will in any case be passed to the analyzer program
• Value - sets the default value of the attribute

Defining Components (Macro Definitions)

Component (entity) represents definitions whose contents can be reused in a document. In other programming languages, similar elements are called macrodefinitions. Are being created DTD- components using instructions !ENTITY:

Analyzer program, looking first at the contents of the area DTD- definitions, will process this instruction and will use the contents during further parsing of the document DTD- the component in the place where its name will appear. Those. Now in the document we can use the expression &hello; , which will be replaced with the line " We are happy to greet you"

In general, inside DTD You can define three types of macro definitions:

Internal macro definitions - are designed to define a string constant; with their help, you can organize links to frequently changed information, making the document more readable. Internal components are included in a document using an ampersand &

IN XML There are five predefined internal symbolic constants:

• < - symbol "<"
• > - symbol ">"
• & - symbol "&"
• " - apostrophe symbol """
• " - double quote character """

External macro definitions - point to the contents of an external file, and this content can be either text or binary data. In the first case, text strings will be inserted where the macro is used, in the second - binary data that is not considered by the analyzer and is used by external programs

Rule Macro Definitions - parameter macro definitions can only be used within the DTD area and are indicated by a special symbol % , inserted before the macro name. In this case, the contents of the component will be placed directly in the text DTD- rules

For example, for the following document fragment:

You can use a shorter form:

Macros are often used to describe parameters in attribute rules. In this case, it becomes possible to use the same attribute definitions for different elements:

Data typing

Quite often when creating XML- the element developer needs to determine what type of data can be used as its content. Those. if we define an element10.10.98 , then we want to be sure that in the document at this place there will be a string representing a date, and not a number or an arbitrary sequence of characters. Using data typing, you can create elements whose values ​​can be used, for example, as parameters SQL- requests. In this case, the client program must know what data type the current value of the element belongs to and, if it matches, generates SQL-request.

If a verifier is used as a client-side program XML-processor, then information about the type can be transmitted using an element specially created for this attribute that has the corresponding DTD- definition. During the parsing process, the parser will pass the value of this attribute to the client application, which can use this information as expected. For example, to specify that the content of an element should be a long integer, you could use the following DTD- definition:

By setting the attribute to its default value LONG and defining it as FIXED, we have thereby allowed the client program to obtain the necessary information about the content type of this element, and now it can independently determine whether the content type matches the one specified in DTD- definition.

Here's an example XML- a document in which several elements with different data types are defined and used:

As can be seen from the example, the mechanism for creating document elements has not changed at all. All the information necessary to check data types is included in the definitions of the elements inside the block DTD.

In conclusion, I would like to note that DTD provides us with a very convenient mechanism for monitoring the contents of the document. Today, almost all Internet document viewing programs use DTD-rules. However, this is far from the only way to check the correctness of a document. Currently in W3 The consortium is considering a new standard for a language for describing the structure of documents, called data schemas. The next section is devoted to working with them.

This is the next article in the series “XML Basics” and in it we will look at the basics of describing the structure of XML data using DTDs. This is a fairly old way of describing the structure of XML documents, but it is still used, so we will still look at it.

I would also like to point out that this is a great way to show how XML checks document content, grammar, etc. We will look at a newer and more advanced way of describing the structure of XML documents using XML Schema technology in the next article, but for now let’s move on directly to studying the XML DTD.

In this article we will look at several important points at once. This is what an XML DTD is and what it is needed for, let's talk about the disadvantages of DTD, and also learn how to independently compose your own DTD for validating XML documents. All this, as usual, will be presented step by step, as briefly and clearly as possible in order to save your time.

So, let's begin.

What is a DTD in XML and why is it needed?

In short, a DTD in XML is used to check the grammar of a document and its conformance to a standard (one that the developer or you came up with). This allows the parser (processor) to determine at the processing stage whether the document meets our requirements. That is, the XML document is validated.

The need to check the grammar of XML documents is as follows:

• The XML document may not be intended for your system.
• The XML document may contain incorrect data.
• The XML document may contain errors in the structure ().

So, we figured out what an XML DTD is and why it is needed. Now let's briefly look at the disadvantages of DTDs, and then move on to the process of creating DTD files for validating XML documents.

Disadvantages of XML DTD

• Language syntax different from XML. This causes many problems, such as encoding problems or the inability to track errors.
• No data type checking. There is only one type in DTD - string.
• There is no DTD. You cannot match two or more DTD descriptions to a document.

This was a short list of DTD shortcomings that have been successfully corrected in XML schemas, which we will talk about in future articles.

Declaring elements, attributes and entities in a DTD. Modifiers “*”, “?”, “+”

Special declarations and modifiers are used to declare elements, attributes, and entities in a DTD. To understand everything in detail, let's first look at the theoretical information, and then in the second part of the article we will move on to practical examples.

Defining an XML Element and a Sequence of XML Elements

The book element contains one title, author, price, and description elements.

Element Alternatives

The pricelist element contains the elements title, price and one of three elements to choose from – author, company or sample.

Empty elements

The none element must be empty.

Attribute Declaration

The pricelist element can contain two attributes - an id attribute and a name attribute. In this case, the id attribute is required, since #REQUIRED is specified, and the name attribute is optional (#IMPLIED is specified). In turn, CDATA indicates to the handler that there is no need to parse the contents of the attributes.

Defining Entities

If the entity “” is encountered, then “Dmitry Denisov” will be automatically substituted instead.

Modifiers (explain repetitions of elements)

* - zero or many.
? – zero or one.
+ - one or many.

The books element can contain one or more book elements.

Now let's look at what this all looks like with more practical examples.

Creating a DTD file for validating an XML document using the example of a book price list

Let us have the same price list of books that we use for examples in almost every article about XML. The XML document itself will look something like this.

&myname; Price 1 Description

Of course, the above example is not the ultimate dream, but it will do as an example. As you can see from the example, we have a root element pricelist, which contains nested book elements. Inside the book elements there are title, author, price and possibly description elements, which may contain some text data.

To validate this price list, we can use the following DTD document.

Now let's look at everything in more detail.

• — we declare the root element books and indicate in parentheses what it can contain. In this case, it can contain one or more book elements (the plus sign means one or more, see above).
• — define the book element. The book element can contain one title element, one or more author elements (plus sign), one price element, and one or no description elements (question mark).
• — define the title element. We specify #PCDATA as the content of the element. This means that the parser is required to parse what is inside this element.
• Similarly, we define the elements author, price, description.
• — we define the essence. First we write the entity itself, and then in quotes what will be displayed in its place. By default, only 3 entities are defined in XML. This is more (">" -<), меньше («<» — >) and ampersand (“&” - &). If you wish, you can create an unlimited number of entities using this method. The meanings can be not only words, but also entire sentences of significant length.

Connecting DTD for validating XML documents

Declarative method

This method is very rarely used, since its essence is to create self-sufficient documents. That is, the document will immediately contain both DTD and XML. The following construct is used to add a DTD to XML.

where instead of DOCUMENT we indicate the root element of the XML document.

For clarity, let's look at an example of a ready-made self-sufficient document with a declarative way to include a DTD.

]>

External DTD definition - connecting a DTD document

The essence of this method is to connect a DTD file to an XML document using the following construction.

where DOCUMENT – we indicate the root element of the XML document.
file.dtd – link to the DTD file.

For clarity, consider the following example.

XML document

This concludes this article. We looked at all the main points when working with XML DTD and, I hope, I was able to explain everything clearly. If you don't want to miss other XML and XSLT tutorials, I recommend subscribing to the newsletter using the form below.

That's all. Good luck and success in learning XML!

Use XML Schemas instead of DTDs to define the structure of XML documents

XML Schema is more powerful than DTD. To illustrate the benefits of using the XML Schema engine, the first three listings compare different ways of representing elements. The following is an excerpt from the XML document. B shows the two elements declared in DTD syntax, and B shows the syntax corresponding to the XML schema. Note that the syntax in Listing 3 is similar to XML syntax. When using a schema, the validating parser can check whether the InvoiceNo element is a positive integer, and whether the ProductID consists of a given set of characters (six numbers and one letter from A to Z). The parser processing the DTD definition can only confirm that the given elements are strings.

Listing 1: XML document fragment

Listing 2: DTD fragment describing the elements from Listing 1

Listing 3: XML Schema fragment describing the elements from Listing 1

Using Namespaces in XML Schema

DTD Limitations

Although DTDs have served SGML and HTML developers as a mechanism for describing structured information for 20 years, DTDs have some limitations compared to XML schemas.

According to the DTD, an element can be represented in one of three ways:

• Text string
• Text string mixed with another child element
• Set of children

DTDs do not have XML syntax and offer only limited support for types and namespaces.

When working together, one party may process the other parties' documents, and different parties may represent their data elements differently. Moreover, in a separate document, they may need to independently reference elements with the same name created by different parties. Using XML Schema allows definitions with the same name to be differentiated by defining different namespaces.

Such an XML schema defines a set of new names, such as the names of elements, types, attributes, and attribute groups, whose definitions and declarations are described in the schema. The names are defined as InvoiceNo , ProductID and ProductCode .

The names defined in the schema belong to the so-called target namespace. The namespace itself is a fixed, arbitrary name that must follow URL syntax. For example, the namespace for the schema presented in , can be set as follows: http://www.SampleStore.com/Account.

The syntax for declaring a namespace can sometimes be confusing. The declaration starts with http:// , but it does not link to the schema file. In fact, the link http://www.SampleStore.com/Account does not lead to any file at all, but only to the assigned name.

Definitions and declarations in a schema can refer to names that may belong to other namespaces. In this article we refer to such namespaces as: original namespaces. Each schema can define one target namespace and possibly multiple source namespaces. In general, each name in a given schema belongs to a certain namespace. Namespace names can be quite long, but they can be shortened using the xmlns declaration syntax in the XML schema document. All these concepts are illustrated in.

Listing 4: Destination and source namespaces

In the XML schema represented with , the targetNamespace namespace is http://www.SampleStore.com/Account and contains the names InvoiceNo , ProductID , and ProductCode . The names schema , element , simpleType , pattern , string , and positive-integer belong to the original namespace http://www.w3.org/1999/XMLSchema , which is abbreviated as xsd by declaring xmlns . There is nothing special about the xsd alias; you can choose another name. For convenience and simplicity, in the remainder of the article we will use the xsd prefix to refer to the http://www.w3.org/1999/XMLSchema namespace, omitting the xsd qualification in some parts of the code. In our example, targetNamespace is also one of the original namespaces, since the ProductCode name is used in the definition of other names.

Figure 1: Namespaces for Listing 4

Listing 5: Multiple source namespaces, namespace import

Defining Elements

Defining an element consists of defining its name and content model. In an XML schema, an element's content model is determined by its type. Therefore, elements in an XML document can only have values ​​that match the types defined in its schema.

Simple types

The XML Schema specification defines several simple types for values, as shown in Table 2—predefined simple value types.

The element type can be simple or complex (complex). Element simple type cannot contain other elements or attributes. A complex type can have the effect of embedding elements within other elements, or can associate attributes with an element. Up to this point, we have only used examples with simple user-defined types (see ProductCode). The XML Schema specification also includes predefined simple types (see box). Predefined simple type Restricts values ​​to their underlying type. For example, the value of the predefined simple type ProductCode is a subset of the values basic type string .

Simple, non-nested elements have a simple type

An element that contains no attributes or other elements may be assigned a simple type, predefined or user-defined, such as string, integer, decimal, time, ProductCode, etc.

Listing 7: Some simple element types

Elements with attributes must be of complex type

Now let's try to add to simple element price from the currency attribute. You won't be able to do this because an element of a simple type cannot have attributes. If you want to add an attribute, you need to define price as an element of complex type. In the example from , we define the so-called anonymous type, in which the complex type is not given an explicit name. In other words, the name attribute of the complexType element is undefined.

Listing 8: Complex type element

Elements containing nested elements must be of complex type

In an XML document, other elements can be nested within an element. This requirement is expressed directly in the DTD. An XML schema instead defines an element and its type, which can include declarations of other elements and attributes. An example is given in.

Table 1: Comparison of complex data types in DTD and XML Schema

XML document