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

> > Туда же, кстати, и XSLT.

> Эт ты зря.

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

> ок, ты изменяешь саму оригинальную переменную. наверное будет работать. Некошерно, правда, говорят goto. Впишут завтра в какой-нибудь верификатор - не давать добро на код, имеющий goto - к тому ведь идёт ;)

У, йопт...

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

а я не хочу работать парсером и искать парный таг: много процессорного времени занимает image-recognition and matching
скрипт - менее ошибкообразующий

>Почему бы в винде вместо реестра оракл не держать?
Подозреваю что это ускорит винду :) Все можно довести до абсурда, думаю что XML конфиги не самая плохая идея, но будет к месту очевидно не везде.

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

а они есть вторая ипостась. Дата без поведения - не_полно

>Тормоз
без этого можно и обойтись - в культурной среде

> а я не хочу работать парсером и искать парный таг: много процессорного времени занимает image-recognition and matching скрипт - менее ошибкообразующий

Угу. Только вот в таком скрипте можно намешать обращений к совершенно разным объектам в произвольном порядке, и потом пойди разберись, кого куда add'или, и все ли присваивания для одного конкретного объекта ты разглядел...

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

согласен на 100%. Ненавижу подход XSLT, хоть к сожалению надо им увы пользоваться. Это надо-же было такое придумать...

> а они есть вторая ипостась. Дата без поведения - не_полно

Не всегда имеет смысл мешать в одну кучу данные и поведение. И даже там, где это надо, можно продолжать использовать XML - просто надо использовать его _только_ для данных, а не для поведения. Например, при задании фильтра никто же не мешает воспользоваться SQL-запросом в качестве содержимого тэга <filter>, вместо того, чтобы изобретать свой мини-язык со всяческими <query> и <order>.

> Угу. Только вот в таком скрипте можно намешать обращений к совершенно разным объектам в произвольном порядке, и потом пойди разберись, кого куда add'или, и все ли присваивания для одного конкретного объекта ты разглядел...

дык что-что, а ух скрипт-то он однозначный, сохраняет последовательност, нумерацию строк. А вот как раз с XSL и братия - порядок никак не определён и как там понапишет разработчик чёрного ящика - то и получим

Дык, определяем тип данных. И всё!

> дык что-что, а ух скрипт-то он однозначный, сохраняет последовательност, нумерацию строк.

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

> дык что-что, а ух скрипт-то он однозначный, сохраняет последовательност, нумерацию строк. А вот как раз с XSL и братия - порядок никак не определён и как там понапишет разработчик чёрного ящика - то и получим

Так, стоять... порядок подэлементов внутри элемента можно игнорировать (когда он не является значащим), а можно и нет. В чем проблема?

> Дык, определяем тип данных. И всё!

что - все? определенный тип данных магически расставит строки в нужной последовательности?

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

Что и имеем в XSL и полдобных. (У моего руководителя PHD по этому поведению рядом с данными - он меня убедил ;)

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

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

<TegA>
  <TegB>
    Something
  </>
</>

Или даже: (TegA (TegB (Something)))

Но если подумать, это всего лишь еще один уровень избыточности,
позволяющий легко проверить целостность данных, чтобы не допустить
<a><b></a></b>.

> Или, скажем, мне очень нравится концепт, заложенный в XSLT, но его синтаксис раздражает поболее, чем в VB6.

Порезали бритвой, чтобы не плодить "ублюдков"?

> Все же внятного объяснения имеющемуся "углоскобочному" синтаксису XML пока здесь никто так и не дал...

Наследственность.

> порядок подэлементов внутри элемента можно игнорировать (когда он не является значащим), а можно и нет

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

>> Тормоз
> без этого можно и обойтись - в культурной среде

Предпочитаю не играть в политкорректность.

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

Я тебе ОЧЕНЬ советую, посмотри на ASN.1. Это тоже _только_ данные.

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

А ты отдели данные, их представления и поведение. Все сразу встанет на свои места.

короче это фундаментальная проблема.
Либо красиво (данные от кода отделены) и трахаемся с несовместимостями, целостностью и занимаемся псевдо-работой
либо имеем данные рядом с кодом (в предельном случае - любой язык), но тратим время потом - на делание репортов, снапшотов данных. Так или не так?
А можно сделать умно - 2 параллельных стрима из синхронизированных слотов данные - поведение, данные - поведение
и не надо парсить
обозначим строки с поведением, начинающимися, например с какого-то символа. И применяем подход строк как выше.
При желании получить чистые данные - выкинем поведение (строки, начинающиеся на тот символ)

как вам такой подход?

>Я тебе ОЧЕНЬ советую, посмотри на ASN.1. Это тоже _только_ данные.

ща посмотрим. не охота надолго отходить ;)

> ща посмотрим. не охота надолго отходить ;)

Загляни в первый попавшийся MIB. ;)

> Угу. Только вот в таком скрипте можно намешать обращений к совершенно разным объектам в произвольном порядке, и потом пойди разберись, кого куда add'или, и все ли присваивания для одного конкретного объекта ты разглядел...

>определенный тип данных магически расставит строки в нужной последовательности?

#type a = int * float;;

# let (c:a) = (2.,1);;

Characters 12-18:

let (c:a) = (2.,1);;

^^^^^^ This expression has type float * int but is here used with type

a = int * float

# let (c:a) = (1,2.);;

val c : a = (1, 2.)

Вот тебе расстановка строк в примитивном виде.

проблема XSL, что они отделены, но уж очень далеко.
И на соединение - нужен парсинг либо оба дерева (xml и xsl) в памяти.
А если они - ну очень большие. Как xsl будет по xml лазить ("и это всё моё!") и его править/модифицировать если первый _очень_ большой.
Скрипт же - как тюрингова машина: взял кусочек, обработал согласно коду лежащему тут-же, сдвинулся, обработал дальше.

Дык человек такой-же с его 7 объектным кешем и одним тредом ;)

Код и данные обладают единым, списковым представлением. В зависимости от контекста один и тот же список может быть воспринят как код или как данные.

как вам такой подход?

>Код и данные обладают единым, списковым представлением. В зависимости от контекста один и тот же список может быть воспринят как код или как данные.

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

а линк хороший не кинешь? а то уже 5 минут какую-то рекламму читаю...

> а линк хороший не кинешь?

http://www.google.com/search?q=ASN.1

злой ты

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

> злой ты

Это ты ленивый.

Самая _первая_ ссылка ведет на http://asn1.elibel.tm.fr/en/, откуда можно почерпнуть _всю_ необходимую информацию.

PS. Что еще раз подтверждает тезис о нежелании детей учиться, вечно им хочется, чтобы носом ткнули...

естественно ленивый - как и всё прогрессивное человечество.
Если кто-то уже проделал работу или знает лучше тему - почему не спросить - если это не доставит хлопот и человек не жадный. В обмене знаний - сила :)
потом я не на олимпиаде и срочно понимать по BNF-like описаниям как же далеко отстоят данные от поведения - да лень просто ;)

> Порезали бритвой, чтобы не плодить "ублюдков"?

Вот именно, что резали-резали по живому, да все равно такое и выродилось - не просто ублюдок, а монстер! =)

> > Все же внятного объяснения имеющемуся "углоскобочному" синтаксису XML пока здесь никто так и не дал...

> Наследственность.

И что в этом хорошего?

> это да, согласен, но нет управляющих структур которые надо-бы здесь-же, чтобы потом ещё и ещё не парсить (или - не держать в памяти, что эквивалентно)

Объясни, зачем мне управляющие структуры в куске xml'я, описывающем, скажем, некоторую запрошенную мной выборку книг из online-библиотеки?

> Либо красиво (данные от кода отделены) и трахаемся с несовместимостями, целостностью и занимаемся псевдо-работой

Не совсем понятно, как из первой посылки (отделение данных от кода) вытекают последующие (несовместимость, проблемы с целостностью). Можно поконкретнее?

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

Вообще на доступ к данным и в особенности их модификацию. Да и все-таки парсер будет попроще, чем интерпретатор...

Кстати вот интересный пример из жизни. Кто пишет на майкрософтовской платформе, имел возможность проследить эволюцию форматов хранения дизайна форм. В VB6 это был отдельный текстовый файлик с собственным текстовым, но легко читаемым форматом (_не_ XML). В .NET - описание формы на лету генерится в код; вот кстати, как хороший комментарий к читабельности - можете попробовать посмотреть на этот самый код, прикинуть, как можно было бы то же засунуть в XML, и сравнить... А нынче - Avalon и XAML, то есть пришли опять-таки к XML'ю. Я далек от мысли о том, что ребятам из MS "виднее всех", но что-то в их метаниях есть...

>И что в этом хорошего?
так как xml - subset sgml, то старый код (написанный для sgml) продолжал работать

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

>Не совсем понятно, как из первой посылки (отделение данных от кода) вытекают последующие (несовместимость, проблемы с целостностью). Можно поконкретнее?

идеальное отделение согласно рекламмным роликам - это когда в нос тычут отдельными данными (без единого аттрибута стиля) и отдельным стайл-шитом , определяющим, как показать эти данные. В MVC терминологии - View здесь XSL и Controller - связан спецификацией и не есть степень свободы. (Model - это xml естественно). Обычно под отделением менеджерам понятно физическое отделение, чтобы трясти двумя файлами или кусками бумаги. Но для того чтобы наложить этот стиль на данные, контроллер должен изрядно потрудиться парсируя оба и делая матченье.
Если все пары винтиков-гаечек после покупки (парами) не рассоединять и не путать в общую коробку - то не надо будет потом искать ответную часть, будем брать сразу нужную пару. Матчить потом - долго и дорого.
понятнее?

по-моему все идут с толпой. Раз все так - значит в этом сила. Ну а раз все - это стандарт. ISO OSI стек тоже преподавался как правильное будущее (в книгах таненбаума по сетям), но TCP был имплементирован реально и стал реальным стандартом. А в случае с xml столько теоретиков-бездельников во всяких стандартологических институтах карпело над стандартами (имхо) когда много денег в индустрии ходило (90-е), вот и сделали реальным стандартом монстрика - во всём.
Теперь закон Мура уже тормозит пару лет и надо снова думать об оптимизациях, но всё - _стандарт_

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

ASN.1 -- это стандартный (ITU-T) язык формального описания данных.

На нем описывается структура данных, в стандарт входят и способы
кодирования для передачи в потоке октетов.

Например, я пишу такой PDU:

DEFINITIONS ::= BEGIN
  Cards ::= SEQUENCE OF {
    card SET {
      name    VisibleString (SIZE (1..32)),
      number  Integer DEFAULT 0,
      props   CHOICE {
        num     INTEGER,
        str     VisibleString }}}
END

Я могу его откомпилировать для применения, например, в C (C++, Java,
etc), и получу примерно такой .h с необходимыми мне структурами
(конечно, упрощаю для ясности):

struct card {
  char  name[32];
  int   number;
#define props_num 0
#define props_str 1
  int   props_type;
  union {
    int   num;
    char *str;
  } props;
};
typedef struct card card;
typedef card* Cards;

Затем я работаю с этими структурами в своей программе. Если необходимо,
использую библиотечные функции для кодирования данных в PER/BER/DER/CER/XER.
Или для заполнения структуры из потока кодированных данных. Например,
на вход может поступить следующий кусок в XER:

<Cards>
  <card>
    <name>Card 1</name>
    <number>100</number>
    <props>
      <num>123</num>
    </props>
  </card>
  <card>
    <name>Card 2</name>
    <number>7</number>
    <props>
      <str>some text</str>
    </props>
  </card>
</Cards>

И он будет декодирован и размещен в предоставленные переменные. Надеюсь, понятно?

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

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

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

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

спасибо за инфо.
2 вопроса.
Почему корба не катит с её IDL?
Те данные могут быть стримом, без конца и начала?

вообще надо будет посмотреть повнимательнее надосуге

во, придумал аналогию.
Мне вот надо было метадату для архивов сохранять (для большой-такой файлопомойки). Можно начать пихать в базу пути и соответствующая им мета-дата. Но мы получаем проблему синхронизации (consistency) для каждого пути, так как одна и та-же структура (в случае xml/xsl - это ID) присутствует и здесь и там. То-есть если мы физически удаляем из файловой системы файл - мы должны не забыть удалить соответствующий ему мусор из базы. Есть второй способ. Как в CVS или svn - иметь файлы здесь же, в той же дире, не отходя от кассы. Стёрли сам файл или диру - удалили локальную базу.
xml/xsl - это путь 2х деревьев с избыточной информацией.
путь cvs/svg же чистится очень просто:
find -type d -name CVS -exec rm -rf {} \;
и вот вам данные (в моём случае - диры и файлы) - в чистом виде, без метадаты.
Дык почему они (эти то там штаны в w3c просиживал) не поставили рядом с каждым куском (тагом - если хотите), рядом, кусок стиля, который по ID можно было-бы заменить 's//'
Это даже если уж идти дорогой нелюбимого мной маркапа.

скрипт же в слотах - можно представить себе как <script> внутри html. Можно не обращать на него внимания, пропускать - и получите чистую дату (если xhtml конечно;) else - и данные и поведение не так далеко.
Правда надо ещё требование корневого элемента удалить - для полного счастья, ну и не требовать закрывающихся тагов, как в multi-part form MIME ;)

и последнее на сегодня.
это наверное будет самое подходящее сравнение:
почему не отделить комментарии в коде /* */ от кода, в отдельный файл - так чище ;)
Присобачив связывающие ID/таги - как в xml/xsl ;)))

> директор Microsoft отметил, что его компания всегда старалась следовать этому принципу, тогда как движение свободного ПО зачастую создает искусственные препятствия

Вот п&#ор а!? Надо же так всё с ног на голову поставить! Что деньги с людьми делают... =) Он наверное даже сам уже в это почти верит.

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

>Согласитесь, что-нибудь вроде (define-form my-form (ancestor-form)

одно "но". "))" менее информативно, чем </define-form></ancestor-form>

В остально согласен. Но для душевного спокойствия лучше считать, что XML - это реинкарнация старого доброго Lisp'а. После этого легко впадаешь в нирванну юзания J2EE :)

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

XML <= Common Lisp.

2Anode:

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

по какой причине вы не любите XML я так же не понял

>у нахрена мне конфиг к программе в xml?

удобно. Сразу как появляются массивы.