Сдается мне - это скорее недостатки редакторов FB2, чем формата xml или fb2.

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

Понимать, что тег тут может быть или не может должен не парсер, а редактор. А вот, то что на практике проще всего в обычном редакторе копипастить в структуру fb2 - вот это уже и есть недостатки работы с fb2, но при чем тут сам xml.

Как-бы, безосновательный треп. XML - штука ценная и очень удобная, с помощью которой можно легко описывать любые объекты, причем делая это в удобочитаемом виде. Можно, конечно, битовые флаги выставлять напрямую и вообще забыть про всякие w_char, UTF и прочие удобства. Каждому своё.

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

Текст значительно более устойчив к ошибкам и искажениям. Если в каждом слове будет по две опечатки, я все равно смогу текст прочитать и поправить. Ошибки в оформлении исправить как правило невозможно.

А попробуйте поменяйте наугад выбранный байт в PDF или DOC файле. Результат почти наверняка будет тот же - не загрузится. Причем в отличие от XML, вручную такой файл уже не починишь.

То есть единственный формат, который БОЛЕЕ помехоустойчив, чем XML - это plain text. Все остальные гораздо, гораздо хуже. А при этом XML абсолютно неограниченно расширяем по семантике, легко читается и пишется на любом языке. Ценой за все это - необходимость escap'ить всего ДВА символа, угловую скобку и амперсанд. С ТеХом или Постскриптом никакого сравнения - вот там действительно черт ногу сломит, любой символ может значить что угодно в зависимости от контекста. А XML создавался как идеальный компромисс простоты и богатства возможностей - и этого идела он достиг. (За исключением DTD - вот за них действительно стоит надавать создателям по ушам; но причины тут больше исторические, слишком резкий разрыв с SGML тогда бы не прокатил.)

Я помню, каким был мир текста до появления XML и Unicode. Я бы не хотел туда возвращаться, спасибо.

http://www.jrapublish.com/help/Appendices/Embedding_Metadata.htm

Appendix F - Embedding Metadata in DjVu Files

Introduction

JRAPublish™ introduces a standard architecture for embedding metadata in DjVu files.

Metadata is information about documents, stored in individual data fields. These fields define, classify and categorize the documents. Historically these data fields have resided in databases, apart from the documents themselves. JRAPublish™ allows you to embed the data fields directly into DjVu documents, making them portable. In other words, they "take their metadata with them".

Each document format has its own structure for storing embedded metadata. For example, HTML has Metatags and PDF has the DocInfo field dictionary. The DjVu file format lacks a formal metadata structure, but the open architecture of the DjVu format permits us to create our own standard for metadata storage "inside" DjVu files.

The purpose and benefit of storing metadata in the DjVu file structure is that it will not be lost (left behind) during INDIRECT <-> BUNDLED conversions, as well as when downloading a DjVu file with the DjVu web browser plug-in. Because metadata is an integrated part of the DjVu file, the DjVu file is portable, as it "carries" its metadata with it at all times. As a result, for example, a DjVu file can be downloaded from the web and re-indexed on the desktop or on CD and the metadata will still be present. We call this form of metadata storage "Embedded Metadata".

In our standard architecture, metadata fields are stored with tag delimiters. For example, this document in the DjVu format has title, author and date fields that are expressed and stored as:

teg title teg Metadata Storage for DjVu files teg слешь title teg

teg author teg John Smith teg слешь author teg

teg date teg 20011204 teg слешь date teg

Metadata is stored in our standard architecture at three levels: document-level, shared-page-level and page-level.