В педивикии наткнулся на статью про MathML. Если вкратце, то это такой мертворожденный язык набора математических формул на основе XML. Полюбуйтесь сами:
<mrow> <mi>x</mi> <mo>=</mo> <mfrac> <mrow> <mrow> <mo>-</mo> <mi>b</mi> </mrow> <mo>±</mo> <msqrt> <mrow> <msup> <mi>b</mi> <mn>2</mn> </msup> <mo>-</mo> <mrow> <mn>4</mn> <mo>⁢</mo> <mi>a</mi> <mo>⁢</mo> <mi>c</mi> </mrow> </mrow> </msqrt> </mrow> <mrow> <mn>2</mn> <mo>⁢</mo> <mi>a</mi> </mrow> </mfrac> </mrow>
Правда, очень просто и понятно? Сомневаюсь, что человек сможет «увидеть» здесь формулу для корней квадратного уравнения. Для сравнения, в TeX она записывается так:
x = \frac{-b \pm \sqrt{b^2 - 4ac}}{2a}
…и получается вот такая красота:
В ФАКе по MathML действительно, упоминают про «избыточность» формата — но сами посудите, почему нельзя сделать MathML чуть поумнее? В формулах буквы, цифры и значки обычно имеют вполне определенный смысл и изображаются вполне определенными шрифтами — в TeX просто заранее определены классы символов и правила их изображения (например, значки бинарных операторов вроде ‘+’ обычно имеют «отбивки» слева и справа, а буквы пишутся курсивом). В MathML это приходится задавать вручную — то есть снабжать каждую букву тегом <mi>, а числа — <mn>. Вряд ли можно назвать такой формат и human-readable (а уж про writable говорить не приходится).
Это, кстати, не скрывается. В том же ФАКе пишут, что желательно пользоваться программами-генераторами для создания документов MathML (кстати, такой генератор есть в Windows 7, называется «Панель математического ввода», здорово умеет распознавать всякие каракули).
В общем, про что это я? А про то, что применение XML-подобных языков зачастую просто усложняет задачу. Иногда просто нельзя понять, зачем где-то применен XML и какие он имеет преимущества перед, скажем, ini-файлом. Итак, загибаем пальцы.
— human-readable/writeable — нужно далеко не всегда, а в сложных приложениях совершенно теряется.
— универсальность — в большинстве случаев нафиг не нужна, да и понимается она очень по-разному. W3C, например, «рекламируя» форматы на основе XML, утверждает, что и для XHTML, и для MathML, и для какого-нибудь SVG подойдет один и тот же «универсальный» XML-парсер. Но вот если нам не надо работать с десятью разными типами XML-документов, зачем заморачиваться такой «универсальностью»?
— «самодокументируемость» — без комментариев. Конечно, вот такое еще можно понять, но как разобраться в том же MathML без специального руководства?
— текстовый формат — в свете написанного выше не совсем понятно, зачем это нужно. Человеку читать и писать XML надо не всегда, а для парсера все эти текстовые теги совершенно безразличны и только создают избыточность, которой, кстати, парсер пользоваться не имеет права, например, при обнаружении ошибок — в этом случае он должен сказать, что документ не является синтаксически корректным. Какое счастье, что многие XML-парсеры пытаются хоть как-то обработать даже не вполне корректные документы!
Так вот, к сабжу. Вспомнилось, как лет шесть назад на одном американском программистском форуме я занимался троллингом в теме про предложенный какой-то американской же фирмочкой способ эффективного сжатия XML. Тезисно, троллинг сводился к следующему — XML — это очень плохой формат, его «удобства» представляют собой одновременно и страшные недостатки, для обхода которых приходится делать «костыли» вроде сжатия-разжатия. Естественно, XML тогда был в моде и попытки сказать, что он не везде оптимален, натыкались на такую забористую ругань, что оставалось только записывать.
Через десяток-другой сообщений американцы были ознакомлены с теорией «золотого миллиарда», XML я обозвал технологией, придуманной по принципу «с жиру бесятся», а уж сжатие XML вообще не нужно.
В общем, амеры обычно очень живо реагируют на то, что есть еще и «весь остальной мир», а если выдать фразу «с жиру бесятся» за мнение «остального мира» об очередной их придумке, типа какого-нибудь «пальцеориентированного интерфейса» — то можно словить немало лулзов.