А вот, кстати, вспомнилось

В педивикии наткнулся на статью про 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}

…и получается вот такая красота:

root2

В ФАКе по 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 без специального руководства?

custom-dll-definition

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

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

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

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

А вот, кстати, вспомнилось: 20 комментариев

  1. Сам по себе xml штука не шибко полезная в большинстве случаев, а вот в паре с xsd/xslt можно творить чудеса из одного представления генерируя всё что угодно. human-readable/writeable это зависит от много чего, в первую очередь от наличия схемы и правильного редактора который всё это понимает. Я в студии вручную генерил/подчищал документы на WordML, не сказал бы что это так сложно. У xml ещё есть одна мега фича о которой обычно забывают — это расширяемость через неймспейсы. Если есть xml документ, то можно легко не боясь что либо сломать добавлять свои данные и метаинфу, т.е. такие вещи как xhmtl+mathml+svg это родная фича, а не приклеено сбоку. А в целом таки да — нужно понимать нахуано сомбреро и не вестись на поводу у окружающих.

  2. Этот «мертворожденный язык», в отличие от tex, поддерживается лидерами индустрии: MS Office, Mathematica и Maple.

    Принципиальное отличие от tex — это язык представления формул, а не только язык описания того, что видно на экране/бумаге.
    В твоём tex например отсутствует инфа о том шо такое «4ac»: 4*ac или 4*a*c.

    1. Где применяется это «представление формул»? Почему для представления формул нужен настолько избыточный синтаксис? В любом языке программирования есть аналогичные средства, и они на порядок компактнее.

      1. А попробуй минизировать XML без потерия функциональности.

        Задача:
        1. проверить синтаксис документа — т.е. для случая ini файла, например, это то, что параметры отделяются возвратами кареток, имя от значения отделены =, имя значения содержит только допустимые символы и там дальше прелести с кавычками и датами
        2. проверить семантику документа — знак дробной черты может быть только между двумя выражениями или константами, но не может быть между, скажем, знаками интегралов

        1. У меня такой вопрос: а кому вообще вся эта функциональность XML нужна, когда его используют в лучшем случае — как сериализацию каких-то данных, которые все равно преобразуют в другую форму, или как конфигурационный файл?

          1. 1. Индусам :)

            Софтина пишется на, скажем дот-нете в котором всегда под рукой хмл-парсер. Зачем заморачиваться с чем-то другим?

            2. Сериализация подразумевает сложные данные. Сделать маршалинг для дат задача нетривиальная.

            3. Универсальность. Пакуя данные на одном конце who knows, что будет ждать на другом. Можно, конечно договориться о других способах маршаллинга, и даже они были — DCOM, CORBA, OFS, но все умерли. Как раз из-за убойной сложности API, кроме прочего. Сейчас еще есть JSON, вполне себе живая вещь, но опять же пока не надо отличить «01/01/01» от «первого января 2001-го года».

              1. 1. JSON имеет смысл, когда на одном из концев JavaScript — тогда распаковка делается с минимальными затратами
                2. JSON и XML равнозначен, если ни на одном конце нет Java’ы, дот-нета (PHP сервер)
                3. JSON требует отдельного интерпретатора если общаются два не JS приложения

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

        1. А что «десктоп писи» нужен еще для чего-то кроме запустить гуглхром? Некоторое время назад еще можно было запускать на писи Файрфокс, но и тот начиная с 9-ки уже только для некрофильских удовольствий.

  3. >если нам не надо работать с десятью разными типами XML-документов, зачем заморачиваться такой “универсальностью”?
    Использовать готовое дешевле чем разрабатывать собственное.

    >текстовый формат
    Есть несколько бинарных форматов XML, например Microsoft .NET binary XML.

    >приходится делать “костыли” вроде сжатия-разжатия
    Не обязательно.
    Например .NET объекты умеют сериализоваццо сразу в binary XML, без какого-либо performance penalty.

    >попытки сказать, что он не везде оптимален, натыкались на такую забористую ругань
    Неудивительно.
    Развитие индустрии показало что правы были американцы: щас XML форматы используются чуть менее чем везде (xhtml, svg, SOAP, MS office, и т.п.)

    1. > Использовать готовое дешевле чем разрабатывать собственное.

      Ну дык, и для ini-файлов есть libconfuse.

      > Есть несколько бинарных форматов XML, например Microsoft .NET binary XML.

      А как у них с совместимостью?

      > Развитие индустрии показало что правы были американцы: щас XML форматы используются чуть менее чем везде (xhtml, svg, SOAP, MS office, и т.п.)

      Еще скажи — конфигурационные файлы grub3.

      1. >libconfuse
        А что у него с кодировками, если я хочу документ в Windows-1251? А если я хочу шоб без лишних телодвижений открывались файлы во всех стандартных кодировках, как это с XML происходит?
        А если я программирую на C#, Java, RoR или JavaScript, где взять libconfuse?

        >как у них с совместимостью?
        Родной парсер везде где есть .NET (win32/64, WinCE, WP7, xbox 360, etc), формат открытый с прекрасной документацией и без royalties, можно реализовать на чом хочешь.

        1. > А что у него с кодировками

          Ничего. Это вам не родной майкрософтский парсер XML из дотнета, который нецензурно воспринимает документы в UTF с BOM.

          > А если я программирую на C#, Java, RoR или JavaScript, где взять libconfuse?

          А стандартных средств работы с какими-либо конфигурационными файлами там что, тоже нет? Кстати, в JavaScript можно использовать json.

          > везде где есть .NET

          lol

  4. Объяснение феномену есть. Но оно не тривиальное.

    Если коротко, то XML — 1. расширяем 2. при этом формализуем 3. поэтому проверяем.

    Если еще короче, то «очевидно что»(с) сила XML’я в XSD

    На примерах

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

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

    2. Приложение собирается из кучи библиотек (в мире J2EE их количество исчисляется десятками на проект). Дальше понятно.

    Идеологическое обоснование.

    Все мы, старые пердуны, любим сыпать песок на предмет «вот раньше был Lisp, это было круто, потом уже трава не такая зеленая». XML — это кучеряво нарисованный Lisp-код. Точнее это вообще 1-в-1 переложенные в теги S-expressions, которые для лиспа были больше, чем JSON для JavaScipt’а. Какие-то тонкие отличия между s-expression и XML’ем были, но я забыл. Во-всяком случае когда однажды пришлось плотно садиться за XSLT душа пела — «наконец-то, наконец-то старый добрый Lisp пригодился для зарабатывания денег».

    …а. Вспомнил. s-expression закрываются неименованой скобкой (в отличи от закрывающего тега xml) и поэтому правильность документа не столь точно проверяется.

      1. J2EE-вселенная. С которой нелепо пытается конкурировать дот-нет.

        Но вам туда не надо.

        Из практических областей, конечно же великий XSLT. Когда из одного XML’я путем почти одной алгебры предикатов получается другой вплоть до PDF’а то, это что-то вроде йоги для мозга.

        1. Йога для мозга это хорошо. Но вот зачем спать на гвоздях и жрать толченое стекло в обычной жизни? Зачем пихать XML в трешовые конфигурационные файлы на две опции или пересылать в виде XML два с половиной числа?

          1. 1. «лучшая библиотека — известная библиотека» — люди знают, как работать с DOM’ом — им легче прицепить XML парсер
            2. расширения — кто знает, во что конфиг превратится дальше

            Тут уместно привести пример Magento — чисто PHP’шное приложение, притом, что у PHP всегда были проблемы с XML’ем. Там каждый модуль тащить свой маленький XML, которые комбинируются в один огромный и потом используется, как конфиг. При этом никаких XSD, никаких трансформаций. Тупой текстовый файл, как конфиг апача. При том, что рядом же используются шаблоны на php, который сам по себе отличный язык описаний конфигураций.

            Что подтолкнуло людей к такой структуре конфига? ХЗ. Можно придумать много оправданий, но ни одного сколько либо серьезного кроме «на вырост».

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *