Билл Гейтс о свободном ПО

>>Также в письме отмечается важность XML как основы взаимодействия ПО в будущем.

ага, а потом M$ придумает свое расширение XML, которое будет не совместимо ни с чем, навешает пару десятков патентов, и пр, пр..

Почему то особой радости не внушают подобные заявления от билли - жопой чувствуется подвох

>the open source development approach encourages the creation of many permutations of the same type of software application, which could add implementation and testing overhead to interoperability efforts.

наоборот хорошо когда есть альтернативы, выбор...

>... зачастую создает искусственные препятствия...

интерсно это они о препятствиях для себя :)

XML ЗЛО

С нетерпением жду, когда же билли реализует обещание об зюмельных системных вызовах, тогда посмеёмся и над скорость, и над оверхедом, и над совместимостью.

Как думаете, XML стоит того ?

Можно ведь под задачу написать гораздо компактнее. А полный XML далеко не все парсеры поддерживают.

Форматы поверх него тоже часто бред, тот-же SOAP(Formatter из .NET) понимает только то что ему хочется, или я чего-то недопонял.. Да и вообще с этим ремоутингом и ихними цлр версиями полный бред..

Вот взять Google.Gmail кто смотрел, там все компактно передается JavaScript масивами, типа

[1, [22, 33], [1], 2]

Почему не взять такой формат ?

Помоему вполне удобно и разумно для тех кто знает Python/Ruby/JS..

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

XML ничего не стоит...
Уже давно (очень давно! :) придуман формат, который на многие порядки удобнее XML. Он называется "символьные выражения", или s-expressions. Например, приведённый список будет выглядеть как:
(1 (22 33) (1) 2)

Согласитесь, что-нибудь вроде
(define-form my-form (ancestor-form)
  (user-id "User ID")
  (customer-name "First & Last Name")
  ...)

выглядит внятнее, да и набирается быстрее чем

<form name="my-form" base-on="ancestor-form">
  <item>
   <name>user_id</name>
   <display>User ID</display>
  </item>
  <item>
   <name>customer_name</name>
   <display>Customer First &amp; Last Name</display>
  </item>
  ...
</form>

конечно, можно можно заменять некоторые элементы атрибутами, но существенного облегчения это не принесёт. Почему, спрашивается, надо
по [до xyz] раз писать одно и то же?

> Почему не взять такой формат ?

Парсить XML скриптом - устанешь. Если есть возможность использовать XMLHttp - это выход. Google врядли себе мог такое позволить, поскольку в IE xmlhttp - activex. Многие запрещают выполнение любых ActiveX...

пример namespace-а другого пожалуйста, включение внешнего xml документа, подобие xslt? XML рвёт всё и вся, только его можно употреблять неправильно.

> пример namespace-а другого пожалуйста,

(another-namespace:something (yet-another-namespace:other-thing ...)

>включение внешнего xml документа,

(load "other-document")

> подобие xslt?

сколько угодно лисповских библиотек - впрочем, чаще всего простых конструкций с использованием loop / dolist / mapcar etc. хватает. ну или макросы, конечно же - XSLT до этого дела как до китая раком (да, я вполне прилично знаю XSLT, и собственно благодаря ему заинтересовался Лиспом)

> XML рвёт всё и вся, только его можно употреблять неправильно.

XML - недооткрытая Америка и плохо изобретённый велосипед...

Сам по себе XML - не есть зло. Зло это когда его пихают куда ни поподя. SOAP - отстой. Есть CORBA. Многие жалуются, мол сложно - не правда. Сейчас, когда пытаются из SOAP сделать CORBA с XML - вот это уже не смешно даже... Есть такая нотация ASN.1 называется. К ней можно прикрутить любой енкодинг (даже XML) - используется огромным колличеством протоколов...

Спасибо.

>директор Microsoft

Так директор же сейчас Стив Баллмер.

ну уж как изобретённый незнаю, но либы под него можно найти подо что угодно. О "символьных выражениях" я только-что узнал ;).

В очередной раз доказано, что мир IT на 99.9% состоит из домохозяек. Ну почитайте главу Using XML to Achieve "Interoperability by Design", это даже не смешно... Печально...

Ну так и что с XML?

>>Также в письме отмечается важность XML как основы взаимодействия ПО в >>будущем.

>>ага, а потом M$ придумает свое расширение XML, которое будет не >>совместимо ни с чем, навешает пару десятков патентов, и пр, пр..

>>Почему то особой радости не внушают подобные заявления от билли - >>жопой чувствуется подвох

Они просто сделают патент на букву M и все было ваше стало наше..... =))))))

К сожалению, xml, как и java с linux сечас модно впихивать во все дырки - и куда нужно, и где это нафиг не надо. Для разминки советую покурить sf.net - куча проектов используют java,xml для простейших задач. Ну нахрена мне конфиг к программе в xml? coLinux его юзает, хотя .ini файлы на порядок удбнее читаются... Давайте вообще /etc оформим как один xml? Модно же бля! И либу на жабе накатаем.

Все это от непрофессиональности, не иначе.

to majordomo:

согласен :)

Это все семечки - вона ту одна оч. известная контора(не МС) CRM желала нам внедрять, дык там call-center по http данные дает/принимает, а остальное в xml. Знаешь как здорово? Надо ей ФИО передать - изволь xml'ку на 10Кб сгенерить. Поубивал бы.

так etc давно пора в xml

мы даж некоторые шаги в этом направлении принимаем уже

вообще все конфиги в xml давно пора, и dtd стандартные....

ага, лучше всю ФС в один зумль-файл, без подсветки...

majordomo (*) (06.02.2005 16:20:41):
>нахрена мне конфиг к программе в xml? ....
>Все это от непрофессиональности, не иначе.

cyclon *** (*) (06.02.2005 16:21:58):
>согласен :)

пупсики, а ну представьте себе конфиг чуть сложнее, чем fstab, где необходимо описать пару структур и в них по паре подструктур - вот тут вот xml и рулит. профессионалы.

device(/dev/tun0)
{
    media
        {
            duplex=full
            speed=100
            speed_q=Mbps
        }
}

Вобщем, перед тем как говорить, посмотри на то, что ДО ТЕБЯ сделали.

Ну дык надо-же что-то якобы супер новое впаривать в бесконечность.

Дело в том что отрасль IT так на самом деле не оправдывает себя как это не странно. Одним словом внедряя везде кучи компьютеров якобы увеличивается в бесконечность производительность труда - это миф. Производительность труда конечно увеличивается, но лишь в определённых областях (торговля например). И далеко не в самом производстве(нефтедобыча,машиностроение...), а в его обслужтвающей отрасли.

А вот где логику простейшую надо описать -- там зумль сосайт.

to anonymous (*) (06.02.2005 16:55:25)

ага, а потом руками это править оооччччееннньь удобно будет....

Объясни взаимосвязь "малоизвестное опенсорсное приложение" <==> xml?

В XML главное не формат (который вообще, строго говоря, pluggable). В XML главное - infoset. Если Ваши s-expressions могут его выразить однозначно (могут, очевидно, только надо ввести некоторые доп. соглашения) - они тоже могут носить гордое имя XML.

Что нормального может сказать Билл Гей...тссс ;) о свободном ПО? По-моему не чего. Как всегда, "Вы все пид@#%сы, один я Д'Артаньян" ;)

> XML ничего не стоит... Уже давно (очень давно! :) придуман формат, который на многие порядки удобнее XML. Он называется "символьные выражения", или s-expressions. Например, приведённый список будет выглядеть как: (1 (22 33) (1) 2)

Ну так XML все равно, как система понимает \n, в какой кодировке XML (в твоем случае на unix и windows пакет будет воспринят по-разному), может сразу же проверить не побился ли XML при передаче, кроме этого может осуществлять как потоковый, так и навигационный парсинг XML... То, что ты привел в качестве примера, вот это ЗЛО...

Во уделал-то так уделал :-).

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

Уважаю...

Ты не прав - это верно только если парсер умеет /r/n преобразвоать в /n и автоматически сделать перекодировку... Вобщем, любой sh/perl/python/etc скрипт сделает то же самое.

>Вобщем, перед тем как говорить, посмотри на то, что ДО ТЕБЯ сделали.
оооо блин! озарил истиной! ;) ну и чем это лучше хмеля ?
руками всё-равно неудобно, парсить такое тоже удовольствия мало, визуально редактировать нечем (потому как нестандартно)... да и... мы ведь датасет описываем, а не программу пишим, нафига нужен с-синтаксис ?

Вобщем следовала бы самому сначала разобраться, а потом уж заявлять, что XML - это однозначно "непрофессионально".

> Ну так XML все равно, как система понимает \n

В s-expressions - тоже всё равно. Whitespace.

> в какой кодировке XML (в твоем случае на unix и windows пакет будет воспринят по-разному),

Если в таких вещах есть необходимость, это вполне решается. Наиболее очевидный выход - просто юзать юникод. Так или иначе, то что в <?xml version="1.0" encoding="..."?> указывается charset, можно рассматривать, как некоторое преимущество (стандартизованность), но уж лучше бы в целях interop то же самое стандартизовать на s-expressions. С технической точки зрения тут проблем нет.

> может сразу же проверить не побился ли XML при передаче

IMHO это лучше на более низком уровне проверять. XML здесь ни при чём.

> кроме этого может осуществлять как потоковый, так и навигационный парсинг XML...

Навигационный парсинг - не проблема. Потоковый при необходимости тоже реализовать нетрудно, благо же отпарсить s-expr, это, простите, как два байта переслать. Да вообще, честно говоря, как SAX, так и DOM, такое [***], я вам скажу...

> То, что ты привел в качестве примера, вот это ЗЛО..

Нет, зло - это всё-таки XML. Избыточность. Эффект "леса за деревьями" в следствие обилия тегов. Interop? Если я схему не знаю, то какая мне нафиг разница, XML там или что-то вроде юниксовых конфигов? Костыль это для недоразвитых языков программирования, и ничего больше. Разьве что ещё инструмент маркетинга.

мне XML не нравится. в нем подсветки нет.

Небольшое сравнение XML и S-Expression:

http://www.prescod.net/xml/sexprs.html

Вот ещё кое что, нагло спёртое с с2 wiki с небольшими изменениями -
изобразите-ка на XML. Лучше выглядеть стало?

(automaton init
  (:init (c -> more))
  (:more (a -> more)
         (d -> more)
         (r -> end))
  (:end  (r -> end)))

или даже вот так

 (( Sentence -> (NP VP)	           )
  ( NP	     -> (Article Noun)     )
  ( VP	     -> (Verb NP)          )
  ( Article  -> the a              )
  ( Verb     -> eats drinks        )
  ( Noun     -> man woman dog blog ))

(последнее - из книги Paradigms of Artificial Intelligence Programming:
Case Studies in Common Lisp, Peter Norvig (Director of Search Quality
@ Google.com)

По поводу использования Лиспов для документов - см. http://www-sop.inria.fr/mimosa/fp/Scribe/ и http://www.cliki.net/Scribble

>> может сразу же проверить не побился ли XML при передаче

> IMHO это лучше на более низком уровне проверять. XML здесь ни при чём.

Не согласен. Передача на CRC в пакете - это совсем другое. Речь идет о проверке на правильность заполнения и передачи данных из различных приложений, работающих под различными платформами. При этом, кстати, внутри себя XML с данными из формы, вообще говоря может выглядеть по-разному. Но зато мы всегда можем проверить, что он валиден в терминах ХМЛ вообще, и, зная схему, можем сразу же проверить его валидность в плане содержимого. Т.е. уже на этом этапе мы гарантируем, что в наше приложение не попадут недопустимые значения для определеннных параметров. Это очень удобно!

>> кроме этого может осуществлять как потоковый, так и навигационный парсинг XML...

> Навигационный парсинг - не проблема. Потоковый при необходимости тоже реализовать нетрудно, благо же отпарсить s-expr, это, простите, как два байта переслать. Да вообще, честно говоря, как SAX, так и DOM, такое [***], я вам скажу...

Для слабых духом есть JDOM :) Что касается SAX, то есть приложения, для которых *DOM не применим вообще - потоковый парсинг огромных документов с данными, как тогда быть если ваш формат потоковый разбор не поддерживает?

>> То, что ты привел в качестве примера, вот это ЗЛО..

Нет, зло - это всё-таки XML. Избыточность. Эффект "леса за деревьями" в следствие обилия тегов. Interop? Если я схему не знаю, то какая мне нафиг разница, XML там или что-то вроде юниксовых конфигов? Костыль это для недоразвитых языков программирования, и ничего больше. Разьве что ещё инструмент маркетинга.

Да, оверхед, конечно значительный, но при этом никакого леса нет - ведь XML разбор делает парсер, а не человек. Для парсера все четко и понятно. А вот пример конфигов вообще супер - очень многие приложения переходят на XML-конфигиги именно потому, что пользователю можно выдать гораздо более внятное сообщение об ошибке, чем просто "Ошибка в конфигурационном фале. Загрузить резервную копию?" При этом, даже самый неискушенный пользователь может проверить корректность XML в любом броузере!!!

> К сожалению, xml, как и java с linux сечас модно впихивать во все дырки - и куда нужно, и где это нафиг не надо.

ну-ка пример куда МС пихает линух с жабой ?

Скоро он придумает не только стандарты, но и дойдёт до того, что программа должна быть представлена в максимально понятном виде (в виде исходного кода). Году эдак в 2010-ом.

В последние пол года мы пытались нанять на работу программера, специфика в том, что по политическим мотивам мы должны нанимать толко через одну специальную фирму (судя по всему кто-та получил новый BMW или мерс). Я проинтервьюревал ~60 индусских XML архитекторов, бля на резюме у всех золотые XML горы, в реалности никто не мог в SQL три таблицы соеденить, я не говорю про то, что половина не понимала разницы между порцессом и программой ...

Так, вставлю свои 5 копеек.
Был у меня проект разработать грамматику для генерации любого PDF и векторной графики (основные примитивы - некий прприетарный аналог SVG).
Получились огромные DTD, но так как XML - кастрированный SGML - то я столкнулся с его явной слабостью в проверке (validation). Пример - в XML удалена поддержка проверки отсутствия элемента (elements exclusion) и я вынужден был делать эту проверку в коде anyway. И если куча логики у меня всё равно в коде, а в dtd я делаю комментавии: это не делать, это подразумевается так итд (я не говорю об отсутствии/ущербности control structures: попробуйте пописАть более одного вложенного 'if' а Ant например) - то возникает вопрос - а зачем я плачу такой оверхед за трудно-читаемый человеком ограниченный недоязык?

Если уж говорим о декларативности, а не процедуральности, то набор правил, как в прологе - будет проще (пример правил - ipchains).

Приведу пример такого декларативного подхода для описания иерархической структуры:

title=record
person.name.first=Vasya
person.name.second=Chapayev
person.age=100

Заметьте что в этом случае - каждая строка как и в ipchains правилах - отдельна, читаема человеком, не надо иметь большой стек/память для глубоких структур, легче добавить скрипт итд.

Представим стрим - миллионы записей. xml сожрёт всё - без incremental parsing, а последнее практически очень сложно. А поток вышепреведённых записей может быть хоть гигабайты. Скрипт.

имхо.

Ничто не является панацеей и всему свое место.

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

> Ничто не является панацеей и всему свое место.

а еще говорят всякой твари по паре.

так глядишь скоро МС изобретет лисп с зумль-синтаксисом и настанет всем шастье

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

>ага, а потом M$ придумает свое расширение XML, которое будет не >совместимо ни с чем, навешает пару десятков патентов, и пр, пр..

Погугли про XAML - eXetnded Avalon Markup Lang. - появится с Win Longhorn

http://longhorn.msdn.microsoft.com/lhsdk/core/overviews/about%20xaml.aspx