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

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

Сразу чувствуется пользователя LaTeX ;)

Сколько сам тратил время на форматирование, когда ещё только проценты текста были набраны…

Вот по этому набор в md/adoc выгоднее для подготовки многоформатного результата. До готовности 90% текста не отвлекаешься на форматирование. А предварительный результат видно сразу.

Для тех, у кого большой опыт LaTeX, pandoc привычнее. Набор формул тот же. Есть поддержка BibTeX.

Ну а подгонку форматирования уже можно сделать на финальном этапе перед печатью. Сконвертировал в LaTeX и довёл до совершенства ;) Для epub свой финал. HTML можно подправить в любой момент.

Сконвертировал в LaTeX и довёл до совершенства ;)

Это! В этом вся проблема: доведение до ума в итоговом формате. Она не решается никак.

А простые вещи в LaTeX и точно так же просто делаются.

P.S. Основные «челенджи» возникают ни когда сам набираешь — я знаю как и что нужно/можно делать, а когда верстаешь чужой текст, который поменять нельзя ☹

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

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

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

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

Для людей эта нечитаемая мешанина из тэгов и аттрибутов выглядит слишком громоздко. Для машины данные расположены неэффективно. Стандартные средства unix’а с xml’ем не работают. Очень хорошая вещь случилась в индустрии. Скорей бы его забыли с концами.

Добавьте CSS и для человека будет хорошо выглядеть. А машинам без разницы - все равно в основном будет прилетать сжатый в архив файл.

Добавьте CSS и для человека будет хорошо выглядеть.

Не будет. Всё равно слишком много шума.

будет прилетать сжатый в архив файл.

Который нужно распаковать и разобрать текст. Т.е. вы своей упаковкой только добавили работы.

Для машины данные расположены неэффективно.

не более или менее эффективно чем в каком-нибудь json.

«эффективно» данные расположены наверное только в дата-файлах колумнарных бд

Добавьте CSS и для человека будет хорошо выглядеть.

Не будет. Всё равно слишком много шума.

Какого шума? Вы даже тэгов не увидите, а отображение с CSS можно настроить как вам удобнее, хоть в стиле ЛОРа

Который нужно распаковать и разобрать текст. Т.е. вы своей упаковкой только добавили работы.

Так я именно об этом - что как раз все равно распаковка/упаковка будет. То есть предпроцессинга не избежать.

ЗЫ. XML в потоке еще удобно разбирать по-элементно.

Docbook хуже чем sgml для простых случаев, в сложные случаи, как, собственно и sgml, он не вытягивает.

Сдаётся мне, что у тебя очень мутные представления о том, что такое XML, SGML и DocBook.

XML и SGML — это метаязыки, а DocBook — это конкретный язык XML. Как можно сравнить метаязык с конкрентным языком? Ну, ладно ТС — от хоть вопрос задаёт, но ты-то отвечать берёшься, но при этом несёшь пургу.

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

По месту применяются конкретные представления. XML даже в DocBook инкарнация — это полная гадость. SGML, который использовался для написания HOWTO и де факто для всего остального (потому для него специального имени не придумали), много проще и лучше, но годится только для простых случаев.

Ага — Adobe FrameMaker

Странно, что не JSON выбрал. Для написания книг.

Какого шума? Вы даже тэгов не увидите

Я рассуждаю с позиции создателя документа. Вот ему приходится работать непосредственно с голым xml.

XML в потоке еще удобно разбирать по-элементно.

Машине неудобно. Машине удобно работать с бинарными форматами.

Я че-то вообще не понимаю, как можно «писать книгу в XML». Можно пример?

Я рассуждаю с позиции создателя документа. Вот ему приходится работать непосредственно с голым xml.

И много «создателю» документа приходится видеть XML в ворде или экселе? В мобильных приложениях или на сайтах?

Машине неудобно. Машине удобно работать с бинарными форматами.

zip - бинарный формат. Удобно/неудобно - это человеческая категория. Машина должна работать, а человек отдыхать.

TeX примерно с той же натяжкой язык программирования как и например PDF (там же урезанный Postcript есть в стандарте) и какой-нибудь современный CSS с кучей расширений тоже может что-то сам «высчитывать»

Но так-то да, для печати на бумаге в любом случае ещё много работы нужно делать в чём ты не пиши на черновую.

Вот пример из 2003 года: http://www.inp.nsk.su/~baldin/Cyrillic-HOWTO-russian.tar.bz2

Осторожно: koi8-r ибо c UTF-8 при конвертации тогда были проблемы.

И много «создателю» документа приходится видеть XML в ворде или экселе?

У XML’я есть много достоинств: например можно от него отгородиться, чтоб вообще его не видеть ни в каком виде.

zip - бинарный формат.

zip — это вообще не формат в данном случае. Формат — это то, что им заархивировано.

Удобно/неудобно - это человеческая категория.

Интересно вы XML защищаете.

Вот, истина! XML не для людей, а для машин. Это было собственно понятно всякому, кто видел представления решения квадратного уравнения в виде MathML

Не знаю, кто на чём пишет эти ваши книги, а я по-старому, при помощи бумаги и ручки.

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

А docx это разве не XML?

Я че-то вообще не понимаю, как можно «писать книгу в XML». Можно пример?

book.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE Book SYSTEM "book.dtd">
<Book>
    <Title>Пример книги</Title>
    <Author>
        <FirstName>Иван</FirstName>
        <LastName>Иванов</LastName>
    </Author>
    <PublicationYear>2024</PublicationYear>
    <Genre>Фантастика</Genre>
    <Chapters>
        <Chapter number="1">
            <Title>Введение</Title>
            <Content>&loremText;</Content>
        </Chapter>
        <Chapter number="2">
            <Title>Начало истории</Title>
            <Content>Текст второй главы. &externalText;</Content>
        </Chapter>
    </Chapters>
</Book>

book.dtd

<!ENTITY loremText "Lorem ipsum dolor sit amet, consectetur adipiscing elit.">
<!ENTITY externalText SYSTEM "chapter2.txt">

chapter2.txt

Это содержимое второй главы, загружаемое из внешнего файла.

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

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

ППКС с обоими ораторами. Инлайн вставки html и mathtex решают проблемы с формулами и т.д. в маркдауне.

zip — это вообще не формат в данном случае. Формат — это то, что им заархивировано.

https://ru.wikipedia.org/wiki/.ZIP

ZIP — формат архивации файлов и сжатия данных без потерь. Архив ZIP может содержать один или несколько файлов и каталогов, которые могут быть сжаты разными алгоритмами. Наиболее часто в ZIP используется алгоритм сжатия Deflate. Формат был создан в 1989 году Филом Кацем и реализован в программе PKZIP компании PKWARE[2] в качестве замены формату архивов ARC Тома Хендерсона. 

Обратите внимание на случай использования с несколькими файлами и каталогами - прям вот эту фичу чем заменить?

ZIP — формат архивации файлов

xml-парсеру абсолютно без разницы, что перед тем, как данные поступили на разборку, они были упакованы или зашифрованы. Его [не]эффективность от этого никак не зависит.

прям вот эту фичу чем заменить?

Вы смешиваете архивацию и компрессию. Если вам просто нужно собрать для удобства много файлов в один, для этого спокон веков есть tar. Однако это уже другой вопрос, никак к формату данных не относящийся. Что tar’ом, что zip’ом вы можете обрабатывать файлы любых форматов.

Не только. Там бинарные вставки есть в формате и в вида «как в ворде»

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

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

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

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

Проблема в том, что XML плох и для машин тоже. Его продавали как человекочитаемый, самодокументируемый формат. Если отказаться от этих фишек, то он начинает играть в лиге бинарных машинных форматов и с треском тут проигрывает. См. например Comparing the Performance of Abstract Syntax Notation One (ASN.1) vs eXtensible Markup Language (XML):

We describe a series of tests that have been carried out to measure the performance differences between eXtensible Markup Language (XML) and Abstract Syntax Notation One (ASN.1) with its Basic Encoding Rules (BER), for signed and unsigned attribute certificates. Our findings demonstrate that, as might be expected, XML encoded attribute certificates are approximately an order of magnitude greater in size than ASN.1 BER ones. The XML encoding process is initially faster than ASN.1 BER for small unsigned data structures, but the time taken increases more rapidly so that for large complex data structures ASN.1 BER is quicker than XML. However, ASN.1 BER decoding of unsigned data is always two to three times faster than XML decoding, regardless of data size. When digital signing is taken into account, ASN.1 BER is faster than XML for all data structures, and its performance advantage increases with data complexity. When validating signed data structures, ASN.1 starts at over 3 times faster than XML for simple attribute certificates, rising to an order of magnitude faster for complex attribute certificates. When transmission time is taken into account ASN.1 BER outperforms XML in all of our scenarios. For small comparable unsigned data objects across broadband connections, the performance difference is a factor of 5 greater, and for large signed data objects across 64k lines the difference is approximately an order of magnitude better. We conclude that where performance is required to be optimal there are better choices of data formatting and digital signing than XML, and one of those choices is ASN.1 with its BER.

Собственно, давно выкатили Efficient XML Interchange (EXI) Format, который може быть неплох в некоторых сценариях. См публикацию Performance Comparison of Data Serialization Schemes for ETSI ITS Car-to-X Communication Systems:

… . In this work, we provide a performance comparison analysis between the standardized ASN.1 , the binary representations, Google Protocol Buffers and Efficient XML Interchange format (EXI), all of them as alternative strategies for data serialization. Standardized data content for CAM, DENM and the security envelope are used in the conducted study. We conclude that ASN.1 encoding on the facility layer shows the best performance, outperforming Google Protocol Buffers and EXI. However, for the case of encoding the security envelope, ASN.1 is outperformed by a binary encoding scheme in most cases, while EXI encoding outperforms all other schemes. This implies that standardization efforts for the security envelope should reconsider the recent shift from binary encoding towards usage of ASN.1. Instead, the Efficient XML Interchange format should be considered for this purpose.

Но оригинальный XML даже не рассматривается. Он проигрывает всем и во всём.

Движок формул можно хоть куда впихнуть. Для этого не нужно терпеть все латех уродства с процессингом на баше и компиляцией pdf 10 минут. Про нормальный предпросмотр во время редактировпния я молчу. А уж какого хрена набор утилит для латеха весит несколько гигабайтов я даже боюсь думать.

терпеть все латех уродства

Об чём речь? На примерах пожалуйста.

Про нормальный предпросмотр во время редактировпния я молчу

У меня в emacs всё работает.

меня начинает трясти если под рукой нет
Яндекс.Диск

Лечится вам надо батенька.

как можно «писать книгу в XML». Можно пример?

.docx

Повторяю второй раз и последний: SGML, как и XML — это метаязыки. Они пригодны для создания конкретных языков на их основе.

Во-первых, SGML, который использовался для написания HOWTO — это бессмыслица. Для написания HOWTO мог использоваться какой-то конкретный язык, но не SGML сам по себе.

Во-вторых, SGML не может быть проще XML, поскольку XML — подмножество SGML. Авторы XML решили, что SGML слишком сложен и упростили его до XML.

Кончай нести пургу. Если не владеешь вопросом, то лучше промолчи.

<!DOCTYPE Book SYSTEM "book.dtd"> ни на что не намекает?

Говорить, что «книга написана на XML» — это всё равно что говорить «программа написана на алгоритмическом языке», не называя конкретного языка. Фортран и Форт — оба являются алгоритмическими языками, и даже названия похожи, но это очень разные языки.

Ээээ, для начала разберись в вопросе как это реально было на практике, а потом уже строй из себя знатока на деревне. Повторялка у тебя ещё не отросла.

то есть ты переводил книгу, она была в SGML, но это был не DocBook. пускай не DocBook, но на каком-то же языке разметки она была?

XML даже в DocBook инкарнация — это полная гадость. SGML, который использовался для написания HOWTO и де факто для всего

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

SGML - этот обобщенный язык разметки как и XML. и у того и другого есть ряд применений. HTML - самое популярное применение SGML. XHTML - одно из применений XML. DocBook был применением как SGML так и XML (в последующих версиях)

Для людей эта нечитаемая мешанина из тэгов и аттрибутов выглядит слишком громоздко. Для машины данные расположены неэффективно.

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

Я че-то вообще не понимаю, как можно «писать книгу в XML». Можно пример?

Мцыри в xml
<?xml version=«1.0»?>
<![CDATA[
Немного лет тому назад,
...
И никого не прокляну!...»
]]>

И много «создателю» документа приходится видеть XML в ворде или экселе? В мобильных приложениях или на сайтах?

Как минимум на сайтах, это не такая уж и редкость.

Не знаю, кто на чём пишет эти ваши книги, а я по-старому, при помощи бумаги и ручки.

Почему не пером? С точки зрения нашей эры ручка это уже хипстерское поделие.

Четверть века назад мы были молоды, наивны и полны надежд. Ну, ошиблись чутка, бывает. А сейчас-то чего? Впрочем, на лоре каких только чудных мнений не высказывали.

Тут миллиарды выбирают венду, а ты про какого-то чудика который XML выбрал для написания книг. Ну выбрал и выбрал, чего такого-то. Может ему нравится как длинные открывающие и закрывающие тэги выглядят, или прётся от < и >.

Четверть века назад мы были молоды, наивны и полны надежд.

Отличное объяснение! Ведь так и было, мы верили в то, что всё новое... ну или почти всё новое, несет только хорошее, доброе и однозначно способствует развитию. Помню как сам прочитал про xml и идея показалась мне вполне здравой и своевременной, однако какого-либо применения для себя лично в тот момент я не нашел, а стороннего применения где пришлось бы с ним столкнуться ещё не наплодили. Позже же столкнувшись с ним в работе, я уже был далек от юношеских восторгов и рассматривал его не более чем с точки зрения «и чем же мне удобнее парсить/создавать очередную хрень раз уж пришлось столкнуться».

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

Дык в том-то и дело, что миллиарды это то, что ты видишь каждый день, а вот четыре часа харе кришна орать книгу в xml писать, это не каждый сдюжит.

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

Пока люди не пытаются всех остальных заставить их дичью заниматься - проблем не виже никаких. Иногда даже познавательно и интересно.

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

Полностью солидарен с высказанным вами. И я вроде как о том же «Иногда даже познавательно и интересно.».

Очень смешно, просто обхохочешься.

Конечно смешно, вроде как минимум пиш. машинку изобрели ещё в прошлом веке, в первой половине прошлого века.