Почему выбирают XML для написания книг?

Почему раньше психические болезни лечили лоботомией? Потому что не знали, что так не нужно делать.

Вы имеете ввиду, что XML морально и технически устарел для написания книг? на подобии ситуации с XML VS Json. Или про то, что пассатижами лучше не забивать гвозди?

пассатижами лучше не забивать гвозди

Вот это. У формата нет никаких преимуществ для написания книг. Вариант «пишу в ms word, но я же профессионал и в docx сохранять не буду».

Наверное, потому что практически разница не заметна.

Разница на выходе или в процессе?

У меня нет опыта работы с XML, но когда-то давно увлекался (X)HML. И есть опыт работы с Latex. Лично мне кажется, что разница в процессе работы над книгой будет колоссальной в пользу Latex.

Подскажите, почему программисты выбирают XML для написания книг, а не, например, Latex?

Например чтобы можно было экспортировать в HTML, а не только печатать. Для поддержки переменной ширины окна. Для экспорта в разные форматы электронных книг.

Странные люди выбирают странные штуки порой. Если что-то существует, то каким бы убогим, неудобным и нелепым оно не было, всегда найдётся хотя бы один-два человека, которые это выберут и будут говорить, что им так удобно, и они привыкли. В этом нет какой-то внутренней логики. Ты нашёл двоих сумасшедших, которым нравится работать на XML. Повезло. Но не надо это экстраполировать на «программистов» в целом. Да и с профессией/тематикой это вряд ли связано.

Мартин вон вообще в WordStar 4.0 для MS-DOS свои книги пишет.

Это не значит, что книга прямо пишется в XML изначально. Разметку можно применять к уже готовым главам, например.

TeX это язык программирования, а XML это язык разметки данных. Многие считают документы данными, а не программами. И поэтому выбирают язык разметки, а не язык программирования.

На самом деле авторам удобно использовать XML, например, Docbook. Потому что там семантическая разметка. Автору главное семантику донести. А превращение семантики в буковки нужной гарнитуры и размера, отступы, размещение врезок и прочих рисунков делает издательство.

Мартин вон вообще в WordStar 4.0 для MS-DOS свои книги пишет.

За эту ссылку отдельная благодарность! Давно хотел найти информацию по Мартину и MS-DOS, всё руки не доходили. Ну и слово экстраполировать мне тоже пригодится (каюсь, обобщил видовое с родовым).

TeX это язык программирования, а XML это язык разметки данных

Кнут и авторы xslt смотрят на тебя с недоумением :)

Почему выбирают XML для написания книг?

Потому что DOCX и OOXML. Дело раскрыто.

Пишут в том, что хочет издательство. O'Raily например ранее использовала troff, но решила что это «сложна» для авторов и перешли на xml. Был сделан транслятор из xml в troff, а перчатная версия по прежнему организовывалась с помощью уже сложившейся troff-экосистемы и так они жили длиительное время. Как сейчас — не знаю.

С моей точки зрения — так себе формат. Для простых вещей там всё просто, но шаг влево/вправо гарантирует кучу головняка и лишних телодвижений. К счастью большинство текстов очень простые — там больше org-mode подходит.

Из LaTeX в HTML тоже неплохо переводится.

Подскажите, почему программисты выбирают XML для написания книг, а не, например, Latex?

Написание книги для нескольких форматов: pdf, epub, html.

Потому что латех страшный как атомная война.

Подскажите, почему программисты выбирают XML для написания книг, а не, например, Latex?

Потому, например, что есть DocBook, специально заточенный под книги. Чёткая логическая разметка.

Против LaTeX ничего не имею.

Потому что не знали, что так не нужно делать.

Лучше бы продолжали.

«пишу в ms word, но я же профессионал и в docx сохранять не буду»

Docx – это зазипованный xml. Может они это имели в виду? ;)

А какая разница на чём? На чём захотел на том и написал. docx это фактически тоже xml, да и практически все другие офисные форматы, да и не только, просто чудовищно перегруженные и переусложнёные (на самом деле найти не xml формат хранения в ентерпрайзнутых продуктах, надо постараться), а тут челы скорее всего взяли использование в упрощённом виде и поэтому xml можно использовать напрямую. Только и всего.

XML морально и технически устарел

Скорее defective by design. Текстовый — т.е. не оптимален для чтения машиной и слишком уродлив и многословен что бы быть читабельным для человека.

Говоря откровенно — не знаю. Тут вариантов несколько: либо (как справедливо заметил Evgueni Михайлович) требование издательства, либо технические вопросы пост-издательства (конвертация в какой-нить формат epub, fb2 …), либо личные предпочтения автора.

Сам я слабо представляю как можно вообще что-либо писать объёмом более 10 стр. вне LaTeX’а (может и можно, конечно, если там нет ссылок на литературу и жёстких требований к оформлению). Тем более книгу. Если стоит задача написать методичку или руководство, не говоря уже о главе к какому-нить коллективному труду, меня начинает трясти если под рукой нет связки TeXstudio-Zotero-Яндекс.Диск. А вот мой научник труды в 800 стр. писал рукой на листах A4 — остальное (как он считал) проблема издательства. И издательства с удовольствием принимали рукописи и подгоняли под нужный им формат.

Подскажите, почему программисты выбирают XML для написания книг, а не, например, Latex?

Потому что latex требует отдельного изучения, а xml это тупо абстрактный html. Впрочем сегодня писатели скорее выберут markdown, т.к. он удобнее. Конкретную вёрстку книги всё равно будет делать издательство (это завязано на чисто технические вопросы книгопечати).

Сам я слабо представляю как можно вообще что-либо писать объёмом более 10 стр. вне LaTeX’а (может и можно, конечно, если там нет ссылок на литературу и жёстких требований к оформлению). Тем более книгу.

Да вообще легко. Если нет сложных формул (например если это вообще художка, да и про кодинг тоже), то MarkDown более чем достаточно, а LaTeX избыточен.

Согласен. Можно хоть в .txt, если нет требований по каким-нить полям и межстрочному интервалу (кстати, а в MD их настроить можно?). Всё по усмотрению автора.

Docbook хуже чем sgml для простых случаев, в сложные случаи, как, собственно и sgml, он не вытягивает. С конвертацией там тоже не всё так шоколадно и необходимо доводить по месту руками уже в выходной формат (для O'Reilly это был troff).

Так что xml — это технологический выкидыш, который по хорошему нафиг уже не нужен, но в него вбухано столько сил и денег той же Adobe, что бросить жалко. Исторический курьёз, так сказать.

К счастью большинство текстов очень простые — там больше org-mode подходит.

Относительно.

Большую статью/книгу, по моему опыту, хорошо начинать в org-mode. Структуру, начальное наполнение, первоначальный список.

Потом уже требуется что-то большее.

Pandoc: В своё время надо было написать большую статью. Результат должен был быть в docx. Число ссылок >200. Спас Pandoc + citeproc + crossref. Но текущая документация у меня вызывает регулярно ступор. Как на неё отправлять новичков?

DocBook: Я так и не смог осилить. Как писать понятно. А вот где достать внятные шаблоны и стили для создания книг? В чём редактировать? и т.д. и т.п. Нужен отдельный человек на сопровождение всего этого.

Asciidoctor: С точки зрения минимального сопротивления мне больше нравится. Хотя и в нём до фига и больше недоделок. Но дефолтные стили +/-. В добавок include::xxxxx.adoc[leveloffset=+1] удобен. На пример, сейчас посмотрел один из проектов: 72 adoc-файла.

Но во всех них не хватает каких-то мелочей. На пример, в Obsidian прекрасные перекрёстные ссылки. За которыми ты просто не следишь. Переименовал/переместил файл, и по фигу.

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

В случае org-mode дополнительными переменными окружения можно настроить всё так, чтобы получался вполне приличный pdf, получаемый само собой через LaTeX без необходимости доводить tex-файл руками.

Так что xml — это технологический выкидыш,

Ну тот же DAPS в какой-то момент кроме DocBook стал поддерживать и AsciiDoc. Так что поддержу этот тезис всеми руками. xml отмирает как слишком сложный для ручного редактирования.

если нет требований по каким-нить полям и межстрочному интервалу (кстати, а в MD их настроить можно?)

Конечно нет. Но их можно сделать любыми при печати или конвертировании из MD в PDF, HTML или любой другой формат. Собственно в том и смысл, чтобы разделить семантику от стиля отображения. В MD у тебя есть абзацы, заголовки, есть списки нумерованные и ненумерованный, выделения, таблицы, ссылки, и т.д. и т.п. А как именно оно будет отображаться (шрифты, цвета, выделять ли курсивом или подчёркиванием, посередине заголовок или в начале строки, поля, межстрочные интервалы и прочее) — этому как раз не место в MD, а место в параметрах конвертирования в конечный формат, ну или в CSS, если это рендеринг.

Да и какое отношение имеют требования по полям или межстрочному интервалу к писателю? Его дело — написать текст и разметить его так, чтобы было очевидно (в том числе машине, желательно), где тут просто абзац, где список, а где курсивом выделить — а дальше уже работа издательства. Собственно в XML так же.

Ну а если писатель хочет всё это контроллировать, то ему просто нужна связка markdown+css, например. Как вариант, можно стили в LaTeX хранить, а из markdown предварительно тоже в него конвертировать. Просто с markdown на этапе написания банально удобнее работать.

Большая книга в моём случае — это LaTeX без вариантов. Там всё есть, чтобы за разумный промежуток времени получить приличный pdf, за который стыдно перед собой не будет.

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

Первый раз слышу чтобы кто-то писал тексты в xml.

Большая книга в моём случае — это LaTeX без вариантов.

Когда работал ещё преподавателем в ВУЗе, перешёл с LaTeX (pdf) на pandoc (html) для текстов лабораторных. Основной пункт «за» был: возможность скопировать исходный код из текста задания.

В последствии оценил ещё один момент. Можно быстро набрать текст с формулами и кусками исходного кода, на выходе красивый и понятный документ, который можно отправить коллегам. В LaTeX это можно было бы сделать также, но надо было взять шаблон документа из закромы, и добавить мелкие сущности для форматирования.

LaTeX прекрасен для создания красивого печатного издания или презентации. В электронном виде html в мелочах лучше pdf. Но эти мелочи важны.

Docbook хуже чем sgml

Ээээ… DocBook был как на базе SGML, так и на базе XML.

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

что касается XML в документации: техничекая документация пишется в форматах несущих логическую структуру документа и наделяющих текст семантикой, это DITA и DocBook. Так делают, потому что в документе остается только содержание и структура, а представлением документ наделяется на следующем этапе, внешними относительно документа средствами. Из одного исходника автоматическим путем можно получить несколько вариантов документа или книги например HTML для потребления браузером и PDF для печати (на бумаге).

использование структурированного формата позволяет например формировать нетривиальные цепочки обработки: например документ можно формировать из нескольких входных частей, другие части наоборот делить, добавлять динамическое содержание к рукописному, подвергать линтигу (для всего этого подойдет любой ЯП с поддержкой XML, то есть любой ЯП). кроме того можно вмешаться в XSLT преобразоания механизмом расширений на хост-языке.

некоторых возможности есть штатных процессорах, например «профайлинг» - когда готовится например две вариации PDF в которых включаются/исключаются некоторые части документа.

конечно нельзя забыть и возможности проверки корректности синтаксиса документа и даже его структуры: DocBook XML документ валидируется против схемы.

семантика, набор элементов в обычном DocBook фиксирован, но его можно расшить путем расширения схемы (RelaxNG). Это даст возможность использовать в тексте свои теги. Правда их поддержку нужно будет реализовать и в XSLT, что возможно, но крайне заморочено

документация многих проектов (как минимум FreeBSD, PHP, PostgreSQL) написана в DocBook.

книги издательства O’Reilly (с животными на обложке) долгое время писались на XML, а именно DocBook XML, то есть «мастер-версия» кгиниги - это XML. Затем из нее получали уже PDF. DocBook и был (если я не путаю) разработан сотрудником O’Reilly, правда сейчас в O’Reilly от него ушли к формату на базе HTML

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

на сегодняшний день можно говорить что проект DocBook уже «всё». я бы не советовал с этим связываться, несмотря даже на недавние порывы сделать третью версию XSLT тулчейна.

что до DITA, то он используется в основном в американской промышленности.

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

еще можно упомянуть asciidoc - на мой взгляд достаточно гнилой и как язык и как проект по крайней мере в том виде что с ним стало. к слову начался он как «DocBook, в другом синтаксисе», то есть использовал примерно ту же семантику и на выходе давал DocBook XML. я не могу точно дать информацию, но когда-то проходила информация, что как минимум одна книга для орайли была написана в DocBook XML не напрямую, а через asciidoc.

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

кстати в список известных проектов: документация RedHat Linux я догадываюсь тоже написана в DocBook. хотя федора я видел что-то пишет на asciidoc.

Ээээ, я как бы в эти особенности вляпался, когда переводил Cyrillic-HOWTO с одного формата на другой (кому-то из идеологов коллекции HOWTO показалось, что DockBook лучше для них подходит чем простенький sgml). Хотя возможно позже sgml доработали, чтобы XML можно было имитировать.

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

Оба подхода имеют право на жизнь.

Справедливости ради надо добавить, что тот же pandoc и многие другие рендеры поддерживает формулы TeX в md. Поэтому формулы тоже не ограничение.

Просто формулы — это лишь малая часть (при условии, что есть шрифты).

А что такое не просто формулы?

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

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

P.S. И шрифты в этой пачке — это огромный головняк, если в него вдаваться.

почему программисты выбирают XML для написания книг

Два писателя, это не показатель. Может остальные выбирают маркдоун.

При желании всё это можно получить и в md.

Зачем, если это всё это уже есть в LaTeX?

Latex это лекарство для больших документов с строго заданными параметрами, XML если это имеют ввиду ms и oo офисы это для одной странички, да в них есть стили и всё для работы с большими доками, но можно изуродовать мястечковой правкой, Latex работает только в режиме большой документ, не позволит тебе его испортить.
Эти писатели-программисты не пишут больших текстов для печати, или их не заколебало проводить мелкую правку в тексте.

Оба подхода имеют право на жизнь.

Не отрицаю. Но не забываем, что их md/adoc можно получить и tex-файл. Что удобнее для создания сразу нескольких форматов на выходе.

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

Ну как-то так было несколько лет назад main.md:

---
title: ...
author: ...
date: ...
lang: ru-RU
citation-style: csl/gost-r-7-0-5-2008-numeric-alphabetical-and-title.csl
bibliography: [bib/refs1.yaml, bib/refs2.bib]
link-citations: true
figureTitle: Рисунок
tableTitle: Таблица
titleDelim: .
figPrefix: Рис.
tblPrefix: Таб.
numberSections: true
secHeaderTemplate: $$i$$. $$t$$
...
---

# Аннотация.  {.unnumbered}

Смотри [@book1, @report2]...

For immediate example, see @fig:figure0

![A figure](img0.jpg){#fig:figure0}
...

Сейчас citeproc внутри pandoc без необходимости добавления фильтра. Что-то могло измениться. Но сути это не меняет.

Большой пласт таких задач решает pandoc сам, либо за счёт фильтров (пример, pandoc-crossref).

Точно так же из LaTeX (при сохранении простого набора договорённостей) можно получить что угодно, в том числе и тот же html.

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

Сразу же пришли на ум рисунки, которые нужно разместить непременно до вот _этого_ абзаца, но не сильно далеко, точнее на одной с ним странице и длииииной подписью, которая вылазит за всё, что можно ☺

Я вот только markdown на asciidoc заменил бы.