Иногда начинаешь писать что-то серьёзное и по делу, хочешь рассказать про замечательный полезный инструмент — и вдруг в этот процесс вмешивается кот собственной персоной, и ты уже пишешь несколько другую статью. Так и вышло — хотел написать большую обзорную статью про технологию DITA, но в примерах получилось шуточное руководство о том, как правильно «воспитывать» и понимать своего кота.

Для меня DITA — это одна из тех вещей, которые настолько удобны, что их даже не замечаешь в процессе повседневного использования. Вспомните свои ощущения, когда обстоятельства заставили вас сменить удобный привычный инструмент на другой, неудобный и неэргономичный. Неважно, что это будет — клавиатура, телефон, отвёртка, мягкие икеевские тапочки или операционная система. Те действия, которые раньше выполнялись как будто сами собой, теперь требуют дополнительных усилий, всё кажется неудобным и неправильным. Примерно такие чувства я испытываю, когда приходится временно переключиться с DITA, например, на Word. К хорошему очень быстро привыкаешь.

Открываем коробку с конструктором

DITA расшифровывается как Darwin Information Typing Architecture. Формат DITA далеко не новый (первая версия вышла ещё в 2005 году). Фактически это приложение XML со своей стандартизированной схемой DTD. Формат DITA идеально подходит для разработки технической и пользовательской документации, хотя он может быть использован, скажем, для написания учебника или даже романа.

Открытый стандарт DITA, который определён и поддерживается Техническим комитетом OASIS.

Схема DITA включает в себя как хорошо знакомые всем теги, такие как <p> или <ul>, так и специальные теги, предназначенные для документации: <uicontol>, <wintitle>, <apiname>, <parmname>, <userinput>, <systemoutput>. В DITA поддерживается удобное, расширенное форматирование рисунков и таблиц. Например, в таблицах можно как угодно объединять поля и применять различные выравнивания текста, вплоть до его разворота на 90°. Но DITA удобен не только этим, самое интересное в нём — это возможности организации содержимого документов. При работе с документом писатель не просто пишет текст, он конструирует его как в Lego: сначала выбирает нужные блоки, потом собирает из них необходимую конструкцию, а затем при необходимости меняет положение блоков.

Ещё технология DITA хороша тем, что позволяет отделить сам текст документации от его оформления в готовых документах. Примерно так же, как это делается в HTML — контент отдельно, оформление в CSS отдельно. В этом смысле DITA-файлы — это чистый контент, который затем с помощью специального toolkit можно преобразовать в документ любого формата — от HTML до PDF.

Конструируем новые блоки

В DITA есть два основных типа файлов — это топик (topic) и карта (map). Топик — это структурная единица будущего документа. Обычно один топик соответствует одному разделу. В DITA есть топики разных типов, например:

  • Concept — это просто текст на любую тему. Например, «Кот — общие сведения».

  • Reference — это справочная информация. Например, «Варианты мяу верхней октавы».

  • Task — это раздел, содержащий описание последовательности действий, которые нужно выполнить, чтобы решить какую-то задачу. Например, «Как выманить кота из-под дивана».

Типы топиков различаются структурой внутренних тегов. Например, в топике типа Task используется тег <step> для описания одного шага.

Вот пример простейшего топика типа Concept:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
<concept id="conceptId" xml:lang="ru-ru">
   <title>Запрос на открытие двери</title>
   <shortdesc>Если долго вопить на закрытую дверь, то она обязательно откроется.</shortdesc>
   <prolog>
      <author>PhD Eleanor Abernathy</author>
      <publisher>Catnip ltd.</publisher>
   </prolog>
   <conbody>
      <section>
         <p>Для отправки уведомления о необходимости прохода в закрытую комнату кот выполняет следующие действия:</p>
         <ol>
            <li>Садится перед закрытой дверью.</li>
            <li>Начинает передавать периодические сигналы определённой амплитуды.</li>
         </ol>
         <p>После предоставления прохода отправка уведомления прекращается.</p>
         <note>Кот обычно теряет интерес к комнате после того, как дверь открыта.</note>
      </section>
   </conbody>
</concept>

Собираем из блоков конструкцию

Карта — это файл, в котором описана структура будущего документа. Карта содержит иерархический список ссылок на топики, которые нужно включить в документ. Вот пример простой DITA-карты:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE map PUBLIC "-//OASIS//DTD DITA Map//EN" "map.dtd">
<map title="Как понять своего кота?" xml:lang="ru-ru">
   <topicmeta>
      <author>PhD Eleanor Abernathy</author>
      <publisher>Catnip ltd.</publisher>
      <othermeta content="Руководство пользователя" name="doctype"/>
      <othermeta content="1" name="docedition"/>
   </topicmeta>
   <topicref href="food.dita">
      <topicref href="morning_ceremony.dita"/>
      <topicref href="sauce_taste.dita"/>
      <topicref href="eat_or_sleep.dita"/>
   </topicref>
   <topicref href="objects.dita">
      <topicref href="door_open_request.dita"/>
      <topicref href="robot_vacuum_cleaner.dita"/>
      <topicref href="bird_watching.dita"/>
      <topicref href="scratching.dita"/>
   </topicref>
</map>

При сборке карты toolkit автоматически пронумерует все разделы, создаст содержание документа:

Как понять своего кота?
Руководство пользователя.
Глава 1. Питание.
1.1. Утренняя церемония.
1.2. Вкусовые качества соуса.
1.3. Еда или сон — правильно определяем приоритеты.
Глава 2. Взаимодействие с объектами.
2.1. Запрос на открытие двери.
2.2. Робот-пылесос: враг или средство передвижения.
2.3. Наблюдение за птицами через окно.
2.4. Пальма-когтеточка или кресло — выбор неочевиден.

Легко меняем один блок на другой

Если нам нужно как-то поменять структуру документа, то мы свободно перемещаем топики внутри карты, добавляем или удаляем новые разделы. При этом мы не задумываемся о таких технических вещах, как нумерация разделов или, скажем, разрывы страниц. Обо всём этом за нас позаботится toolkit.

Важно, что каждому топику в карте можно назначить свой уникальный ключ. Например, для топика «Важность открытых дверей в инспекции периметра квартиры» можно задать ключ perimeter_security:

<topicref href="topic.dita" keys="perimeter_security"/>

По этому ключу на топик можно ссылаться из текста других топиков:

<xref keyref="perimeter_security"></xref>

Теперь при необходимости мы можем легко заменить ссылку на топик в карте, не меняя его ключ. Все ссылки в других топиках продолжат исправно работать. Это очень удобно, когда, например, нужно выпустить документацию по новой версии системы с новым содержимым заменённого топика. А теперь вспомним, как работают внутренние ссылки на разделы в Word :)

Если в ссылке не задавать текст, то при сборке документа toolkit автоматически подставит название или номер раздела — в зависимости от того, как настроены правила сборки.

Используем один блок в разных местах

Ещё одна полезная и незаменимая функциональность DITA — это возможность повторного использования контента. Самый простой вариант — это использование одного топика в разных картах. Например, мы можем один раз написать раздел «Обратная связь» с координатами компании и затем использовать его во всех документах. Если у компании вдруг поменяется телефон службы поддержки, то нам достаточно будет его поменять только в одном топике.

Другой пример — это глоссарий. Все топики с терминами можно разместить в специальном каталоге. При необходимости писатель добавляет нужные термины в свою карту из этого каталога. Если термин нужно уточнить или исправить, то опять же, это достаточно сделать только в одном топике.

Повторно можно использовать не только топики, но и любые элементы внутри топиков — от параграфов, до строк таблиц. Для этого нужно назначить этому элементу атрибут id, а затем сослаться на него в другом топике с помощью специального тега. Например, в топик с ключом «requests» можно задать для фразы идентификатор last_warning:

<ph id="last_warning"><q>Какая часть моего мяу тебе непонятна?!</q></ph>

Теперь, чтобы повторно использовать этот параграф в другом топике карты, достаточно вставить в нужное место целевого топика такой код:

<p>Если вы игнорируете запросы кота, то последует последнее предупреждающее сообщение: 
<ph conkeyref="requests/last_warning"/></p>

При сборке документа этот тег будет заменён фрагментом из исходного топика. Кстати, чтобы сослаться на исходный топик, он не обязательно должен быть включён в карту. Можно этого не делать, а добавить ссылку с относительным именем файла:

<ph conref="../CommonTopics/requests.dita#references_reusing/last_warning"/>

Наконец, можно добавить в карту специальный технический топик, содержащий подобные готовые блоки. Чтобы он не добавлялся в собранный документ, нужно в карте задать ему специальный атрибут processing-role:

<topicref href="requests.dita" keys="reusing" processing-role="resource-only"/>

Техническая и пользовательская документация полна фразами, конструкциями и данными, которые используются многократно. Писатель может добавить такие блоки информации только один раз, а затем переиспользовать их во всех топиках документа. Ну и, конечно же, при таком подходе можно забыть про команду «Поиск и замена». Поменять текст блока нужно будет только один раз — в исходном топике.

Каждому заказчику — индивидуальный блок

Мы уже знаем, что один и тот же топик можно использовать в разных картах. Но при этом часто может возникнуть ситуация, когда в таком универсальном топике для разных документов нужно поменять одно-два слова. Например, название системы. В этом случае нам поможет фильтрация.

Фильтрацию можно задавать по нескольким атрибутам, например, таким: audience, platform, product. Фильтр можно добавлять на любой элемент топика. Например, этот параграф предназначен только для владельцев сибирских котов:

<p platform="Siberian">Сибирским котам требуется регулярное расчёсывание шерсти.</p>

Чтобы применить фильтрацию, при сборке документа нужно указать, какие фильтры для него действуют.

Писатели часто используют фильтрацию, когда пишут набор документов для разных ролей пользователей. Администратор и обычный пользователь могут работать в одном окне приложения, но администратору будет доступно больше параметров. Можно описать такое окно в одном топике, но в списке полей использовать фильтрацию, чтобы в документ для администратора попали все поля, а в документ для пользователя — только те поля, которые ему доступны. Администратору кота также доступно больше команд, чем другим членам семьи.

Можно также задать фильтр для ссылки на топик в карте:

<topicref href="topic.dita" audience="Administrator"/>

Это позволит нам создать одну карту для всех вариантов документа.

Немного об инструментах

Для редактирования DITA-файлов можно использовать любой удобный XML-редактор. Также есть специализированные приложения с поддержкой DITA, например: oXygen XML Author.

Для сборки документов из DITA-файлов обычно используется бесплатный Toolkit DITA-OT. В этом toolkit уже есть готовые инструменты для преобразования DITA-файлов в большинство популярных форматов: HTML, CHM, PDF, EPUB и другие. Чаще всего используют преобразование в PDF и HTML. Все основные правила преобразований описаны в виде XSLT-файлов, так что можно самостоятельно кастомизировать сборку документов.

Кстати, поскольку DITA — это расширение XML, то можно создавать DITA-файлы не только вручную, но и с помощью сторонних программ. Например, можно написать утилиту для преобразования структуры базы данных в готовые DITA-файлы. Писатель получает готовую карту справочника с топиком на каждую таблицу БД. В топике уже есть список полей и их формат. Писателю остаётся только добавить описание таблиц и полей.

Сначала сложно, потом легко

DITA — это, конечно, не Markdown, который можно неплохо освоить за полдня. Но, если с DITA как следует разобраться, то написание сложных технических документов существенно упростится. DITA позволяет полностью сосредоточиться на содержании документа и не думать о его оформлении. Кроме того, этот инструмент помогает легко и быстро вносить изменения и дополнения в уже написанные ранее документы.

В этой статье я рассказал только об основных достоинствах DITA, но это удивительно гибкий и универсальный инструмент, который предоставляет множество возможностей для технических писателей и других специалистов, которые постоянно работают с программной документацией. А как вырастить психически здоровую кошку — вопрос по-прежнему остаётся открытым.

Комментарии (6)


  1. BasilSnowman
    30.01.2022 14:31
    +2

    А как вырастить психически здоровую кошку — вопрос по-прежнему остаётся открытым.

    фу ты.. полез читать и проверять себя. вдруг ненормального кота вырастил? и такой облом в самом конце. совести у вас нет..))))


  1. alexs963
    30.01.2022 14:59

    Кто-то изобрёл TeX, только на xml.


    1. alexs963
      30.01.2022 14:59

      Правда сейчас на смену xml пришел json, ждём нового формата?


      1. S_A
        30.01.2022 15:53

        markdown... а потом просто естественный язык. на какой-то конфе уже давно слышал, что IoT-устройства на нем родном общаться будут.

        и кстати не вижу в этом ничего запредельного. есть например BERT-оподобные модели (рус./англ.) на ~50 Mb, huggingface cointegrated rubert-tiny. для генерации конечно таких маленьких пока что нет, но возможно, это дело или времени, или железа. а может и просто облачных сервисов.

        но скорее всего вендоров надо еще вынуждать на такое идти, не всем выгодны универсальные интерфейсы. а пользователю вообще было бы удобно, купил девайс, а он со всеми договорился в доме) главное чтобы не поругался)


      1. horror_x
        30.01.2022 17:52

        А на смену JSON пришёл YAML. Не во всех сценариях, но вручную составляемые документы как раз его случай.


  1. dimitrii_z
    30.01.2022 20:16

    Спасибо за попытку пояснения, но по факту в статье не раскрыты конкретно преимущества данного способа по сравнению с более простой и быстрой в использовании связки маркдауна и, например, VuePress: развернуть и настроить вьюпрес надо один раз (в том числе настроив стили, структуру, глоссарий, поддержку мультиязычности, самописные компоненты и прочее), а автору совершенно не требуется потом знать и понимать некий XML, HTML и прочие непонятные для обычного пиарщика/журналиста вещи.

    А если речь конкретно про тех.писателей, то писать в чистом XML проставляя теги - намного дольше, чем набрать тот же текст в маркдаун. Опять же, вьюпрес из коробки имеет механизм использования мультиязычности, тут об этом ни слова, а документация разрабатывается зачастую не под один язык.

    То есть мне как тех.писателю с опытом не ясны преимущества, буду благодарен за аргументированный ответ )