Пятая редакция стандарта XML 1.0 несовместима с XML Namespaces 1.0

> для ХML уже сейчас есть XSLT, и конвертация возможна. Ни для бинарей, ни для INI этого нет и в помине.

Прошу занести в протокол, что _я_ не предлагал использовать INI :)

Насчет XSLT: делать язык программирования с синтаксисом XML - это надо сильно ненавидеть людей. В любом случае, использование XML как метаязыка для обмена данными вполне разумно, но в качестве сетевого протокола (SOAP) - идиотизм.

> Ясен пень XML не серебрянная пуля

...но его тем не менее суют во все дыры.

>Много всего прочитал про XML, но так и не придумал куда его всунуть в своих проектах.. разве что в биореактор.

Интересно, твои проекты видел хоть кто-то кроме тебя? Или очередной Делхи-какер?

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

- Проходите товарищ инженер в очках, не задерживайтесь, отдел выдачи патентов на вечные двигатели шестая дверь направо, вверх по коридору, 8-й этаж. СЛЕДУЮЩИЙ!

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

И кстати, FYI XML никогда не был скриптом, тем более разметки страниц. OMG! И эти люди занимаются IT!

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

Почитайте хотя-бы Крауфорда, если не хотите ничего знать про ИИ.

> ассоциативные массивы - это и есть ключ-значение.

Да ты что!

var a = [];
a["адын"] = 1;
a["дыва"] = 2;
a["тры"] = 3;

Это ассоциативный массив в жабаскрипте. Жду как оно представляется в JSON.

>{кеy1:value1,key2:value2,key3:value3}

Результат evalа этой херни будет _обжект_ и ни разу не коллекция.

>так что ты не могешь передать в ассоциативном массиве - что можешь - в ХМЛе?

В XML есть четкое разделение на атрибут и контент - чего нет в JSON.

Нарисованный мной ассоциативный массив жабаскрипта ты в JSON не представишь.

> В любом случае, использование XML как метаязыка для обмена данными вполне разумно

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

> FYI XML никогда не был скриптом, тем более разметки страниц.

На основе XML делали скрипты %) Ну а XSLT - вполне полноценный язык программирования, так что про "скрипт" недалеко от истины ;(

Т.е. ты хочешь чтобы опять как в 90-е, люди обменивались файлами в бинарных форматах .xls и .doc? Спасибо, я наелся этого. Ты мог открыть .doc чем-нибудь кроме MS Word, до появления OOo?

>Документы одного приложения другим приложением не обработаются (если не следуют стандартизованной схеме). То есть имеем прямое соотвествие: схема == *.x, документ - RPC-сообщение

Они умеют прозрачно проноситься благодаря изоляции неймспейсов. В нутри SOAP передаются документы без всякой необходимости понимания самим транспортом их содержимого.

>Если вам это не надо, значит вы лепите пасочки из песка в детской песочнице и вообще можете не волноваться.

Ok. А теперь, расскажи ка дядя, нах XML тащат в конфиги софта?

> обжект_ и ни разу не коллекция.

Простите ламера, но разве коллекция - не объект? :)

> В XML есть четкое разделение на атрибут и контент - чего нет в JSON.

Нет там никакого "четкого разделения". Атрибуты есть, контент есть - а разделение от задачи зависит. некий элемент данных одни сделают атрибутом, а другие - контентом.

Речь о XML, не надо язык для трансформации сюда приплетать, он и должен быть полноценным ЯП, с циклами, условиями, рекурсиями, и т.п. Кстати, а что за скрипты делали на XML? Впервые слышу

>клади JSON в MIME - и нет проблем: MIME - протокол, JSON - иерархии. Можно без JSON. Ле

Прекрасно:

<?xml version="1.0" encoding="UTF-8"?>
<job:job xmlns:job="ns/markii/workflow/job/1.0/" name="PlayBoy#2-2008/Cover" id="1" state="move1"
                                 finished="false">
        <job:description>PlayBoy#2-2008/Cover</job:description>
        <job:sender name="r" email="x.mad.scientist@gmail.com"/>
        <job:resources tag="main">
                <job:resource>/tmp/test/EngineTestCase/files/1.txt</job:resource>
                <job:resource>/tmp/test/EngineTestCase/files/2.txt</job:resource>
        </job:resources>
        <job:resources tag="preflight">
                <job:resource>/tmp/test/EngineTestCase/files/1.checkresult.xml</job:resource>
                <job:resource>/tmp/test/EngineTestCase/files/2.checkresult.xml</job:resource>
        </job:resources>
        <wfd:workflow xmlns:wfd="ns/markii/workflow/wfd/1.0/" name="3move">
                <wfd:state name="move1" action="fs:move" type="START">
                        <wfd:property name="destination" value="/tml/test/EngineTestCase/dest1"/>
                        <wfd:transition on="success" to="move2"/>
                </wfd:state>

                <wfd:state name="move2" action="fs:move">
                        <wfd:property name="destination" value="/tml/test/EngineTestCase/dest2"/>
                        <wfd:transition on="success" to="move3"/>
                </wfd:state>

                <wfd:state name="move3" action="fs:move" type="FINAL">
                        <wfd:property name="destination" value="/tml/test/EngineTestCase/dest3"/>
                </wfd:state>
        </wfd:workflow>
</job:job>

Я в ожидании вашего варианта майможсонного, представления вышеуказанного XMLя.

Жду как оно представляется в JSON.


"a":{"адын":1,"дыва":2,"тры":3}

называть можешь как хочешь, смысл от этого не меняется (иногда меняется фильтр, но не намного)


> В XML есть четкое разделение на атрибут и контент - чего нет в JSON.

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

>XSLT - это очень плохо. Код должен быть написан на императивном языке

Кому должен?

> В нутри SOAP передаются документы без всякой необходимости понимания самим транспортом их содержимого.

Что такого умеет SOAP, чего CORBA не умела за 10 лет до этого? Независимый от пространства имен транспорт - IIOP. Что еще?

XML - это жирная и неэффективная (по пространству и времени), но трендовая (язык разметки во времена первого бума Веба) реализация здравых идей и старых технологий. Это работает, никто и не спорит. Но всё это можно было сделать куда эффективнее.

> Т.е. ты хочешь чтобы опять как в 90-е, люди обменивались файлами в бинарных форматах .xls и .doc? Спасибо, я наелся этого. Ты мог открыть .doc чем-нибудь кроме MS Word, до появления OOo?


виндузятник?

нормальные люди и раньше обменивались текстом (уних-вей)

>java-script architect at yahoo

yahoo... оно, собственно, не нужно

> Кому должен?

здравому смыслу и прогрессу

> yahoo... оно, собственно, не нужно

мне Вас жалко...

>>> зачем в диалоге МАШИНА <-> МАШИНА переводить данные на человеческий язык?
>> А что за машина? be? le? Целое и указатель какого размера? А?
> Против be да le придуман, например, EBML. XML всё-таки всем своим видом намекает на то, что его хотя бы изредка читает или пишет человек.

+1. А для human-readable есть YAML.

>Ok. А теперь, расскажи ка дядя, нах XML тащат в конфиги софта?

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

>Что такого умеет SOAP, чего CORBA не умела за 10 лет до этого?

Он умеет по http://:80 . А CORBA умеет?

>мне Вас жалко...

А мне Вас нет. Биореактор готов. Следующий!

что я за тебя твою работу делать должен? Не хочу.
Могу сказать что твой ёб будет в 2+ раза меньше по объёму и гораздо более читаемым.
спек - на http://www.json.org/
(я бы вообще в иерархию свернул:

job.description=PlayBoy#2-2008/Cover
job.sender.name=r
job.sender.email=x.mad.scientist@gmail.com
...

всё равно эффективнее - из хеша таскать. Так кладите сразу в хеш (зачем же мучаться с парсингом?)

>> Что такого умеет SOAP, чего CORBA не умела за 10 лет до этого?

> Он умеет по http://:80 . А CORBA умеет?

Старая CORBA не умела (то есть умела, но с фарволами были проблемы), насчет 3.0 не знаю. Тот же ZeroC - умеет.

Еще что-нибудь есть?

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

это мы говорили 10 лет назад, когда появлялся ХМЛ (вагон и маленькая тележка парсеров текстовых файлов существовала задолго до появления ХМЛя), а ХМЛщики продолжали строчить и строчить велосипеды. Теперь конечно, вы можете сказать - много. Но они _не нужны_.
И даже этот вагон - это вагон дерьма. Возвращайтесь к истокам (к старому вагону надёжных и простых текстовых конфигов. Наигрались, поди)

>Простите ламера, но разве коллекция - не объект? :)

Коллекция то обжект но не любой обжект коллекция. В переводе на це десереализация той херни эквивалент:

struct X {
void * key1 = "value1";
void * key2 = "value2";
void * key3 = "value3";
}.

Не находишь что это несколько не то же самое что ассоциативный массив? Вот и eval жабаскрипта не находит.

>Нет там никакого "четкого разделения".

Имелось ввиду что в JSON нет аттрибутов - только значения. В чем собственно и состоит невозмодность представить ассоциативный массив в JSON или взаимнооднозначное соответствие построить к <x content="attribute">content</x>.

> struct X {

кто-ж вам сказал что eval должен автоматически представить в то что вам надо. JSON парсер например кладёт key1:value1, key2:value2
сразу в хеш. Это как раз то что нам и надо. Не так ли?
Или вообще заберите сами всё в пропертиз и имейте всё в ключах.

>называть можешь как хочешь

Я назову как называет жабаскрипт.

var a = {"адын":1,"дыва":2,"тры":3}

a.length //error

Array.prototype.mymethod = function(){};

a.mymethod // error

В моем случае это все работало. В твоем не будет. Потому что ты вместо того чтобы признать что JSON это представить эквивалентно не может пытаешься копать граблями вместо лопаты и убеждаешь что они тоже копают.

>Что такого умеет SOAP, чего CORBA не умела за 10 лет до этого?

Нашару обрабатываться большим количеством унифицированных средств или написание оных не представляется сложным. SOAP дернуть из жабаскрипта на страничке - не вопрос - элементарно - вопрос минут даже не применяя библиотек. Хотел бы я видеть это в исполнении для корбы.

>Но всё это можно было сделать куда эффективнее.

Только не на бинарных протоколах.

> здравому смыслу и прогрессу

В каким месте трансформация деревьев нуждается в императивщине?

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

>Ok. А теперь, расскажи ка дядя, нах XML тащат в конфиги софта?

Именно чтоб делать password = selectSingleNode('//client[attribute::login="'+login+'"]).attributes.getNamedNo de('password').text

Гораздо удобнее чем в ini при наличии 50 секций [client]

> // error

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

если уж на то пошло - вот пример:

var data={"result":
{"records":[
{"c0":"0.9720159953189302","s0":"","ca0":"aCategory","c1":"0.6619113675453985", "s1":"","ca1":"aCategory","c2":"0.5176177263094673","s2":"","ca2":"aCategory"},
{"c0":"0.09578029464710125","s0":"","ca0":"aCategory","c1":"0.6738298720092876" ,"s1":"","ca1":"aCategory","c2":"0.180947294489604","s2":"","ca2":"aCategory"},
]}};

or the same:
<!--message-->
"result":
{"records":[
{"c0":"0.9720159953189302","s0":"","ca0":"aCategory","c1":"0.6619113675453985", "s1":"","ca1":"aCategory","c2":"0.5176177263094673","s2":"","ca2":"aCategory"},
{"c0":"0.09578029464710125","s0":"","ca0":"aCategory","c1":"0.6738298720092876" ,"s1":"","ca1":"aCategory","c2":"0.180947294489604","s2":"","ca2":"aCategory"},
]}};

>что я за тебя твою работу делать должен? Не хочу

В таком случае можешь идти обогащать землю. Задаяча элементарная чтобы подтвердить твои загоны.

> Могу сказать что твой ёб будет в 2+ раза меньше по объёму и гораздо более читаемым.

Жду не дождусь решения на MIME[+JSON] которое будет меньше и более читаемо.

>job.sender.email=x.mad.scientist@gmail.com

А ты продолжи дальше - я хочу посмотреть как с таким подходом онро будет меньше. Особенно меня интересует когда ты начнешь ассоциативные списки раскладывать.

>Так кладите сразу в хеш

Дададад - данные для программы на С надо писать на С. Тут главное не забыть компилятор динами\ческий привернуть чтобы он прочитав исходный код на С загенерил бинарник и загрузил в адресное пространство процесса.

>Но всё это можно было сделать куда эффективнее.

А еслиб у бабушки.... Понятно, куда я клоню? XML есть здесь и сейчас. Все остальное, по большему счету сферические кони в вакууме. Это не идеально, но есть для 99% языков, сделаны даже аппаратные акселераторы.. Если применять с умом, а не с фанатизмом - все отлично пашет.

>В каким месте трансформация деревьев нуждается в императивщине?

ой не заставляйте опять обьяснять - как трудно поддерживать функциональщину.
И давать примеры 3-страничного SQL и хранимой процедуры делающей то-же самое через курсор - императивный способ решения абсолютно неподдерживаемого но кошерного логического выражения)
хоть ничего и не может быть православнее реляционной алгебры.
Но мы - люди :(.

>JSON парсер например кладёт key1:value1, key2:value2
сразу в хеш.

А - то есть мне здесь надо неаписать еще специфичный для структуры данных парсер который понимает что в

{a:b,c:d,e:{k1:v1,k2:v2}}

a,c,e поля структуры, а k1,k2 - это ключи хаша? Что еще мне надо руками сделать? И нафига мне в таком случае JSON когда он сбюда подходит как метла слесарю? Если мне надо будет формат отличный от XML скобочного вида с ассоциативными массивами для которого мне надо еще и парсер руками писать - то эта проблема решаема в виде

{a:b,c:d,e:[k1 -> v1,k2 -> v2]}

Только это не JSON.

JSON имеет очень ограниченную область применения, и является эффективным костылем, а не полноценным методом хранения структурированных данных по причине того что он не в состоянии засериализировать даже стандартные типы жабаскрипта. Уж не говоря о том что не известно в случае {x : 1} какого чисельного типа эта единица.

>Если уж ты пихаешь прямо в жаба-скрипт - тогда надо более точно - согласно JSON-стандарту (гугле в помощь).

Я и не знал что кастование гугла может добавить в стандарт в котором нет ассоциативных массивов оные.

Повторяю по буквам JSON таких типов данных _не умеет_. Все что умеет JSON - это иерархический ключ-значение.

>это мы говорили 10 лет назад, когда появлялся ХМЛ (вагон и маленькая тележка парсеров текстовых файлов существовала задолго до появления ХМЛя)

Дурак, или прикидываешься?

Еще раз, для тех, что в танке. Из этих парсеров ни один не мог полностью покрыть следуюие возможности (неймспейсы, валидация, хранение бинарных жанных, автоматическая трансформация) Тем, более, что танкисты трындят про ПАРСЕРЫ! А DOM это еще и генератор. Причем, если нужна фича, используешь. не нужна нет.

JSON аналог namespaces где? Где в вашем JSON комментарии которые выживут после программного обновления вашего недохэша? Где ваш идиотский JSON для PERL, PHP, PYTHON, PgSQL? Да есть для них такое, но нифига не стандарт. Велосипедисты

>И давать примеры 3-страничного SQL и хранимой процедуры делающей то-же самое через курсор - императивный способ решения абсолютно неподдерживаемого но кошерного логического выражения)

Повторяю вопрос с выделенными ключевыми словами: В каким месте _трансформация !деревьев!_ нуждается в императивщине?

>Повторяю вопрос с выделенными ключевыми словами: В каким месте _трансформация !деревьев!_ нуждается в императивщине?

Оно, о логике не слышало... можешь не объяснять ему. в 1С такого, нет. Оно не понимает, деклоративные или функциональные языки и в SQL везде пихает курсор. Отсюда и полное непонимание XSLT

парсеры писать не надо - если клиент - яваскрипт.

Сдаунлодь мой пример (index.html, он самодостаточен):
http://sourceforge.net/tracker2/download.php?group_id=165715&atid=836476&...

Там захардкожен массив (в реальности - таблицы приходят с сервера), и при смене табов - таблицы разумеется динамические, включая количество колонок и пр. Данных - море (в реальности - больше чем 60к ячеек).
Теперь представим что посылаешь свой ХМЛь. Да тебе надо пропускную способность в 2 раза минимум апгрейдить (на нагруженных сайтах каждые 100к/пер юзер - чрезвычайно важны). Как видно из index.html - обьём данных даёт >100% вклада. Теперь умножим дополнительные 100к (гораздо больше), появляющиеся из-за ХМЛя на количество юзеров. И получим, насколько вы дороже обходитесь компании чем я (цена bandwidth)

>a,c,e поля структуры, а k1,k2 - это ключи хаша?

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

>Повторяю вопрос с выделенными ключевыми словами: В каким месте _трансформация !деревьев!_ нуждается в императивщине?


ты так и не понял...

XSLT - это сложный трансформационный процесс. А любая сложность должна быть контролируема.
Императивные языки действуют методом "divide and conquer", хоть и менее красивы с математической точки зрения.
Мне больно смотреть на контракторов, которые берутся за XSLT-проекты, а потом, на определённой точке сложности - утыкаются и выглядят, поверьте, - очень жалко. Все крупные проекты на XSLT которые я видел (или делали мои знакомые) - провальные.
Я не спроста дал аналогию с SQL. Аппликация может быть построена на основе одного огромного SQL. Но те проекты - никто не в состоянии поддерживать. Так как у вас много десятков вложенных подзапросов, кучи джойнов, что оптимайзер сходит с ума. А разбив это на императивные джойны (и учитывая факт, что программер знает будущий объём данных лучше оптимайзера) - мы разбиваем код на контролируемые куски которые ещё и выполняются оптимальнее.
Не случайно так модны сегодня джойны в софте а не в базе. Потому-что не нужны гении, а можно посадить кучу людей, делающие свой кусок вместо медитирующего на одно гиганткое вложенное выражение гения-математика.

Так понятнее? Связь SQLT с императивщиной ясна теперь?

> Оно, о логике не слышало... можешь не объяснять ему. в 1С такого, нет. Оно не понимает, деклоративные или функциональные языки и в SQL везде пихает курсор. Отсюда и полное непонимание XSLT

Наслаждайся своим пониманием. Не интересен.

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

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

кстати JSON - это не отдельный "велосипед", а часть javascript.
А javascript - это почти Scheme ;)

> Речь о XML, не надо язык для трансформации сюда приплетать, он и должен быть полноценным ЯП, с циклами, условиями, рекурсиями, и т.п. Кстати, а что за скрипты делали на XML? Впервые слышу

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