Дискуссии об осмысленности XML

> Ну да. Даже гибче отрисовки из примитивов ;)

Да. Можно манипулировать наборами базовых виджетов в необходимой компоновке. :)

> Реально применение такой схемы как раз обязывает использовать _только_ узкий стандартный набор виджетов

custom widget никто не отменял.

> А вот допустим нужно мне, чтобы количество контролов измнялось в зависимости от чего-то, что я на этой же форме ввожу в текстовое поле.

Легко. Там же в форме прописываются сигналы и слоты, в том числе и видимость виджетов. Особо запущенные случаи можно реализовать в коде приложения или custom widget.

> Есть xml-файл, описывающий форму для версии 1.1 платформы. Мы пытаемся запустить это на версии 1.0. Результат?

Покажутся все старые виджеты. Новые будут проигнорированы. Обеспечивается обратная совместимость без перепрограммирования.

> Пример Firefox показывает, что xml _никак_ не помогает от проблем с версионностью.

Это проблемы Firefox, не находите?

> Применение схемы с xml-layout приводит к тормозному GUI.

Почему у меня приложения Qt/KDE работают шустрее, чем Tk?

> а парсить и переделывать DOM на каждое движение мышки на три пикселя....

Вы только под Windows пишите и с менеджерами компоновки никогда не связывались? Тогда понятно. :)

> Мне нужно размещать примитивы, но так чтобы они при движении пытались по возможности "прилипнуть" к сетке.

См. менеджеры компоновки. Похоже, вы это пропустили. :)

еще раз вмешаюсь...)

>Приходит сообщение.

в связи с чем у меня "два вопроса и один тезис"(ц)

>Когда есть валидация, в момент прихода сообщения мы знаем о том, что оно имеет правильную структуру

1. момент прихода - значит ли это, что все сообщение _принято_целиком_? Или есть возможность принять решение отвергнуть/нет сообщение ДО его получения? (как бонус, нет - так нет))

> Можно посмотреть на publicID, и еслиы мы его не поддерживаем сразу дать отбой. Но нам могут прислать ложное сообщение с нужным publicID, но несоответствующим схеме content'ом.

2. Но нам могут прислать НЕложное сообщение вообще без каких-либо ID, несоответствующим схеме, но ОЧЕНЬ нужным content'ом...

(только не пинать - я преснасно пониманию, что "в лоб" задача не решается никак, а существующие решения таки допускают ложные срабатывания...)

Конечно, можно отправить отправителя в эротик-тур - требовать от разработчика его инструмента тщательного соблюдения формата...

(представим, что сообщения идут в формате smtp. И что делать, если Аутлук некорректно формирует поле message-ID, а любимый всеми Бэт - не ставит кодировку для поля Subject?)

Собственно вопрос в том, есть ли гарантия, что "высокие договаривающиеся стороны" не забьют на требования вновь разработанного формата??? (имхо - новый формат создается, хоть и в обертке "xml")

Теперь тезис). Могу только повторить: разруха - в головах. Большинство технических проблем решается организационными методами. Это проще и эффективней. Создалось впечатление, что внедрение xml - желание решать оргвопросы техническими средствами.

> Создалось впечатление, что внедрение xml - желание решать оргвопросы техническими средствами.

Нет, внедрение XML - путь с наименьшим сопротивлением когда довольны все (кроме лисперов, конечно). :)

>Нет, внедрение XML - путь с наименьшим сопротивлением когда довольны все (кроме лисперов, конечно). :)

Если это не шутка - то как-то бездоказательно... Вы можете гарантировать на 100%, что если сообщения электронной почты поместить в обертку xml, то все почтовые программе тут же начнут отпавлять сообщения, кторые "имеет правильную структуру и содержит всю необходимую информацию"???

Кстати - путь _куда_ ?

> еще раз вмешаюсь...)

Да ладно, чего уж там :)

> момент прихода - значит ли это, что все сообщение _принято_целиком_?

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

> Или есть возможность принять решение отвергнуть/нет сообщение ДО его получения?

Теоретически да, ты можешь начать SAX parsing XML потока, не дожидаясь получения всего сообщения, по мере поступления данных зависая в read, из которого если что можно вывалиться по timeout.

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

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

> Но нам могут прислать НЕложное сообщение вообще без каких-либо ID, несоответствующим схеме, но ОЧЕНЬ нужным content'ом...

Отключить валидацию и проверить все руцями (с допуском атрибут туда, атрибут сюда, плюс-минус элемент) в ходе parsing'а или после, уже по DOM'у??? :)))

Но сейчас же набегут "А мы вот говорили!", "Overhead!".

Провокатор :)

> Конечно, можно отправить отправителя в эротик-тур

Не худший вариант. Если я не ошибаюсь, то причиной того, что сообщения SIM в Gaim отображаются с HTML mark up (возможно сейчас уже исправлено), является как раз-то, что Gaim написан четко в соответствии со стандартами, и кладет с пробором, на всех, кто их хоть как-то игнорирует.

В случае с messageID, я не в курсе кого это напрягает (в 97-98 годах приходилось писать свой почтовый клиент и сервер, с Outlook тестил все ОК было). А вот неустановка charset для Subject (да и остальных полей в том числе From, To), давала некрасивые для пользователя результаты - тело в одном charset, headers - в другом. Читаешь заголовки, не понимаешь текст. Читаешь текст, а в заголовках всякая бНОПНЯ.

Тогда я навозился с этим по самое не хочу. Вроде реализовал все RFC тютелька в тютельку. Ушло в тестирование и началось... "Прислали письмо из Outlook Express а оно не читается!" и пошло-поехало. На машине стояло 11 почтовых клиентов, все что смог на тот момент найти (с доступом в Сеть туго было, шарился по раскладкам с компакт дисками). Как я материл разработчиков! После этого, предпочитаю придерживаться стандартов, чтобы меня не вспоминали и не икалось :)

> Собственно вопрос в том, есть ли гарантия, что "высокие договаривающиеся стороны"

Гарантии нет, но задача разработчиков стандартов (чуть ниже будет детальнее) сделать стандарты/форматы таковыми, чтобы не возникало желания от них отходить.

> Могу только повторить: разруха - в головах.

Я понял о чем ты. Это само собой.

> что внедрение xml - желание решать оргвопросы техническими средствами.

Я думаю, тут целый комплекс средств, в том числе и психологические. "Все, с понедельника начинаю новую жизнь! С утра на зарядку, бросаю курить и пр.". Так и тут: "Все, переводим все на XML! С нуля!".

В какой-то мере это и организационно проще, потому что вернуться из состояния разрухи к высокой организации и соблюдению стандартов нереально (попросить MS исправить баги в Outlook, и проапгрейдить всех пользователей кто сидит на старых версиях?), по крайней мере, я не вижу как это сделать. Есть идеи (сталинизм не предлагать, оставим это для Китая, у них там свой Интернет скоро будет, дай им волю они и протоколы в порядок приведут, но в мире у нас демократия :/)?

Есть радикальный путь. То есть, грубо говоря надо заставить разработчиков все переписать и чтобы пользователи на это все перешли. Понятно что не все так просто, и 700+ сообщений в этой ветке тому подтверждение :) Но для этого, нужна хорошая мотивация как для разработчиков (упрощений разработки) так и для пользователей (экономия средств). Вот умные дядки в ИБМ и Ко. сидят и придумывают. Мусор тоже случается, но есть и достаточно много хороших вещей.

ИМХО это единственный рациональный (но от этого он легким не становится) путь.

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

У меня любимая игра тетрис, мне для нее CGA адаптера вполне достаточно (ладно VGA, с глазами и так плохо). Но это же не повод говорить что ATI и nVidia - отстой, выброси свой акселлератор, возьми классный ISA-шный Trident и так далее :)

опять к вопросу о docbook

Я наконец-то осознал для чего крупным компаниям нужен XML: XML - это интерфейс для работы с закрытыми проприатными форматами.

С самими форматами работать нереально или крайне тяжко, а при наличии транслятора good enough с фиксеньем багов и изменениями в случае смены версии проприатного формата жизнь становится so so.

То есть, это способ растянуть жизнь таким несвободным образованиям с минимальными затратами на их поддержание.

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

В любом случае зло от закрытых стандартов.

> Если это не шутка - то как-то бездоказательно...

Ранее по треду уже несколько раз доказывали. Но разве "лисперы" хоть что-нибудь слышат? :)

> Вы можете гарантировать на 100%, что если сообщения электронной почты поместить в обертку xml, то все почтовые программе тут же начнут отпавлять сообщения, кторые "имеет правильную структуру и содержит всю необходимую информацию"???

В отличие от нынешнего бардака с RFC наверняка смогут. :)

> Кстати - путь _куда_ ?

Путь в светлое будущее без геморроя. :)

> Теоретически да,

Оххх...

>Провокатор :)

гыы)) Зато ответ внятный получил! ))

> В случае с messageID, я не в курсе кого это напрягает

это напрягает тех, в отношении чьих сообщений "сделаны выводы" каким-нибудь спам-атсасином :)

поэтому не всегда возможно "Отключить валидацию и проверить все руцями", а тем более послать )).

> Собственно вопрос в том, есть ли гарантия, что "высокие договаривающиеся стороны"

> Гарантии нет, но

> Я думаю, тут целый комплекс средств, в том числе и психологические. "Все, с понедельника начинаю новую жизнь! С утра на зарядку, бросаю курить и пр.". Так и тут: "Все, переводим все на XML! С нуля!".

т.е. - псхологически более комфортно будет - раздавать звездюлины кодерам-рас^^ям?! ))) жжош б/п! но с этим я согласен 100%! )

>В какой-то мере это и организационно проще, потому что вернуться из состояния разрухи к высокой организации и соблюдению стандартов нереально ?

ну а что, более реально попросить всех забить на smtp и перходить на альтернативный (xml?) протокол?? ;)

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

ревность тут ни причем. вопрос в одонм - сколько стоит сменить привычки?

>Есть радикальный путь. То есть, грубо говоря надо заставить разработчиков все переписать и чтобы пользователи на это все перешли.

> Но для этого нужна хорошая мотивация

>умные дядки в ИБМ и Ко. сидят и придумывают.

дык они придумали уж! Мотивация - что надо! каждому неофиту - по 20 уе! )) а лучше - по 200! )))

> В любом случае зло от закрытых стандартов.

Вывод поддерживаю, с предпосылками не соглашусь. :)

> XML - это интерфейс для работы с закрытыми проприатными форматами.

На самом деле нет. По моим наблюдениям, это не интерфейс, он их вытесняет из бизнесс-процессов, с трудом, но вытесняет.

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

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

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

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

Например, для PDF используется dsssl, для HTML - perl, еще где-то python и так далее. Для того чтобы написать custom решение, необходимо чтобы разработчик изучил все эти техники. В случае с XML зачастую достаточно одного набора инструментов, так как исходный формат относительно унифицирован.

Это мое ИМХО. Возможно оно диктуется нехваткой знаний. Я детально не знаком с промышленными процессами подготовки документации в "доXMLную эру" (до 98-99 у меня была другая специализация), то есть мне сложно сравнивать. Но я базируюсь на какой-то аппроксимации исходя из общего представления которое я имел, информации полученной в ходе этой дискуссии и пр.

>И все равно, это не гарантирует того, что не найдется нескольких сторон, каждая из которых выбрала отличный от других свободный формат.

В любом случае любая из этих сторон может разобраться с другим форматом - им не надо покупать для этого инструменты. Даже те, кто жить не может без kde-help, если прижмёт, наберут man и info. И всегда эти man и info будут читаемы и доступны.

Критична именно принципиальная возможность.

>Что касается отображения, то оно тоже не всегда идеально, а главное оно требует подстройки под себя (ну не будут же все книги в мире издаваться с default'ными стилями).

Собственно говоря, а почему нет? Это разве секрет? Оформление это тоже часть кода, как и текст.

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

Ааа, в 98ом такая проблема не стояла :/

> ну а что, более реально попросить всех забить на smtp и перходить на альтернативный (xml?) протокол?? ;)

Тоже нет. SMTP вообще прост как двери, там сложно что-то сломать. Проблемы которые я описывал они в формате сообщения (RFC 822 вроде) и MIME (2045-2049), тут можно и поменять, хотя это уже устоявшийся стандарт. Тут как в шахматах, все варианты ошибок уже просчитаны и на них всех есть решения :)

Но и в нем обнаружился изъян, тот который ты упомянул - СПАМ. Не факт, что это проблема именно протокола. Может DNS, может еще чего. Склоняюсь, что всего понемногу. И пошло поехало: black lists, domain keys... и что-то пока никак. Все зубры думают, а мы ждем.

Основная проблема перехода, о котором ты говоришь - масштаб. Не удивлю наверное :), но я тоже не вижу как это можно сделать, сижу жду вместе с остальными. Получается, и порядок навести сложно и выбросить все сложно.

Что-то у нас слишком глобальная дискуссия пошла. В общем, в более мелких масштабах от XML пользу получить можно, в масщтабах Сети его возможности еще плохо изучены :)

> ревность тут ни причем. вопрос в одонм - сколько стоит сменить привычки?

Да какая разница, личные можно и не менять. А стоимость смены привычек на рабочем месте за тебя посчитают. Но я и не призываю менять. Я говорю о _безосновательных_ (то что я называл невежество) нападках на тех, кто меняет их добровольно.

У нас в институте сформировались группы сишников и паскалистов, между которыми периодически велись holy wars. И вот один сишник завидев у соседа по парте одну из первых книжек по Delphi, попросил на денек почитать. На удивленный вопрос "Зачем?" ответ был "Врага надо знать в лицо!". :)

>В отличие от нынешнего бардака с RFC наверняка смогут. :)

Дану? тогда эт очень сильное кунгфу! - заменил CR уловыми скобками и все индусы стали писать безглючный код!! а от соседей-алкашей оно тоже помогает?

>Путь в светлое будущее без геморроя. :) к проктологу, чтоли?

>Ааа, в 98ом такая проблема не стояла :/

вот. ну а гарантии того, что через 2-3-5 лет не вылезут какие-либо небрежности, вполне допустимые сегодня xml не дает? ;)

>Получается, и порядок навести сложно и выбросить все сложно.

а дальше - еще хуже будет )).

> А стоимость смены привычек на рабочем месте за тебя посчитают.

увы...

>На удивленный вопрос "Зачем?" ответ был "Врага надо знать в лицо!". :)

:) чтож, достойно!)

> ну а гарантии того, что через 2-3-5 лет не вылезут какие-либо небрежности, вполне допустимые сегодня xml не дает? ;)

Не дает :)

> а дальше - еще хуже будет )).

Так выпьем же за наш неиссякаемый оптимизм! :)

Так выпьем же за наш неиссякаемый оптимизм! :)

непременно! ;) с тяпницей! )

> Даже те, кто жить не может без kde-help, если прижмёт, наберут man и info.

Не будут набирать! man и info уже есть в Центре справки KDE. :)

> Дану? тогда эт очень сильное кунгфу! - заменил CR уловыми скобками и все индусы стали писать безглючный код!!

По крайней мере, есть валидатор. :)

> 2 azakharchuk на Проблемы которые я описывал они в формате сообщения (RFC 822 вроде) и MIME (2045-2049).

Окститесь! RFC 822 уже depricated. Используется RFC 2822. :)

>По крайней мере, есть валидатор. :)

Вот за что люблю наших людей!))

Главное,что валидатор есть - будем валидировать! Кого, что, за что - пох, главное - валидация!

Ударим валидатором по мастурбаторам!

>> Даже те, кто жить не может без kde-help, если прижмёт, наберут man и info.

>Не будут набирать! man и info уже есть в Центре справки KDE. :)

Вы будете запускать это тяжёлое поделие по сети? Вообще-то nixы сильны именно удалённой работой. Но поколению пепси это похоже уже не понять :(

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

Учебник этот небольшой, и, что самое главное, позволяет сразу же несведущему человеку получить общее представление о XML.

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

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

http://xmlhack.ru/archives/2006/04/000151.html

> программисты, которым необходимо привить любовь к этому языку

Это уже похоже на извращение какое-то.

> Вы будете запускать это тяжёлое поделие по сети? Вообще-то nixы сильны именно удалённой работой. Но поколению пепси это похоже уже не понять :(

"Поколение Пепси" в отличие от старых ретроградов хотя бы знает и использует X-протокол, под которых KDE весьма шустро работает. :)

> Окститесь! RFC 822 уже depricated. Используется RFC 2822. Да я в курсе, только ты посмотри о каком времени я говорил, тогда их всего-то до 2500 было...

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

Я понял. XML - это религия!

>Все станет XML-ом.

>С помощью XML вы можете осуществить обмен данными даже между несовместимыми системами.

>С помощью XML обычные текстовые файлы (txt) можно использовать для публикации данных.

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

>Теперь нам остается только молиться, чтобы Microsoft и другие разработчики ПО согласились с нами.

>date="12/11/22002"

Diff для XML: http://apps.gotdotnet.com/xmltools/xmldiff/

Ну "очень" удобный и простой. Максимальный размер файлов для сравнения в 100 кб вещь совершенно обоснованная.

> Максимальный размер файлов для сравнения в 100 кб вещь совершенно обоснованная

Безусловно обоснованная, т.к. интересно что будет, если в этот _бесплатный_ Web-сервис разные добрые люди неачнут, например, заливать файлы по 200 мегабайт?

Там рядом (по ссылке Download) лежит библиотека для .Net (с исходниками на C#, документацией и примерами), в которой этого ограничения нет.

Интересная тема. Конечно, 90% воды, но... Зря я её пропустил...

> Представь, себе smart home. Вся электроника подключена к home gateway, необходим интерфейс для управления. На самом деле интерфейсов много ... пишется 1 java facade ... web service proxies ... WSDL ... в .NET ... C# интерфейс ... Helper ... WSDL ... исходный код интерфейса ... поверх него пишем логику.

То есть ты начинаешь с того, что определяешь формат сообщений для твоего коммуникационного протокола (пишешь классы "фасада").

> Готов заслушать варианты решения без SOAP, которые дадут возможность за аналогичное время разработать сервер и такое количество клиентов к нему.

Элементарно, мой дорогой Ватсон. Четыре слова: ASN.1

Описываешь формат своих PDU, компилируешь в код на нужных тебе языках, автоматически получая функции/базовые_классы для работы с данными. И все. А дальше гоняй данные между клиентами/серверами хоть в BER, хоть в DER, хоть в GSER. Хоть в XER, если без XML жить не можешь (с DTD и прочим). Причем с валидацией и прочими вкусностями практически бесплатно (по сравнению с XML -- вообще даром).

>XML-учебник.
>покритиковать его.

Не берите грех на душу - не совращайте молодое поколение с пути истинного (в данном контексте - юниксового, строкового, простого и читаемого). Кто-то купит книгу и принимет за чистую монету (раз книга 2006 года - значит вот они - современные технологии - подумав). А затем потратив много времени и имея комплекс "не зря же я потерял время, силы и пр." (не уверен - есть ли такой, но очень похоже;) - потом будут лезть на амбразуру и толкать это всюду.
Лучше переведите что-то типа "Linux Programming by example" Роббинса, где как раз говорится о создании масштабируемых программ на С (кстати от мейнтейнера gawk) или какую-нибудь он-лайн литературу по идеологии классического юникса, а не то что туда стали нести сами знаете откуда. Ведь мир - это базар: продаётся всё (потом множество так называемых новых технологий и фреймворков - это эксперименты, не сказать - экскременты) и не надо всё покупать, блин, даже если это от бимеров, санок, и тем более - из оффтопика. Самостоятельно думать ведь тоже надо.

Никого не хотел обидеть.

Anode

> Самостоятельно думать ведь тоже надо.

Мсье - сторонник изоляционизма? Если технология хорошая - -почему бы её не взять на вооружение. Вон, MONO тоже критиковали из-за копирования оффтопичной технологии. А как появился FSpot и Beagle - почему-то записные критиканы заткнулись. То же самое - с XML. Посмотрите, кто против него: люди, не создающие удобных и популярных решений, затворники. Беда в Linux - не от оффтопика, а от преступного изоляционизма. Слава Богу, реальные разработчики - прагматики и фанатичный бред (всё что угодно - только не от корпораций!) слушать не будут. :)

> То есть ты начинаешь с того, что определяешь формат сообщений для твоего коммуникационного протокола (пишешь классы "фасада").

По сути да, создается GoF Facade, дабы скрыть все ненужные детали системы и на интерфейсном уровне оставалось только необходимое.

Одно но. Это делается независимо от коммуникационного протокола. Как по мне этот шаг необходим в любом случае. Справедливости ради отмечу, что в данном случае привязка к протоколу делалась вручную.

В силу ограниченности ресурсов, использовать полновесный движок, который генерит web-service на базе фасада и обрабатывает его в run-time, не получалось. Поэтому использовался API более низкого уровня. На самом деле, это еще один слой, который пишется довольно быстро.

> ASN.1

Упоминается в этой ветке довольно часто. Решил вкратце посмотреть, что это такое. Смотрел недолго, мнение дилетантское, посему ногами не пинать...

По времени разработки, при условии ручной привязки фасада к web-service, думаю результаты таки будт сходны.

Поверхностно, прошелся по инструментам. ИМХО ситуация обстоит похуже чем c XML. Как мне показалось, толковые инструменты все платные. Среди бесплатных, чего-то уровня Sun JWSDP, Apache Axis сходу не нашел. Один набор инструментов собранных в пакет у IBM вроде попался. То есть, несмотря на всю ISO-шную стандартизацию, инструментальная поддержка похуже (тема ASN.1 + ActionScript не раскрыта вообще).

Тем не менее, остается огромная ниша для применения ASN.1 в действительно resource/bandwidth-limited решениях. Но, при 206MHz процессоре и 10Mbit Ethernet, у меня уже появляется возможность выбора, выигрыш критичным не является, к замедлению системы с точки зрения пользователя не приводит. Поэтому, я могу выбрать лучшую инструментальную поддержку, технологию с которой я лучше знаком и пр.

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

Кстати, только что вспомнил еще одну вещь - wbXML (был у нас SyncML-related проект когда-то). Стандартизирован он вроде меньше, с инструментами еще хуже (пришлось писать свое без возможности выбора, так как в мобилах он уже зашит). То есть, по нише применения он ближе к ASN. Не говорю, что лучше.

Короче, попытаюсь систематизировать все мысли, которые у меня были в ходе данной дискуссии:

- тут кто-то хотел приткнуть что-то про learning curve. У меня вот какая мысль возникла, что каждую из дуэлей: "java property files vs. XML", "TeX vs. XSL-FO", "SOAP vs. ASN" XML с точки зрения простоты изучения XML наверное проиграет.

Но при интегральной оценке, когда в сложных проектах надо использовать и то, и се, и пятое, и десятое... "объединить необъединимое" и "впихнуть невпихуемое", единоразовые затраты на изучения XML-технологий, скорее окупятся. По крайней, исходя из своего опыта, опыта своих коллег, я так думаю.

- преимущество дает так же единый синтаксис и, как следствие возможность использования XSLT. Например, гипотетическая задача генерация PDF документа с API какого-то сервиса. В случае с WSDL/XSL-FO решается гораздо быстрее, чем ASN.1/TeX. :) (Я знаю, что это очень искуственный пример, но я старался далеко от кассы не отходить).

- но это все фигня, ИМХО основная причина - это маркетинг. Это мелкомягкая классика, но тем не менее она есть. Мы можем только вопрошать почему оно так.

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

А так, есть действительно хороший стандарт, местами возможно незаменимый. Пара компаний, вложила деньги в реализацию, проспонсировала стандартизацию. И косят деньги за лицензирование своих продуктов в устройствах, которые выпускаются огромными тиражами.

Я не буду, говорить что это справедливо по отношению к ASN.1 т.к. его историю не изучал, но я наблюдал это на примере OSGi (как раз технология для всяких embedded-фиговин, автомобили, дома и пр). Из документации - спека, пару white papers, туториалы из разряда "мой первый OSGi-сервис" и одна книга от Sun, кратко пересказыващая спецификацию. На самом деле в технологии есть пару некрасивых вещей. Есть OSGi-гуру Питер Кринс, у которого своя консалтинговая компания, которая является членом OSGi alliance (читай платит членские взносы). Автор чуть-ли не половины white papers.

Пишу письмо, так и так, есть проблема, мне кажется косяк технологии, как вы думаете как лучше обойти, мы вот лучше ничего чем такое не придумали. Ответ: "Да проблема есть. Мы можем ее решить. Я могу приехать вам и провести code review и тренинг". Небесплатно естественно. Вот и все.

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

С XML проблем таких не наблюдалось. Так что не всегда при выборе решения можно опираться только на технологию, рынок тоже отыгрывает свою роль.