Writing is a hard matter.

Whatever the subject, the task, the context and the target, only a small number of human accomplishments are as difficult as the act of writing is.

The advent of word processing has made writing easier from a certain point of view, but we have partially lost the idea of structuring our thoughts and concepts because we are distracted by the way they look.

The tendency of "formatting" documents has taken the place of ordering and arranging the ideas in a well constructed design.

So, first of all, we need to make it clear that formatting is just a visual aid in order to structure documents.

When we write a chapter title, for instance, we tend to use large characters. Larger than sub-titles, obviously.

What we are not used to thinking about is that the dimension of the character is just a visual trick in order to immediately grasp the fact that that title has a higher place in a structural hierarchy where chapter titles describe more general concepts, or fields, or subjects than their sub-titles.

So, when it comes to the art of structuring itself, it doesn't really matter which font we are using and how big the chapter title is. What actually matters is that it is absolutely unambiguous that the text we are writing is a chapter title. And the best way to do it is by writing a label close to that text which says something like: this-is-a-chapter-title^[1].

Well, the xml language does exactly that.

When we write an xml file we write the content and some labels which describe what each block of text means in terms of structure.

In other words, structuring has nothing to do with the presentation (fonts, borders, margins, colors, etc.).

Structuring means arranging ideas and concepts in a meaningful way using a specific hierarchy, and setting the role of each piece of information, related to the rest of the document.

On the other hand, the art of presentation has to do with how we decide to render that structural design, what kind of look and feel it should have. So the art of presentation has to do with margins, borders, fonts, alignments, colors, etc. What a professional has to keep in mind is that whatever the presentation, it doesn't change the structural design.

So when we talk about a document we need to make it clear whether we are talking about its structural design or its presentation design, otherwise known as layout.

Here are some examples of structural parts of a document:

The comprehensive design of a document is made of a texture of all these fragments in a specific order.

Well, once we have stated that using xml means to structure a document, we need to become somewhat familiar with the xml language itself.

This is a piece of xml:

					<fruit>
						<item>banana</item>
						<item>orange</item>
						<item>apple</item>
					</fruit>
				

You can see that the information is self-descriptive. And this is a general feature of xml.

But what we need to highlight here is the syntax we have used.

First of all, tags must be opened and closed. The tag fruit is opened, then the item elements are added, then it is closed. We can say that it contains the items elements.

Each item tag has to be closed as well. And each item contains some text.

Technically speaking, the tag fruit is parent of the tags item and the tags item are children of the tag fruit

Another important term in the xml language is element.

An element is a tag plus what it contains. So, the element fruit is made by both its opening tag, its children and the closed tag.

There are three item elements. Each is made by the opening tag, the text it contains and the closing tag.

By the way, the text inside a tag is a child of the tag.

So you have learned the most important concepts of the xml language: tags and elements, parents and children.

But what about the publishing contents? What kind of xml tags we have to use?

Fortunately, we do not have to re-invent the wheel because almost every possible structural element has already been precisely pre-defined by two very effective standards: the DITA and the DocBook.

This document is about how to use the DocBook standard in order to structure our documents and it is about how to transform these docbook files into specific formats and layouts.

The enormous advantage of structuring a document with DocBook is the fact that a DocBook document can be easily and almost automatically converted into whatever rendered format: pdf, ebook, html pages, or even into an indesign layout.

We have already said this: the magic is made possible by xml technology.

A DocBook document is, in fact, an xml document where each piece of content has a label attached which describe what this content is about and which is its place in the overal hierarchy.

But, before hearing your complaints I must say that in order to write a good DocBook document you don't need to become an xml geek.

It is another fortunate circumstance that a lot of DocBook editors assist us in preparing well formed DocBook documents, almost as easily as using a word processor.

The only significant, extremely significant, difference between a word processor and an xml editor is that the word processor isn't concerned with the structure of the text. You can do whatever you want and nobody complains. With Docbook, instead, you MUST follow the xml rules (well-formedness) and you MUST follow the Docbook rules (validation).

These are the final couple of xml concepts you need to keep in mind: when you write an xml document you need to make it well formed, which means that it has to comply with the xml syntax. In any case, the editor will do this job for you. You don't need to write a single xml tag. Secondly, you need to make the document valid as a Docbook document. This means that you must use only the docbook tags. When you make a mistake, the editor will complain until yo fix it. Fortunately, the editor will suggest how to do that.

Now we need to become familiar with the most important Docbook tags because they are the core of the Docbook philosophy. Each tag has a specific structural meaning and there are a lot of them. Fortunately you don't need to use all the tags, you will probably use just 20% of the Docbook tags in your entire copy editor career. I'll describe the most important tags in the next chapter.

The tag <book>

is the root tag, i.e. it includes everything.

The tag doesn't need to be explicitly inserted because the editor does it for you.

The tag <part>

is a division of the book. You can insert this tag using your Docbook editor of choice. The part tag is optional.

In order to specify the number of the part, you need to insert the root="number-of-part" attribute

The tag

<chapter>

represents the chapter and has a title.

Sections are sub-divisions of a chapter. There are two ways of inserting sections. The first one is using the pre defined section tags:

<sect1>, <sect2>, <sect3>, <sect4>

These represent four levels of sections. Remember that a lower sect must be included into a higher one. For instance, you cannot type a sect2 without a sect1 which comprises it.

The other way is using the generic tag:

<section>

This kind of section has no predefined level. They can be nested indefinitely.

Blocks are discreet pieces of content like paragraphs, sidebars, lists, images, tables, examples, etc.

Here is a list of some blocks:

Inline elements are letters, numbers, words or phrases inside a block which have special meanings. The most frequently used are: <emphasis role="italic">, <emphasis role="bold">, and <footnote>