M>>Вот вопрос. Чем их ASN.1 не устроил?

E>a) ASN.1 совершенно не приспособлен к чтению людьми. Бинарная передача данных -- это задача ASN.1, но вот ручками там поправить что-нибудь, или хотя бы без какого-либо инструмента проверить значения в потоке данных, тут текстовые форматы удобнее. Не случайно Эрик Реймонд в своей книги "Искусство программирования под Unix" заостряет внимание на том, что текстовые форматы часто удобнее бинарных.

Тут фишка еще в том, что, ИМХО, ASN.1 можно было бы легко передавать и напрямую в тексте, то есть, не компилируя его в бинарный формат. И наоборот, ХМЛ тоже можно было бы копилировать, если бы кто-нить задался бы таким вопросом

Ну, например:
в нотации ASN.1 (до компиляции)

myQuestion FooQuestion ::= { 
    trackingNumber     5, 
    question           "Anybody there?" 
}

ASN.1 XER

<FooQuestion>
    <trackingNumber>5</trackingNumber>
    <question>Anybody there?</question>
</FooQuestion>

А теперь, внимание!
ASN.1 Defintion для этого типа данных:

FooProtocol DEFINITIONS ::= BEGIN

    FooQuestion ::= SEQUENCE {
        trackingNumber INTEGER,
        question       VisibleString
    }

    FooAnswer ::= SEQUENCE {
        questionNumber INTEGER,
        answer         BOOLEAN
    }
END

XML XSD Schema:

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
    <xs:element name="FooQuestion">
        <xs:complexType>
            <xs:sequence>
                <xs:element ref="trackingNumber"/>
                <xs:element ref="question"/>
            </xs:sequence>
        </xs:complexType>
    </xs:element>
    <xs:element name="question" type="xs:string"/>
    <xs:element name="trackingNumber" type="xs:byte"/>
</xs:schema>

Неее... ХМЛ — это зло

E>b) ASN.1, вообще-то говоря, не столь расширяем, как это может показаться. AFAIK, при проектировании протокола нужно специальным образом помечать места, в которых возможны дальнейшие расширения протокола. Что не просто. В XML-е (да и другом формате текстовой разметки), если не фиксировать жестко DTD, то можно при необходимости расширить любой тег (например, добавить в него атрибутов или дочерних элементов).

Согласно здесь:

Unlike many other syntaxes which claim to be extensible, ASN.1 offers extensibility which addresses the problem of, and provides support for, the interworking between previously deployed systems and newer, updated versions designed years apart.

Я, правда, тоже не спец

E>c) ASN.1 сразу ставит тебя перед высоким порогом вхождения. Во-первых, язык спецификаций. Во-вторых, ASN.1 компиляторы (писать вручную можно разве что ASN.1 BER, да и то не просто, а уж ASN.1 PER...). Их нужно искать, их нужно изучать, за хорошие нужно платить и не мало.

Есть такое. Но, имхо, если бы тот же W3C взялся бы за ASN.1, оставил бы его в текстовом формате, да продвинул бы его, стуация была бы иной.

E>Хотя низкий порог входжения в XML, как показал Голуб, как раз затем и приводит к необдуманному применению XML.

См. также Don’t Invent XML Languages

E>d) Насколько мне известно, ASN.1 не специфицирует отображение своей спецификации в язык программирования. Из-за этого каждый ASN.1 предоставляет собственный маппинг спецификации в классы/функции целевого языка. А из-за этого пользователи ASN.1 привязываются к производителю ASN.1 компилятора.

Ну так то же самое можно сказать и о ХМЛ

E>Так что, имхо, далеко не всегда ASN.1 является более выгодной альтернативой, чем XML. И наоборот. Хотя в некоторых случаях действительно задаешься вопросом: какого черта XML использован? Например, есть такая, имхо, маразматическая штука, как подписанный XML. Вот вместо него ASN.1 вполне мог применяться. Тем более, что области, в которых подписанный XML применяется (электронная коммерция), отнюдь не дешевые. И при разработке в них прикладных решений затраты на ASN.1 компиляторы вовсе не такие чувствительные.

Кстати, читал я описание протокола обменна данными с каим-то из payment gateways. Там народ поступил легко и просто Никакого ХМЛ. Пары ключ-значение, разделенные точками с запятыми и переводами строки. Аж глаз отдыхает

E>Плохо то, что XML раскручен, а ASN.1 нет. Я, например, про него совершено случайно узнал. Поэтому при выборе решений многие разработчики такой альтернативы XML, как ASN.1 или, скажем, скриптовые языки, даже не видят. Из-за элементарного незнания.

+1

>>> Напиши xsl-ку переводящую неудобный тебе формат в любой по вкусу.
>> Это не выход
kan>А что выход? Изучать ещё один синтаксис? Если бы каждый писал свой компилятор на каждый случай, ты бы запоминал, что в
kan>hibernate-маппингах в конце строки надо ставить ";", в ant надо ставить ".", в TestNG не надо ничего ставить, а вот в
kan>jsf надо ";", но отделить пробелом. И в итоге ты бы также "Нае...лся с ant-ом по самое нехочу", т.к. там всё не так, как
kan>в привычном тебе hibernate.
kan>Плюс поиметь все радости проблем с кодировками.

Как говорится, ню-ню

Смотрим, например, вот в небольшой список XML Languages. Их там — 600 штук. И каждый — со своим, наверняка неудобочитаемым синтаксисом. И для каждого надо писать свой, неповторимый компилятор/интерпретатор/парсер.

То, что ХМЛ — это одинаковая для всех панацея, — миф, уже неоднократно развенчанный.

См. также ответ к Re[3]: Снова XML: Just Say No to XML

Автор: eao197
Дата: 27.09.06

Мне всегда казалось, что основная проблема XML — плохое отображение на привычные структуры данных.
Т.е. "в жизни", грубо говоря, "встречаются" основные структуры данных — скаляр, вектор, словарь (и вроде как бы и все, учитывая их вложенность — элемент вектора может быть скаляром-вектором-словарем и т.п.)
А в XML — "именованный данные с аттрибутами". Отсюда вечные проблемы отображения:

[1,2,3] => <array><value>1</value><value>2</value><value>3</value></array>
или
[1,2,3] => <array values='1,2,3'>
или
[1,2,3] => <array><item value='1'><item value='2'><item value='3'></array>

то же самое и со словарями.
Т.е. для сериализации данных удобнее какая-нито хрень типа помянутого JSON или более продвинутого YAML, которые базируются именно на "естественных" для программера структурах данных.

С другой стороны, вокруг XML накоплен интересный опыт: XPath, XSD, XSLT и т.п. — это все крайне полезные идеомы (паттерны, если хотите), которые могут (и должны) быть применены к другим, более удобным языкам описания данных.

Имху, так.

Mamut wrote:

> Смотрим, например, вот в небольшой список XML Languages
> <http://xml.coverpages.org/xmlApplications.html&gt;. Их там — 600 штук. И
> каждый — со своим, наверняка неудобочитаемым синтаксисом. И для каждого
Бред. Синтаксис всех XML-based языков одинаков и стандартизован.

> надо писать свой, неповторимый компилятор/интерпретатор/парсер.
Чем обычные DOM/SAX парсеры не устраивают? А всякие хрени, генерящие код объектной модели по xsd и прочие xml-object
мапперы?
А компилятор/интерпретатор, если нужен, придётся писать в любом случае.
Часть этих 600 языков — языки разметки (FOP, DocBook, XBRL,...), для них вообще не нужно писать
компиляторы/интерпретаторы. Достаточно заюзать готовые либы трансляции в html/pdf/rtf/etc.

Mamut wrote:

> M>>Вот вопрос. Чем их ASN.1 не устроил?
> WH>Если мне не изменяет скалероз то он насквозь бинарный...
> В нем есть XER, кодирующий его в ХМЛ (веяние времени, однако )
Подумаешь, бином Ньютона. А наоборот?

Mamut wrote:

>> > Вот вопрос. Чем их ASN.1 не устроил?
> C>Ответ: назови мне 10 полностью свободных и бесплатных решений для ASN
> C>для С++, Java, Perl, PHP, C, C#.
> Ну вот в том-то и дело
Кто виноват? Что делать?

Mamut wrote:

> Кстати, читал я описание протокола обменна данными с каим-то из payment
> gateways. Там народ поступил легко и просто Никакого ХМЛ. Пары
> ключ-значение, разделенные точками с запятыми и переводами строки. Аж
> глаз отдыхает
А в какой кодировке? А как иерархию сделать? А может ли ключ содержать ";"? А может ли значение содержать перевод
строки? А как массив значений передать (список — имя/телефон, притом телефон опционален)?
Понятно, что в данном конкретном случае ничего этого, наверное, не надо. Но не надо простые случаи обобщать.
В общем уроды, могли бы заюзать url-form-encoded формат или даже csv, нет, придумали свой велосипед.

Здравствуйте, kan, Вы писали:

kan>Mamut wrote:

>> Смотрим, например, вот в небольшой список XML Languages
>> <http://xml.coverpages.org/xmlApplications.html&gt;. Их там — 600 штук. И
>> каждый — со своим, наверняка неудобочитаемым синтаксисом. И для каждого
kan>Бред. Синтаксис всех XML-based языков одинаков и стандартизован.

Это вы бред говорите. Для компьютера он может и стандартизирован, а человеку по любому все время приходится учить новый язык. XML — это лишь оболочка, как другая кодировка, не более того. Для того, чтобы использовать VoiceXML, например, придется выучить новый язык и то, что он оформлен в виде XML НИЧЕМ абсолютно тебе в этом предприятии не поможет. XML помогает только ленивым программистам, которым в падлу написать компилятор/интрепретатор для более удобной для человека формы.
А вот писать потом программы на XML языке — это ад. Я, как однажды имевший несчастье это делать, готов плюнуть в лицо любому, кто станет проталкивать убожество типа VoiceXML и прочий креатив больных на голову разработчиков.

>> Смотрим, например, вот в небольшой список XML Languages
>> <http://xml.coverpages.org/xmlApplications.html&gt;. Их там — 600 штук. И
>> каждый — со своим, наверняка неудобочитаемым синтаксисом. И для каждого
kan>Бред. Синтаксис всех XML-based языков одинаков и стандартизован.

Стандартизирован настолько, насколько буквы русского алфавита стандартизированы для русского языка — не более.

Напомню цитату

Автор: kan
Дата: 27.09.06

:

А что выход? Изучать ещё один синтаксис? Если бы каждый писал свой компилятор на каждый случай, ты бы запоминал, что в
hibernate-маппингах в конце строки надо ставить ";", в ant надо ставить ".", в TestNG не надо ничего ставить, а вот в
jsf надо ";", но отделить пробелом. И в итоге ты бы также "Нае...лся с ant-ом по самое нехочу", т.к. там всё не так, как
в привычном тебе hibernate.

Абсолютно то же самое происходит и с ХМЛем

Потому что:

<!-- version 1-->
<dataElement type="MyType">
    <publicfields>
        <field type="subType">value</field>
    </publicfields>
</dataElement>

и

<!-- version 2-->
<dataElement type="MyType">
    <field type="subType" visibility="public">value</field>
</dataElement>

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

>> надо писать свой, неповторимый компилятор/интерпретатор/парсер.
kan>Чем обычные DOM/SAX парсеры не устраивают? А всякие хрени, генерящие код объектной модели по xsd и прочие xml-object
kan>мапперы?

Потому что DOM/SAX парсеры — это хорошо. Но что делать, если verson 1 будет заменен на version 2? Тогда мне все равно придется переписывать ту часть программы, которая пользуется парсером, и перенастраивать маппер. Причем мапперы каждый используют свой формат, который опять же придется изучать с нуля. Потому что Castor несовместим, например, с JAXB

kan>А компилятор/интерпретатор, если нужен, придётся писать в любом случае.
kan>Часть этих 600 языков — языки разметки (FOP, DocBook, XBRL,...), для них вообще не нужно писать
kan>компиляторы/интерпретаторы. Достаточно заюзать готовые либы трансляции в html/pdf/rtf/etc.

А если либ нет?

В общем, нет в ХМЛ ничего такого, что делало бы его панацеей... для чего бы то ни было. Просто еще один формат данных, да еще не совсем удачный

kan>Понятно, что в данном конкретном случае ничего этого, наверное, не надо. Но не надо простые случаи обобщать.

Так бОльшая часть случаев как раз укладывается в простые

kan>В общем уроды, могли бы заюзать url-form-encoded формат или даже csv, нет, придумали свой велосипед.

Ну, так там примерно CSV и получился

>> M>>Вот вопрос. Чем их ASN.1 не устроил?
>> WH>Если мне не изменяет скалероз то он насквозь бинарный...
>> В нем есть XER, кодирующий его в ХМЛ (веяние времени, однако )
kan>Подумаешь, бином Ньютона. А наоборот?

Наверняка Он же ж все же протокол передачи данных

>>> > Вот вопрос. Чем их ASN.1 не устроил?
>> C>Ответ: назови мне 10 полностью свободных и бесплатных решений для ASN
>> C>для С++, Java, Perl, PHP, C, C#.
>> Ну вот в том-то и дело
kan>Кто виноват? Что делать?

Маркетинг виноват Подняли бы вокруг него столько же шумихи, сколько вокруг ХМЛ, то же самое было бы

Quintanar wrote:

>> > Смотрим, например, вот в небольшой список XML Languages
>> > <http://xml.coverpages.org/xmlApplications.html&gt;
> <http://xml.coverpages.org/xmlApplications.html&gt;&gt;. Их там — 600 штук. И
>> > каждый — со своим, наверняка неудобочитаемым синтаксисом. И для каждого
> kan>Бред. Синтаксис всех XML-based языков одинаков и стандартизован.
>
> Это вы бред говорите. Для компьютера он может и стандартизирован, а
> человеку по любому все время приходится учить новый язык. XML — это лишь
> оболочка, как другая кодировка, не более того. Для того, чтобы
> использовать VoiceXML, например, придется выучить новый язык и то, что
> он оформлен в виде XML НИЧЕМ абсолютно тебе в этом предприятии не
> поможет. XML помогает только ленивым программистам, которым в падлу
> написать компилятор/интрепретатор для более удобной для человека формы.
> А вот писать потом программы на XML языке — это ад. Я, как однажды
> имевший несчастье это делать, готов плюнуть в лицо любому, кто станет
> проталкивать убожество типа VoiceXML и прочий креатив больных на голову
> разработчиков.
Тот пример voiceXML что тут приводился, действительно бред. Но это не вина xml, а тех, кто этот voicexml придумывали,
ибо люди не удосужились прочитать рекомендации как писать языки, так что ещё неизвестно, что бы они наворотили без
использования xml.
До абсурда можно довести любую идею.

Mamut wrote:

> *Абсолютно* то же самое происходит и с ХМЛем

> <!-- version 1-->

> Это уже два абсолютно разных синтаксиса, каждый из которых надо учить. И
Это семантика, не путаем, плз. Редактор обученный xsd-шкой поможет в данном случае.

> помнить их различия, и орать матом на разработчиков, если в новой версии
> они перейдут с одного синтаксиса на другой (а такое тоже бывает).
Если не сделают xsl-ки для конвертирования из старой версии — наорать, да самому наваять за пол часа.

>> > надо писать свой, неповторимый компилятор/интерпретатор/парсер.
> kan>Чем обычные DOM/SAX парсеры не устраивают? А всякие хрени, генерящие
> код объектной модели по xsd и прочие xml-object
> kan>мапперы?
> Потому что DOM/SAX парсеры — это хорошо. Но что делать, если verson 1
> будет заменен на version 2? Тогда мне все равно придется переписывать ту
> часть программы, которая пользуется парсером, и перенастраивать маппер.
> Причем мапперы каждый используют свой формат, который опять же придется
> изучать с нуля. Потому что Castor
> <http://www.castor.org/xml-mapping.html#3.-The-Mapping-File&gt;
> несовместим, например, с JAXB
> <http://java.sun.com/webservices/docs/1.4/tutorial/doc/JAXBUsing3.html#wp150676&gt;
БезXMLные альтернативы в студию. Да чтобы с совсместимостью, какую вы тут требуете.

> kan>А компилятор/интерпретатор, если нужен, придётся писать в любом случае.
> kan>Часть этих 600 языков — языки разметки (FOP, DocBook, XBRL,...), для
> них вообще не нужно писать
> kan>компиляторы/интерпретаторы. Достаточно заюзать готовые либы
> трансляции в html/pdf/rtf/etc.
> А если либ нет?
А если компьютера нет? Свой паять?

> В общем, нет в ХМЛ ничего такого, что делало бы его панацеей... для чего
> бы то ни было. Просто еще один формат данных, да еще не совсем удачный
А он и не панацея. Есть места где он неприменим, но те наезды что звучат здесь — мимо тазика.

Mamut wrote:

>> >> > Вот вопрос. Чем их ASN.1 не устроил?
>> > C>Ответ: назови мне 10 полностью свободных и бесплатных решений для ASN
>> > C>для С++, Java, Perl, PHP, C, C#.
>> > Ну вот в том-то и дело
> kan>Кто виноват? Что делать?
> Маркетинг виноват Подняли бы вокруг него столько же шумихи, сколько
> вокруг ХМЛ, то же самое было бы
Как ни прискорбно знать, но маркетинг обычно отражает реальные требования (тем более если учесть некоммерческое
происхождение XML с w3c.org), а не "единственно верные" решения.

Mamut wrote:

> kan>Понятно, что в данном конкретном случае ничего этого, наверное, не
> надо. Но не надо простые случаи обобщать.
> Так бОльшая часть случаев как раз укладывается в простые
И чем такая штука была бы хуже? Чем сложнее?

<payment>
  <key1>Value</key1>
  <key2>По-русски</key2>
  <key3>Ё!"№;%:?*()_+Ё!"№;%:?*()~!@#$%^&*()_+{}|<>?[\];',./</key3>
</payment>

Зато ни у кого никаких бы вопросов не возникло бы.

> kan>В общем уроды, могли бы заюзать url-form-encoded формат или даже
> csv, нет, придумали свой велосипед.
> Ну, так там примерно CSV и получился
И какого хера тогда? Вместо того, чтобы взять готовый кусок кода для работы с CSV, программист вынужден писать очередной
велосипед.

Здравствуйте, kan, Вы писали:

kan>Тот пример voiceXML что тут приводился, действительно бред. Но это не вина xml, а тех, кто этот voicexml придумывали,
kan>ибо люди не удосужились прочитать рекомендации как писать языки, так что ещё неизвестно, что бы они наворотили без
kan>использования xml.
kan>До абсурда можно довести любую идею.

Не нефига, я неправильно выразился. VoiceXML сделан очень грамотно, многое в нем неплохо продумано. Был бы очень приятный язык, если бы не xml.

Здравствуйте, kan, Вы писали:

>> В общем, нет в ХМЛ ничего такого, что делало бы его панацеей... для чего
>> бы то ни было. Просто еще один формат данных, да еще не совсем удачный
kan>А он и не панацея. Есть места где он неприменим, но те наезды что звучат здесь — мимо тазика.

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

>> <!-- version 1-->

>> Это уже два абсолютно разных синтаксиса, каждый из которых надо учить. И
kan>Это семантика, не путаем, плз. Редактор обученный xsd-шкой поможет в данном случае.

Если файл больше одной страницы текста, то ни один редактор не поможет (мне, например, влом разбираться)

>> помнить их различия, и орать матом на разработчиков, если в новой версии
>> они перейдут с одного синтаксиса на другой (а такое тоже бывает).
kan>Если не сделают xsl-ки для конвертирования из старой версии — наорать, да самому наваять за пол часа.

А оно мне надо?

kan>БезXMLные альтернативы в студию. Да чтобы с совсместимостью, какую вы тут требуете.

Таких и нет. Но и пропагандировать ХМЛ, как панацею, которая ручками, в редакторе, за полчаса, и еще неизвестно, заработает ли, тоже пропагандировать не надо

>> kan>А компилятор/интерпретатор, если нужен, придётся писать в любом случае.
>> kan>Часть этих 600 языков — языки разметки (FOP, DocBook, XBRL,...), для
>> них вообще не нужно писать
>> kan>компиляторы/интерпретаторы. Достаточно заюзать готовые либы
>> трансляции в html/pdf/rtf/etc.
>> А если либ нет?
kan>А если компьютера нет? Свой паять?

Легко!

>> В общем, нет в ХМЛ ничего такого, что делало бы его панацеей... для чего
>> бы то ни было. Просто еще один формат данных, да еще не совсем удачный
kan>А он и не панацея. Есть места где он неприменим, но те наезды что звучат здесь — мимо тазика.

Имхо, он вообще нигде не применим Для конфигов легче использовать YAML/JSON/INI, особенно, если их руками надо править, а для всего остального он не предназначен. Имхо, конечно.

M>ASN.1 XER
С таким названием, не удивительно, что они в массы не пошли