АнатолийБелайчук bell@b-k.ru МарияНиколаева mmm@b-k.ru НадеждаМатвеева matveeva@b-k.ru СтаниславФридкин stas@b-k.ru 2005 ООО Бизнес-Консоль, www.b-k.ru Технология DocBook существует с 1991 года и к сегодняшнему дню принята на вооружение многими лидерами ИТ-отрасли. Достоинства этой основанной на XML технологии — независимость от конкретного поставщика, открытость для расширений, отделение контента от дизайна и, не в последнюю очередь, свободно распространяемый инструментарий. Особый интерес DocBook представляет для организаций, стремящихся к систематическому документированию своей деятельности. Наблюдательный посетитель Internet может обнаружить в Сети множество документов с однотипной навигацией между страницами при помощи ссылок Prev, Next, Up, Top, причем один и тот же документ может предлагаться в нескольких форматах: каскадный HTML, единый HTML, PDF.

Возникает подозрение, что документы в разных форматах генерируются автоматически из одного источника. Из какого? Чтобы это узнать, заглянем в код HTML: ]]> Свидетельство того, что HTML-страница сгенерирована XSL-скриптами DocBook. Копнув еще глубже, обнаруживаем, что DocBook используют многие авторитетные компании: Sun Microsystems Hewlett-Packard RedHat O'Reilly & Associates World Wide Web Consortium (W3C) OASIS На DocBook написана документация на Linux (www.tldp.org), FreeBSD (www.freebsd.org), Sun Solaris (docs.sun.com), PHP (www.php.net).

Чем же так привлекательна эта технология? В самом деле, ведь существует множество программ для подготовки текстов (начиная с Microsoft Word), настольных издательских систем (например Xerox Ventura Publisher, Adobe PageMaker) и языков разметки (unix nroff/troff, TeX/LaTeX, тот же HTML). Преимущества над всеми этими средствами DocBook унаследовал от XML: простой HTML-подобный язык разметки "идеологическая выдержанность" — четкое разделение контента и верстки, чего нет в HTML мощный набор стандартов и поддерживающих их инструментов, позволяющих обрабатывать тексты: XSLT, XSL-FO, XPath независимость от коммерческих производителей, наличие свободно распространяемого инструментария открытость к расширениям Первоначально DocBook разрабатывался как приложение SGML (Standard Generalized Markup Language) и обрабатывался при помощи DSSSL (Document-Style Semantics and Specification Language). Но в дальнейшем DocBook стал эволюционировать в направлении XML, а для обработки стал использоваться XSLT (Extensible Stylesheet Language for Transformations). И хотя SGML-версия DocBook продолжает использоваться в существующих проектах, если вы собираетесь начать работать с DocBook, то мы рекомендуем ориентироваться только на XML/XSLT-версию. Разработка DSSSL и XSLT скриптов, предназначенных для работы с DocBook, ведется в рамках Open Source проекта: docbook.sourceforge.net. XML в каком-то смысле является преемником HTML, поэтому несколько слов о преимуществах и недостатках последнего. Роль HTML как основного носителя информации в Internet невозможно переоценить. Этот язык разметки оказался невероятно удачным (именно "оказался", ведь никто, включая его автора, и близко не представлял, каким успехом он будет пользоваться). Язык оказался простым, удобным, выразительным и технологичным. Миллионы людей получили возможность поделиться своими знаниями, опубликовав их в виде HTML-страничек, и они этой возможностью воспользовались. Но "вольность" HTML, соответствующая анархическому духу Internet, в корпоративной среде становится недостатком: HTML-документы плохо поддаются унификации. Технически это связано с тем, что в HTML присутствуют как структурные тэги (например <h1>, <p>, <ul>, <kbd>), так и оформительские (например <font>, <u>, <b>). В результате каждый автор волен "раскрасить" документ так как ему нравится, что усложняет создание корпоративных библиотек. (Сущий кошмар в этом смысле представляют документы, экспортированные в формат HTML из Word.) Конечно, можно в приказном порядке обязать авторов пользоваться только ограниченным наборов набором структурных тэгов, но лучше, чтобы это ограничение срабатывало на уровне языка разметки, а не на дисциплинарном. Кроме того, HTML недостаточно четко формализован. Конечно, есть официальные стандарты W3C, но в реальности и браузеры, и Web-мастера широко используют нестандартные конструкции. Это затрудняет автоматизированную обработку HTML-документов, без которой нельзя обойтись, когда речь идет о корпоративной среде. XML и DocBook — это достоинства HTML без его недостатков: В DocBook присутствуют только структурные тэги. Их много (около 400), но ходовых всего пара десятков: <para> вместо <p>, <emphasis> вместо <em>, <chapter> вместо <h2>, <listitem> вместо <li> и т.д. Формат документа жестко выдерживается: например, каждому открывающемуся тэгу <para> обязан соответствовать закрывающий </para>. В противном случае ни одна программа такой документ обрабатывать не будет. Имея на входе четко структурированный документ, приспособленный к автоматизированной обработке, получение выходного документа, оформленного в корпоративном стиле, в формате HTML, PDF, WinHelp или другом, становится делом техники. При том что уже есть большая часть инструментария — стандартные XSL-процессоры. Например, вот как выглядит исходный текст DocBook этой статьи (полный исходный текст):

... Технология DocBook существует с 1991 года ...

Чем же так привлекательна эта технология и кому она может быть полезна? ...

]]> Несложно и интуитивно понятно. По крайней мере, для человека, когда-либо имевшего дело с HTML. Обратите только внимание на следующее: Документ должен начинаться с XML-декларации, как в приведенном примере (кодировка, естественно, может быть другой, например koi8-r). Все открытые тэги должны аккуратно, с соблюдением вложенности, закрываться. Атрибуты внутри тэгов, даже числовые, должны ставиться в кавычках (одинарных или двойных), как lang="ru" в приведенном примере. Если в вашем тексте встречается символ <, то замените его на &lt;, а символ & на &amp;. Остальные мнемоники HTML, в частности &nbsp; (явный пробел) XML по умолчанию не понимает. Используйте числовой код, например &#160; вместо &nbsp;. Корневой тэг <article>, использованный в рассмотренном примере, в DocBook предназначен для относительно небольших и самостоятельных статей. Традиционному жанру технической литературы — "Руководству" — соответствует тэг <book>, а для многотомной библиотеке имеется <set>. Для того, чтобы научиться оформлять нумерованные списки, таблицы, картинки и т.д. вам понадобится справочник по тэгам DocBook. Тэги DocBook стандартизованы на уровне спецификаций, выпускаемых комитетом при консорциуме OASIS (Organization for the Advancement of Structured Information Standards, www.oasis-open.org), в который входят, в частности, представители Hewlett-Packard, IBM и Sun Microsystems. Возглавляет его Норман Уолш (Norman Walsh) — человек, который является автором большей части DocBook. По состоянию на март 2005 года последней официальной версией спецификации является версия 4.2, датированная июлем 2002г. Номер последней рабочей версии — 4.4. Эти версии существуют в виде XML и SGML. В версии 5.0 планируется переход к единой схеме, совместимой как с SGML, так и с XML. Материальное воплощение DocBook — это XML-схемы (DTD) и скрипты (DSSSL, XSLT). Они распространяются свободно: их разрешается использовать с любыми целями, модифицировать и тиражировать без ограничений и специального разрешения. Единственное, что запрещается в соответствии с духом Open Source — это ограничить других в свободном использовании и распространении DocBook или его модификаций. Стандартом в популярном изложении служит Definitive Guide Нормана Уолша. На том же сайте docbook.org находится Simplified DocBook, в котором произведена селекция: исходные примерно четыреста тэгов сведены к порядка ста наиболее употребительных (скорее всего и это много больше, чем вам реально понадобится). Для настройки XSLT-инструментария и параметров, влияющих на вид выходных документов, вам понадобится руководство DocBook XSL: The Complete Guide и справочник DocBook XSL Stylesheet Reference Documentation.

DocBook уже достиг той степени зрелости, что им можно начать пользоваться, не тратя ни денег на покупку ПО, ни времени на его настройку. По крайней мере, если на первых порах вы согласны ограничиться HTML в качестве формата выходных документов. Причем это относится и к документам на русском языке. Для работы с DocBook вам понадобятся: редактор для набивки исходного текста конверторы для преобразования исходного текста в выходные форматы Для ввода исходного текста подойдет обычный текстовой редактор. Если он умеет работать с XML — отлично: это обеспечит вам дополнительный сервис, например он будет "на лету" обнаруживать ошибки разметки. Максимум комфорта даст специализированный XML-инструментарий. Например, в меню продукта Altova Authentic слово DocBook присутствует в явном виде. К тому же, Desktop Edition этого продукта является бесплатным. Проблема только в том, что вам врядли удастся найти русифицированный XML-редактор. И поэтому для пользователей, не владеющих английским, обычный текстовой редактор, но с русским интерфейсом, скорее всего окажется удобнее. Сохраните текст в файле с расширением .xml. Если ваш редактор не проверяет корректность XML-документа, то самый простой способ проверить — открыть его при помощи Internet Explorer. Если все в порядке, IE отобразит ваш документ в виде структурного дерева, в котором можно сворачивать и разворачивать отдельные ветки, соответствующие разделам документа. Конверторы — это, в первую очередь, XSLT-процессор и скрипты. И то, и другое вы получите в составе дистрибутива практически любой более-менее современной версии Linux. Скрипты постоянно развиваются: например, в версии 1.68 исправлены огрехи в предметном указателе на русском языке, поэтому их стоит сразу обновить, загрузив последнюю версию и развернув архив на сервере. XSLT-процессор для Windows можно скачать, например, по ссылке Windows binaries с сайта xmlsoft.org, а XSL-скрипты от платформы не зависят. На unix преобразование исходного документа в формат HTML выполняется следующей командой: $ xsltproc /usr/docbook/xsl-stylesheets/html/chunk.xsl article.xml где вызываемая программа, XSLT-процессор (один из нескольких возможных) директория на вашем сервере, куда вы положили XSLT-скрипты, и вариант генерации выходного документа, конкретно в виде каскадного HTML исходный документ DocBook Готово! В текущем каталоге должны появится HTML-файлы, по одному на раздел статьи и один на общее оглавление.

Первый, самый простой уровень настройки — это выбор стартового скрипта. В приведенном ранее примере таковым является html/chunk.xsl. Он наиболее употребительный, но не единственный. Другие варианты: html/docbook.xsl — устаревший вариант, html/chunk.xsl его заменяет html/onechunk.xsl — генерация единого HTML для всего документа htmlhelp/htmlhelp.xsl — генерация HTML Help manpages/docbook.xsl — генерация man pages (формат традиционной документации в unix/linux) fo/docbook.xsl — генерация XSL-FO для последующего преобразования в PDF и другие ориентированные на печать форматы Более широкие возможности для управления внешним видом выходного документа предоставляют параметры, которых только для chunk.xsl насчитывается более 200. Пример: заставим выделять в отдельный файл первый раздел документации и зададим кодировку выходного документа windows-1251 вместо UTF-8, принятой по умолчанию: $ xsltproc --param chunk.first.sections 1 \ > --stringparam chunker.output.encoding windows-1251 \ > /usr/docbook/xsl-stylesheets/html/chunk.xsl article.xml Для реальной работы захочется задать как минимум десяток параметров, однако делать это через командную строку неудобно. Значит, пора создать так называемый "XSL драйвер". Создайте в текущей директории файл с именем mydocbook.xsl и следующим содержимым: ]]> Подайте его на вход XSLT процессору: $ xsltproc mydocbook.xsl article.xml Теперь вы вольны экспериментировать: задавать файл стилей CSS, управлять автоматической нумерацией, размещением оглавлений и многим другим. Все вопросы применения и настройки XSLT великолепно изложены в книге DocBook XSL: The Complete Guide, а актуальный перечень параметров содержится в справочнике DocBook XSL Stylesheet Reference Documentation. В результате манипуляций с параметрами вы добьетесь того, что сгенерированные HTML-страницы будут полностью удовлетворять вашим представлениям об эстетике и эргономике или просто соответствовать принятому корпоративному стилю:

Максимальной гибкости в использовании XSL-скриптов можно достичь, если подменять не только значения параметров, но и код, используемый для обработки тех или иных тэгов. Например, если вас не устраивает то, как отрабатывается тот или иной шаблон, вы просто копируете его из файла в каталоге /usr/docbook/xsl-stylesheets в свой драйвер и правите его так, как считаете нужным. Шаблоны, которые вы напишете, перекроют импортируемые. Похожим способом можно не только менять обработку существующих тэгов, но и вводить свои собственные. Искушенный читатель мог заметить, что в примере исходного файла мы опустили DTD-декларацию, т.е. не связали наш документ с XML-схемой DocBook. Это было сделано не случайно. Прежде всего заметим, что XSLT процессор указания DTD не требует. Естественно, при этом возможна ситуация, когда ваш документ будет правильным XML, но не будет соответствовать схеме DocBook. Например, в нем будут придуманные вами тэги. XSL-скрипты в такой ситуации ведут себя очень разумно: содержащийся внутри таких тэгов текст попадет в выходной документ, при этом он будет выделен красным цветом. Теперь вам осталось написать свой обработчик (xsl:template) для изобретенного вами тэга и вставить его в драйвер mydocbook.xsl. (Еще лучше — поместить обработчик в отдельный файл и включить его в драйвер командой xsl:import.) Вот в такой свободе и раскрывается преимущество открытых технологий над закрытыми коммерческими решениями.

Преобразование из DocBook в HTML в стандартных XSL-скриптах отработано практически идеально. Нет проблем также с генерацией в Windows HTML Help. Скрипт htmlhelp/htmlhelp.xsl создает набор файлов HTML и необходимые служебные файлы. После этого запускаете help-компилятор hhc.exe, который компания Microsoft распространяет свободно, и получаете HTML Help. Но в том, что касается генерации PDF, проблемы, увы, есть. И если для документов на английском языке получить выходной документ приемлемого качества довольно просто, то добиться того же для документа на русском — занятие не для слабонервных. Сначала немного теории. PDF из DocBook получают в два этапа: сначала DocBook преобразуют в промежуточный формат — такой, для которого уже есть готовая программа преобразования в PDF. Таких промежуточных форматов два: XSL-FO и TeX. Стандартные xsl-скрипты поддерживают преобразование в XSL-FO, но дальше начинаются проблемы. Хорошо известны два свободно распространяемых транслятора из XSL-FO в PDF: PassiveTeX и Apache FOP (xml.apache.org/fop). Первый никогда не рассматривался его автором в качестве серьезного продукта, второй выглядит посолиднее, все-таки Apache Foundation — это марка. Но увы, последняя версия FOP 0.20.5 была выпущена еще в июле 2003г. После этого разработчиками было заявлено о намерении выпустить версию 1.0, полностью переписав код, но по состоянию на начало 2005г. никаких прогнозов по поводу сроков дать невозможно. Из коммерческих FOP-процессоров, пожалуй, лучшим на сегодняшний день является продукт XEP от компании RenderX ценой около 300 долл. Это зрелый продукт и проблем с русским языком у него нет, благо вся команда разработчиков русскоязычная. К сожалению, "из коробки" кириллические шрифты в нем не работают и нет инструкции, которая толково объясняла бы как их включить. Но разобраться можно, и после того как кириллические шрифты подключены, все работает гладко. Работают даже переносы для русского текста. Вторая альтернатива — промежуточное преобразование в LaTeX. Стандартные XSL-скрипты его не поддерживают, но есть, например, db2latex — также пакет XSL-скриптов, который можно заставить делать то, что нужно. "Из коробки" он с русскими буквами тоже не работает — как минимум, в XSLT-драйвере надо прописать следующее: utf8 pscyr ]]> Сгенерированный документ в формате LaTeX можно преобразовать в PDF командой pdflatex, также штатно имеющейся в Linux. После этого русский текст появляется, но до удовлетворительного результата еще далеко: остаются огрехи в графике, в выравнивании текста, в закладках PDF и т.п. Нас пакет db2latex не устроил еще и тем, что в нем не поддерживается атрибут morerows, т.е. в таблицах невозможно объединять ячейки по вертикали. К тому же стало ясно, что для доведения этого варианта до ума не обойтись без глубокого изучения TeX/LaTeX, а это в наши планы не входило. Не в последнюю очередь источником проблем PDF является компания Adobe. Трудности с поддержкой русского языка возникают чуть ли не во всех ее продуктах: и в Photoshop, и во FrameMaker, и в Acrobat. (Видимо среди программистов в Adobe не оказалось выходцев из бывшего СССР.) Вот что официально пишет компания по поводу Adobe Acrobat версии 6: при создании PDF из HTML файлов текст, набранный кириллическими шрифтами, заменяется неправильными символами или пустотами. Иными словами, не работает — и не должно! Самый простой и надежно работающий вариант генерации PDF на русском — это Adobe Acrobat Distiller. Немаловажно то, что он включает шрифты в создаваемый документ, что гарантирует его прочтение на любом компьютере, а не только на том, что оснащен русской версией Windows. Поступаем следующим образом: штатными средствами (onechunk.xsl) создаем единый HTML; настраиваем CSS так, чтобы документ хорошо смотрелся в печатном варианте; отправляем его в Acrobat Distiller и получаем на выходе PDF. Недостатки этого варианта: в результирующем PDF нет ссылок и закладок, т.е. это не гипертекстовый документ, а предназначенный в основном для печати; в оглавлении нет номеров страниц. Преимуществом же является то, что при помощи CSS можно точно подобрать шрифты, отступы, отбивки, расположение картинок и тем самым добиться индивидуального дизайна ваших документов. На пути XSL-FO этой цели добиться сложнее — потребуется глубокая адаптация XSL-скриптов. Еще одно применение DocBook — создание интернет-сайтов. Идея заключается в следующем: пользуясь тэгами DocBook, вы создаете по одному XML-файлу на каждую страницу сайта (корневой тэг <website>) плюс один XML-файл, содержащий оглавление. Затем обрабатываете эти файлы при помощи XSL-скриптов (docbook.sourceforge.net/release/website) и получаете на выходе набор HTML-страниц, составляющих вебсайт. В ходе генерации к каждой странице автоматически подверстывается панель с иерархическим оглавлением сайта, пункты которого можно сворачивать-разворачивать. Также автоматически в оглавлении выделяются новые/измененные страницы. Примечательно, что ссылки между страницами сайта делаются не при помощи привычных <a href=…>, а при помощи тэга docbook <olink>. Это гарантирует, что все внутренние ссылки на результирующем сайте будут корректными. Основное достоинство этой технологии, как и DocBook в целом,— последовательное отделение контента от дизайна. Скажем, сайты www.docbook.org, www.docbook.ru, сделанные по этой технологии, выглядят по-академически строго. Но, воспользовавшись стандартными приемами кастомизации DocBook, вы сможете радикально менять дизайн и верстку своего сайта, абсолютно не затрагивая при этом его контент.

Какими достоинствами обладает DocBook с точки зрения человека, профессионально занимающегося подготовкой технических текстов? Традиционно под документацией в первую очередь понимался напечатанный документ или книга. Но сегодня документация в большинстве случаев требуется и в печатном, и в электронном виде. Если у вас уже есть документ, сверстанный для печати, то самый простой (и универсальный) способ сделать его электронный вариант — воспользоваться Adobe Acrobat Distiller. Вы получите PDF, который можно записать на CD или выложить на сайт. Однако PDF — это эрзац, не родной для Internet формат. Ваши документы не станут органической частью сайта и будут раздражать пользователя длительной загрузкой. К ним не удастся привязать стандартное оформление сайта (шапки, панели, сервисы), в них затруднено использование ссылок и поиск средствами сайта. Еще одно дешевое решение — выполнить экспорт в HTML, например, из Microsoft Word. С точки зрения интеграции с Internet-сайтом этот вариант ненамного лучше PDF — такие документы также будут выбиваться из общего стиля сайта. Формально это, конечно, будет HTML, но по существу — нет, ведь даже сменить шрифт или увеличить размер символов при просмотре в браузере пользователь не сможет, поскольку все жестко прописано в сгенерированном HTML-коде. Концептуально подход DocBook к выпуску документации в нескольких форматах является наиболее грамотным: исходный текст, абсолютно не привязанный к выходному формату, и управляемые параметрами программы генерации выходных документов. Задача генерации HTML-документов решена на отлично, с PDF потребуется больше усилий, но и эта задача решается. Кроме того, техническому писателю необходим сервис: автоматическая нумерация разделов, таблиц, рисунков, автоматическое формирование оглавления, перечня рисунков, алфавитного указателя. Со всеми этими задачами DocBook прекрасно справляется.

Но по-настоящему преимущества DocBook раскрываются в коллективной работе. Представим себе, что над документацией работает команда, включающая: авторов, разбирающихся в сути той или иной области и поставляющих контент редактора или литературного обработчика, который принимает фрагменты будущей документации у авторов, выправляет текст и собирает его в единое целое дизайнера, отвечающего за верстку и художественное оформление документа В такой ситуации остро встает проблема разделения контента и дизайна. Если авторы работают с Word, то их документы содержат и контент (собственно текст), и дизайн (шрифты, оформление абзацев, страниц и т.д.). Поэтому дальше идет трудоемкая ручная работа: редактор собирает фрагменты и приводит верстку в соответствие со стилем, заданным дизайнером (теоретически в этом могли бы помочь собственный механизм стилей Word, но на практике он работает не очень хорошо.) Еще хуже становится дело, когда автору необходимо внести правку в свой фрагмент. Предположим, что программисты доработали продукт, и в документацию надо добавить описание нового параметра. Позволять авторам работать напрямую с выходным документом нельзя — возникнет конфликт совместного доступа. Значит, автор внесет правку в копию, и после этого, опять-таки вручную, редактор должен будет интегрировать ее в главный документ. Накладные расходы становятся непропорционально большими: даже если надо исправить небольшой фрагмент текста, приходится привлекать редактора, который должен выполнить ответственную операцию. В результате общая производительность труда оставляет желать лучшего. Как в этой же ситуации строится работа через DocBook: редактор намечает структуру будущего документа: делит его на главы или более мелкие разделы для каждого раздела редактор создает отдельный файл DocBook, содержащий только название раздела редактор раздает файлы авторам для работы над контентом дизайнер разрабатывает файл CSS, определяя в нем стили для оформления регулярного текста, заголовков, ссылок, таблиц, рисунков и т.д. редактор создает головной файл документа, содержащий ссылки на разделы выходной документ создается из набранных фрагментов автоматически Вот как при этом будет выглядеть начальный файл первого раздела start.xml, который получает автор для работы:

]]> А вот как будет выглядеть головной файл: ]]> ... ]>

... Технология DocBook существует с 1991 года ... &start;]]> ]]> Местоположение файла SGML-схемы (DocBook DTD) на сервере. В SGML-декларации определяются составные части документа. Составные части вставляются в документ. Авторам не обязательно ждать пока соберется общий документ, они вполне могут запускать DocBook на своем фрагменте и смотреть, как он будет выглядеть в отформатированном виде. После такой предварительной отладки редактор может быть уверен, что получил от автора синтаксически правильный документ DocBook. Поскольку весь документ разбит на составные части, которые к тому же являются текстовыми файлами, такая организация работы великолепно ложится на систему контроля версий (например RCS или CVS). Снова вернемся к ситуации, когда в документ надо внести небольшую правку. Последовательность действий при работе с DocBook: Автор достает из системы контроля версий нужный фрагмент документа, правит его, автономно просматривает и помещает исправленный вариант обратно в систему контроля версий. Редактор просматривает новый текст, при необходимости корректирует. Но, в отличие от работы с Word, его заботит только контент. Автоматически генерируется выходной документ. Очень технологично, минимум накладных расходов. Одновременно, не мешая друг другу, над документом может работать большая команда.

Единственное, что нас не устроило в работе с DocBook — это "хвосты" SGML, которые появились в головном файле для организации ссылок на разделы документа. Во-первых, неправильно, что каждый файл должен быть упомянут дважды (один раз в определении, второй в размещении) — там, где дублирование, появляются ошибки. Во вторых, это неадекватный способ для работы со сложными структурами. В рассмотренном примере всего два фрагмента, реальные же документы на программные продукты, например, нашей компании состоят из примерно трехсот при глубине вложенности разделов равной четырем. Возникает естественное желание сделать структуру более наглядной. А как наиболее наглядно можно отразить иерархическую структуру, каковой является документ DocBook? Очевидно, иерархией каталогов. Поэтому мы реализовали следующую схему работы с разветвленными документами DocBook: под раздел любого уровня создается отдельный каталог. Контент раздела помещается в XML-файл, лежащий в этом каталоге, а для вложенных подразделов создаются свои подкаталоги. Сборка фрагментов осуществляется автоматически несложной программой, написанной на unix shell и XSLT. Правильный порядок следования разделов достигается при помощи нестандартного атрибута nr в тэгах <section>. SGML-декларации становятся ненужными. Последнее представляется важным с точки зрения не столько технологической (в конце концов, с дублированием имен разделов можно было бы справиться), сколько концептуальной. Если необходимость разделения контента и дизайна — это более-менее общее место, то мы пошли дальше и добились разделения контента, дизайна и структуры. Что это означает на практике? Абстрагирование вышележащих разделов от нижележащих и возможность легкого изменения структуры. Раздел верхнего уровня "не знает", какие подразделы окажутся в нем в результате эволюции документа: какие подкаталоги будут, те и включатся. А если у редактора возникла идея перенести какой-то подраздел из одной части документа в другую, переместить его выше или ниже по иерархии, то это делается максимально просто: с помощью проводника Windows. Небольшое замечание: в DocBook для маркировки разделов имеются тэги с жестким позиционированием в иерархии: <sect1>, <sect2> — разделы соответственно первого и второго уровня — и рекурсивный тэг <section>. Для того, чтобы можно было манипулировать структурой описанным выше способом, мы используем только <section>.

Стоит ли вашей компании внедрять DocBook? Если речь идет об автоматизации труда одного человека — технического писателя, то, пожалуй, нет: проще продолжать работать по-старинке. Но если компания или организация стремится к прозрачности своих бизнес-процессов, то написание документации становится уделом многих. В основе современных методов контроля качества лежит максима напиши, что делаешь, делай как написал. Это означает, что значительная часть персонала, вплоть до менеджеров нижнего звена и даже рядовых исполнителей, участвует в документировании процессов управления. К тому же, документирование бизнес-процессов — это не то, что можно один раз поручить внешним консультантам и после этого навсегда зафиксировать. Бизнес-процессы постоянно меняются, что должно отражаться в документации. То есть, мы приходим к уже описанной ситуации много авторов — один редактор. Эта же ситуация характерна для ИТ- и консалтинговых компаний, главный актив которых — знания. Где они хранятся, как накапливаются? Худший вариант — в головах сотрудниках, самый распространенный — в файлах Word на персональных компьютерах. Идеальный — в виде текстов, подготовленных в едином стандарте и помещенных в общее хранилище. Именно этого позволяет добиться DocBook. Сложно ли внедрить DocBook? По опыту нашей компании, вовлечь в работу широкий круг исполнителей можно достаточно быстро. Последовательность внедрения: Подготовьте небольшой документ DocBook, относящийся к вашей предметной области, и раздайте его авторам (или опубликуйте на внутреннем сайте) в качестве образца. Для ввода текста на первых порах можно обойтись обычными текстовыми редакторами. Определите местоположение документов и порядок совместной работы. Если у вас нет системы контроля версий, начните просто с сетевого диска. Проинсталлируйте инструментарий XSLT и настройте его так, чтобы получать на выходе документы, оформленные в корпоративном стиле и готовые к публикации на внешнем или внутреннем сайте. Или же подготовленные в соответствии с требованиями заказчика, например с рамками в стиле ГОСТ.

DocBook основан на технологиях XML и, в частности, XSLT. Надо ли бояться, если эти технологии для вас внове? По нашему мнению, XML заслуживает того, чтобы каждой ИТ-компании сформировать по отношению к нему собственную стратегию использования. XML — это не дань моде, хотя и не палочка-выручалочка. Это эффективное решение для широкого круга задач, которые до сих пор плохо поддавались автоматизации. Компьютеры давно уже приспособили к хранению и обработке, с одной стороны,— жестко структурированных и объемных данных, а с другой — слабоструктурированной информации, такой как текстовые документы. Сила же XML заключается в том, что он позволяет эффективно организовывать и обрабатывать (при помощи XSLT) квазиструктурированную информацию, лежащую между этими полюсами. Примеры такой полуструктурированной информации в деятельности IT-компании: спецификации и API требования заказчика и сценарии использования (use cases) тестовые данные и сценарии часто задаваемые вопросы учебные курсы с лекциями, примерами и тестами Для такой информации характерна коллекция объектов с одинаковой структурой верхнего уровня и текстовыми описаниями на нижних уровнях. В отличие от представления такой информации в виде текста, XML позволяет отразить ее структуру. С другой стороны, по сравнению с базами данных XML обладает гораздо большей гибкостью, при том что объемы информации здесь невелики и мощь СУБД не требуется. Существует множество примеров успешного использования DocBook в подобных задачах. Например, учебная лекция может быть представлена в виде одного XML-файла, из которого автоматически формируются слайды для лекции раздаточные материалы тестовые данные для лабораторной работы экзаменационные задачи, вопросы и тесты DocBook умеет формировать выходные документы не только в различных форматах, но и с различным содержанием — например, в зависимости от читателя (лектор/студент, заказчик/исполнитель). В DocBook такая возможность называется profiling, и в приведенном примере с учебной лекцией она оказывается очень кстати. Таким образом, для технологически продвинутых компаний DocBook станет органическим дополнением уже используемых XML-приложений, а для остальных — технологическим заделом, который будет способствовать внедрению XML.