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

> Ты читать умеешь? Use Guile. Получишь гораздо больше, чем ты описал.

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

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

Emacs - это тот самый маргинальный текстовый редактор, занявший 4ое место в 2005 LinuxQuestions.org Members Choice Awards? :)

> Или уже написан универсальный потребитель информации по SOAP, ориентирующийся исключительно на "исчерпывающую информацию о семантике" в SOAP?

Microsoft Office? WSDL? :)

> А это что? Это типа того, что тут на картинке? http://docprof.kvazar-micro.com/system/reg_doc/ Ответ --- Tcl/Tk.

Мне жаль пользователей таких простецких интерфейсов. :)

>> А это что? Это типа того, что тут на картинке? http://docprof.kvazar-micro.com/system/reg_doc/ Ответ --- Tcl/Tk.

> Мне жаль пользователей таких простецких интерфейсов. :)

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

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

Ага, чисто силой воображения. Тогда то же самое можно сделать и средствами CUI. :)

> она валидирует ?

Естественно.

> то есть можно точно сказать с помощью guile что то что написано - нееправильно ?

Можно, если напишешь правила, как и в DTD или XML Schema, но набор возможностей для опиания правил не идет ни в какое сравнение с XML Schema или, тем более, с убогим DTD.

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

При чем тут это? Если ты написал валидную программу, которая работает неправильно, то тебе поможет только отладчик :)

> оно валидирует ??

ini/key=value были приведены как альтернатива для относительно простых конфигов, требующих читабельности и возможности ручной правки, что не отменяет возможности лопатить их _стандартными_ утилитами Unix. И валидировать там нечего абсолютно. Если парсер встретит key без value, то, наверно, ругнется, а больше никакой валидации там не нужно, кроме валидации значений, которая привязана к семантике и DTD/Schema тут также бессильны. Нужна валидация --- guile или самописная.

> xml сериализация уже есть

Да, это плюс, я уже писал, что я с этим согласен, но это не отменяет технических недостатков XML. Кстати, PostScript и pickle тоже уже есть.

> она читаема, и оверхед приемлимый

<office:document-content xmlns:office="http://openoffice.org/2000/office"; xmlns:style="http://openoffice.org/2000/style"; xmlns:text="http://openoffice .org/2000/text" xmlns:table="http://openoffice.org/2000/table"; xmlns:draw="http://openoffice.org/2000/drawing"; xmlns:fo="http: //www.w3.org/1999/XSL/Format"; xmlns:xlink="http://www.w3.org/1999/xlink"; xmlns:number="http://openoffice.org/2000/datastyle"; x mlns:svg="http://www.w3.org/2000/svg"; xmlns:chart="http://openoffice.org/2000/chart"; xmlns:dr3d="http://openoffice.org/2000/dr 3d" xmlns:math="http://www.w3.org/1998/Math/MathML"; xmlns:form="http://openoffice.org/2000/form"; xmlns:script="http://openoffi ce.org/2000/script" office:class="text" office:version="1.0"><office:script/><office:font-decls> ;<style:font-decl style:name="S tarSymbol" fo:font-family="StarSymbol" style:font-charset="x-symbol"/><style:font-decl style:name="Tahoma1" fo:font-family="Ta homa, Lucidasans, &apos;Lucida Sans&apos;, &apos;Arial Unicode MS&apos;"/>

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

> приведите пример разбора для лиспа когда в неизвестное лисп дерево вставлен известный кусок

(let ((subtree-we-need (with-open-file "my.document" (extract-subtree-by-condition condition (read))))) (do-whatever-we-want-with subtree-we-need))

> ваша великая лисп панацея сработает ?

Более чем.

> приведи мне пример динамически модифициремого бинарного формата ! с хорошей эффективностью и на ширину канала и на парсинг

zip.

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

А что, с этим были проблемы?

> И это будет быстрее (не пишу "гораздо быстрее" потому что формат там еще тот, а подписаться под OpenDocument мелкомягким масть не позволяет) в разработке, чем хоть на лиспе, хоть на чем угодно ты попытаешься разобрать бинарный формат Word'a.

Ну, лично я его разбирал на Python через COM API Word'а. Нормально, никаких лишних промежуточных сущностей типа XML мне не понадобилось.

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

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

> Писался конвертор для перевода в него из MS Word и DITA. Время разработки: соответственно полтора месяца (причем баги находим до сих пор, уже три месяца прошло) и три дня.

Я просто не в курсе, что там за формат был, в который вы конвертили. MS Word --- это несколько другой уровень, по сравнению с DITA. DITA ориентирована на структуру и содержание документа, а Word --- на визуальное представление. Из первого во второй генерить легко, а вот наоборот --- сложно.

> Хмм, я не знаю, что ты понимаешь под сложной логикой преобразования.

Ну, например, мой гипотетический формат ориентирован на описание каких-либо объектов совершенно разных типов. В простейшем случае, пусть это будет из близкой вам области: таблицы, иллюстрации, текст и т.п. Мне их нужно, допустим, автоматически нумеровать (с учетом некоторой структуры, например, глав), призваивать символическое имя для ссылок и подставлять номера по именам. Можно заложить логику работы "хардкодно", а можно предоставить набор некоторых инструментов, которые делают не именно это, но позволяют легко описать то, что нам надо. Ну, типа TeX, только на XML. А вам потом придется реализовывать на XSLT логику вычисления <referenceNumber name="picture1" />.

> то есть требований по сути не было. В таком случае, ИМХО что LISP, что XSLT - все до дверцы.

Ну, не совсем. Это ровно тот же случай, который я приводил как пример своего провала с XML и Python --- у нас были примеры документов, накорябанных в Excel и Word без особых правил. Нужно было выковыривать из них инфу в терминах определенной предметной области. Просто в виду слабости возможностей XSLT вы даже не помыслили о более сложных решениях, например, эвристиках, основанных на некоторых элементах оформления, на содержании, которое можно оценивать по словарям в БД и пр. Это и есть, собственно, проблема преобразования из низкоуровневых форматов в высокоуровневые, например, texinfo->HTML легко, а наоборот --- запаришься, потому что данные о высокоуровневой структуре утеряны либо их и не было никогда.

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

Типа, в том редакторе, которым ты пользуешься, для написания пары строки текстов, надо писать те бешенные конфиги на XML, которые ты описал? Так что, не передергивай. Речь шла о _навороченных_ конфигах. Да, к Emacs можно писать очень навороченные конфиги, но не для того, чтобы написать пару строк текста, а для того, чтобы делать навороченные вещи, которые не осилит даже редактор, с приведенными тобой мега-конфигами на XML.

> Emacs - это тот самый маргинальный текстовый редактор, занявший 4ое место в 2005 LinuxQuestions.org Members Choice Awards? :)

В ход пошли аргументы про дерьмо и миллионы мух?

> Microsoft Office? WSDL? :)

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

Можно ли описать это барахло в SOAP так, чтобы Office из коробки без доп. программ и написания кода умел запросить у пользователя набор объектов, набор параметров, временной интервал, получить данные и сгенерить приемлемого вида отчет для печати?

> Мне жаль пользователей таких простецких интерфейсов. :)

Батенька, я не знаю что такое "интерфейсная форма", поэтому набрал в гугле, ткнул в одну из первых ссилок и получил ЭТО. Это то, что вы имели в виду? Покажите не простецкую, которую Tcl/Tk не осилит.

> Ну, лично я его разбирал на Python через COM API Word'а.

То есть, как минимум, тебе не пришлось самому парсить документ, что в купе с созданием объектной модели и сериализацией наиболее трудозатратно (о чем тут уже говорилось). Согласись, что Word API есть не всегда. Например, Corel Draw/Adobe Illustrator vs. SVG.

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

> Я просто не в курсе, что там за формат был, в который вы конвертили.

Это был формат для localization tool. По сути это был не конвертор а фильтр. Нужно было вычленить из документа все текстовые сегменты, которые должны переводится.

На XSLT это было по сути вычленение текстовых узлов (на самом деле чуть сложнее, output тоже XML). В случае с Word'ом, необходимо было изучить объектную модель, чтобы вычленить все строковые значения.

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

Да, DITA проще, но это тоже появилось не на пустом месте, еще нужно уметь разработать формат, который будет легок в использовании, в интеграции и пр. IBM-щикам это удалось. В конце-концов, лишний повод перейти на более удобный формат.

> Это ровно тот же случай

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

> Просто в виду слабости возможностей XSLT вы даже не помыслили о более сложных решениях, например, эвристиках, основанных на некоторых элементах оформления, на содержании, которое можно оценивать по словарям в БД и пр.

Естественно, что из XSLT я в БД не полезу, хотя теоретически могу. Только вот кроме слабости возможностей XSLT, еще бывает "слабость возможностей бюджета". Предложение работать дальше было, и решение было, и estimate был... и ответ был, что за ненамного большие деньги (учитывая, что результат неосязаем) мы переведем весь имеющийся у нас content вручную.

Ради искусства можно было бы и помыслить, а когда денег хочется, то приходится взвешивать. Да, я циник. :)

Сорри, пропустил

> Ну, например, мой гипотетический формат ориентирован на описание каких-либо объектов совершенно разных типов. [и далее по тексту]

Я не увидел сложности в оргнизации ссылок и нумерации (xsl:number?), т.к. это есть то с чем приходится сталкиваться в документации каждый день.

Насчет hard coded алгоритмов. Я думаю, не секрет что на вход трансформации может поступать не один, а много документов (как и получаться на выходе).

Так вот, это возможности используется для описания некоторых правил (в XML), которые потом прекрасно интерпретируются основной трансформацией, во время обработки документа.

> Типа, в том редакторе, которым ты пользуешься, для написания пары строки текстов, надо писать те бешенные конфиги на XML

Почитайте http://developer.kde.org/documentation/tutorials/kconfigxt/kconfigxt.html - там написано, насколько удобнее использовать в разработке XML, маппируемый как на логику программы, так и на построение интерфейса для настроек - программист избавлен от нудной ручной работы.

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

Увы, разработка навороченных вещей для текстового редактора не востребована. Проще писать отдельные специализированные приложения с общением между ними в XML, чем всё толкать в одну кучу. Один из принципов Unix-way. :)

> В ход пошли аргументы про дерьмо и миллионы мух?

Нет, просто констатация фактов. :)

> Можно ли описать это барахло в SOAP так, чтобы Office из коробки без доп. программ и написания кода умел запросить у пользователя набор объектов, набор параметров, временной интервал, получить данные и сгенерить приемлемого вида отчет для печати?

Не знаю, я с MSOffice не работаю. Посмотрите примеры: http://spaces.msn.com/mkozloff/blog/cns!D1ED809F4FFA9136!231.entry

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

Побойся Столлмана, революционер! :) За это боролись! И именно этот факт неотделимости привел создателей KIF (Формат обмена знаниями) к s-expressions. Этот формат уже стандартизован ANSI. Поинтересуйся. Как знать, куда все качнется. Возможно, что он будет включен и в ISO.

>> она валидирует ?
> Естественно.

даа ? какие мы - если лисп то он еще и на балалайке играет
ну-ка нука - правильное ли это лисп выражение -
(someA (someB someC someD)) ?
и каким образом лисп догадается что оно неправильное
если someC никогда не может быть аргументом someB
до того как выполнит это выражение ??? святым духом ?

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

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

>> она читаема, и оверхед приемлимый
><office:document-content xmlns:office=
>фигенно читаемо, правда? То, что оверхед _может_ быть приемлемым

приведи сначала аналог офисного документа на лиспе ....
а потом звенди

<env:Body>
<p:itinerary
xmlns:p="http://travelcompany.example.org/reservation/travel">;
<p:departure>
<p:departing>New York</p:departing>
<p:arriving>Los Angeles</p:arriving>
<p:departureDate>2001-12-14</p:departureDate>
<p:departureTime>late afternoon</p:departureTime>
<p:seatPreference>aisle</p:seatPreference>
</p:departure>
<p:return>
<p:departing>Los Angeles</p:departing>
<p:arriving>New York</p:arriving>
<p:departureDate>2001-12-20</p:departureDate>
<p:departureTime>mid-morning</p:departureTime>
<p:seatPreference/>
</p:return>
</p:itinerary>
<q:lodging
xmlns:q="http://travelcompany.example.org/reservation/hotels">;
<q:preference>none</q:preference>
</q:lodging>
</env:Body>

нечитаемо ??????
>> приведите пример разбора для лиспа когда в неизвестное лисп дерево вставлен известный кусок
>(let ((subtree-we-need (with-open-file "my.document" (extract-subtree-by-condition condition (read))))) (do-whatever-we-want-with subtree-we-need))
>> ваша великая лисп панацея сработает ?
>Более чем.

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

>> приведи мне пример динамически модифициремого бинарного формата ! с хорошей эффективностью и на ширину канала и на парсинг
>zip.

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

> Покажите не простецкую, которую Tcl/Tk не осилит.

Я не знаю нынешних возможностей Tk, но попробуйте сделать вот это: http://img215.imageshack.us/img215/2262/skullscreenshot12el.png

За десять минут сделал в Qt designer. :)

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

> Побойся Столлмана, революционер! :) За это боролись! И именно этот факт неотделимости привел создателей KIF (Формат обмена знаниями) к s-expressions. Этот формат уже стандартизован ANSI. Поинтересуйся. Как знать, куда все качнется. Возможно, что он будет включен и в ISO.

когда-то интересовался KIF - жаль только не нашел ничего, что его использует :)

> Побойся Столлмана, революционер! :)
это не революция
это простой принцип который хорошо бы было соблюдать в языке представления данных
не знаний, а данных

наверное все-таки лучше всего вместо чистого XML использовать SXML - как
связующее звено между XML и KIF
но мы же знаем что SXML - эквивалентен XML
значит когда понадобиться я смогу перейти с XML на SXML а потом на KIF ?;)
значит ничего страшного ? :))

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

кстати - требование иметь закрывающий именованный тэг-
основное отличие xml от sxml (по моему скромному мнению :) -
пережиток эпохи html
но наличие такого тега - делает сообщения об грубых ошибкак в документе
намного более вменяемым но это уже обсуждалось выше
в остальном xml полный эквивалент s-exp :)

радуйтесь лисперы - мир наконецто повернулся к вам лицом
а вы нахально пытаетесь туда плюнуть :)

Nu rebyata, vi kakiye-to upiortiye s XML.

---8<---
<env:Body>
<p:itinerary
xmlns:p="http://travelcompany.example.org/reservation/travel">;;
<p:departure>
<p:departing>New York</p:departing>
<p:arriving>Los Angeles</p:arriving>
<p:departureDate>2001-12-14</p:departureDate>
<p:departureTime>late afternoon</p:departureTime>
<p:seatPreference>aisle</p:seatPreference>
</p:departure>

<p:return>
<p:departing>Los Angeles</p:departing>
<p:arriving>New York</p:arriving>
<p:departureDate>2001-12-20</p:departureDate>
<p:departureTime>mid-morning</p:departureTime>
<p:seatPreference/>
</p:return>
</p:itinerary>
<q:lodging
xmlns:q="http://travelcompany.example.org/reservation/hotels">;;
<q:preference>none</q:preference>
</q:lodging>
</env:Body>

---8<---

= 733 bytes

---8<---
1:New York
2:2001-12-14
3:late afternoon
4:Los Angeles
5:2001-12-14
6:mid-morning
---8<---

= 87 bytes

where mapping file #->Name of the field (names definition) - PASSED ONLY ONCE!
1.departing
2.departureDate
3.departureTime
...

V 10 raz raznitsya!
Da vi escho hotite otdelniy webserver ustasnovit' chtobi http://travelcompany.example za schemoy diorgat' (cluster webserverov?:) - kajdiy message kogda ih millioni??

Kogda code validiruyuschiy napisat' - odin cheloveko den' i on prost kak yaytsa?

Koroche pioneriya eto vsio.

Anode

В Лиспе нет валидатора! Задачи pattern matching --- это более высокий уровень. Но эти задачи решаются в рамках LISP красиво, лекго и непринужденно его же средствами. И этих валидаторов для LISP --- масса. Но ведь DTD тоже является мета-уровнем.

Проблема злости лисперов *ИМХО* возникает потому, что когда-то они опоздали на раздачу слонов. В тот момент, когда фреймфорк, аналогичный "XML и Ко", уже имелся в наличии, никто не позаботился о том, чтобы как-то влиять на стандарты. А SGML тем временим был стандартизован, потом HTML получил большое распространение. На этой волне и XML моментально стал мейнстримом. Потом уже появились дополнительные инструменты XSLT, DTD и пр. Это все *ИМХО*, так как я авторитетно об истории этого вопроса не могу рассуждать. А теперь вот оказывается, что это уже было. Причем в рамках одной системы LISP. Вот и злятся. :)

Eto vsio govorit libo o prof. nesootvetstvii teh kto reshayet - kakiye technologii ispolzovat' v real-time systemah (travel company/reservation - real-time) libo dur' kakaya-to kotoraya v production ne poydiot - kogda yeyo uvidyat ludi rabotayuschiye bolee 10 let s realnimi ob'yomami dannih.

Koroche jelayu nam vsem mnogo raboti ;)

Аналогия: docbook <-> эсперанто

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

Идея просто замечательная: имеем n языков, следовательно необходимо n! словарей (рускко-русский словарь тоже необходим), а в случае второго обязательного языка имеем всего 2n словарей, когда n>3 имеем выигрыш.

Эсперанто самый распространённый из подобных универсальных языков. Он прост, исключений в языке нет. Так почему выбирают для обучения второй английский? Да потому что в мире всего несколько сотен человек для кого эсперанто родной.

Эсперанто, как и docbook статичны - они не развиваются так как развиваются языки/форматы у которых "есть носители"/"те кто работают с ними напрямую". В статичности их сила - легко транслировать. В статичности их слабость - так как мы творим расширяя.

Сила живых языков в том, что в них могут легко создаваться принципиально новые языковые схемы, которые не входят в стандарт до момента пока достаточно не распространятся - выживает то, что удачно. Мёртвый язык - язык для трансляции лишён этой возможности - его можно расширять только сверху по команде. Для развития в языке должна быть возможность ошибаться.

"В каждой шутке есть только доля шутки"

Da kakoy lisp k chortu v travel agency example vishe?!
Eto uje ne zamena .doc na personalke ili podderjka odnoy knigi v xml i preobrazovaniye cherez xslt.
Eto - real-time systema s bolshimi ob'yomami gde i lisp i xml zakidayut ssanimi tr'apkami, potomu chto im tam ne mesto (raznitsa - na poryadok+ otsutstviye flexibility strok!).
Da ya posle vas pridu i peredelayu sistemu za neskolko dney uvelichiv na 10 raz propusknuyu sposobnist' i poluchu babki, no vas prosto ne pustyat tuda iznachalno.
Tam escho i http://domain, t.e. DNS server na kajdiy message hotyat diorgat' :)))

Da, pora otkrit' kontoru - optimizatsiya vplot' do na-poryadok - budet rastirajirovano kak "Success stories" (ne na 20%, ne v 2 raza, a na poryadok!!), a na dele - ubiraniye xml i povisheniye bandwidth i performance, ubiraniye web-serverov i nagruzok na DNS ostavlenniye pionerami (gde vozmojno i budut bottlenecki). Esli takiye sistemi budut vnedreni konechno.
Vnedryayte pojaluysta!

достали вы меня лисперы
юмор уже пропал
идите - покряйте мир

Anode
понятие - пример, example - тебе знакомо ?
если нет - то к сведению - пример -это не обязательно реальная вещь
а то что илюстрирует идею ....

>>>>>>>>>>>>>>>>>>>> >>>>>>
1:New York
2:2001-12-14
3:late afternoon
4:Los Angeles
5:2001-12-14
6:mid-morning
---8<---

= 87 bytes

where mapping file #->Name of the field (names definition) - PASSED ONLY ONCE!
1.departing
2.departureDate
3.departureTime
>>>>>>>>>>>>>>>>>>>> >>>>>>

затрахали уже изобретатели форматов, сильно, очень
а если я скажу что и
1.departing
2.departureDate
3.departureTime
в принципе то и не нужно так как значения позиционно зависимы ?
ты перестанешь изобретать свой великий формат ?

и почему ты решил что кто то кого-то будет "дергать за схемой"
и где-ты увидел реалтайм систему ?

в общем - зае.ли
успехов вам в продвижении лиспа
xml уже просрали - продолжайте в томже духе

2 Zubok
Zubok, sorry - eto konechno ne Vam bil otvet, a tem kto hochet vnedryat' xml v bolshiye sistemi tipa travel-reservation.

>понятие - пример, example - тебе знакомо ?
na brudershaft vrode ne pili...

>затрахали уже изобретатели форматов
esli sistema s bolshim budjetom (a ne podelka) - to napisaniye protocola - samaya bistraya chast' i samaya blagodarnaya - potomu chto tam est' svoboda (potom - den' - maximum)

>и почему ты решил что кто то кого-то будет "дергать за схемой"
gde namespace hranyatsya?

>успехов вам в продвижении лиспа
pri chom tut lisp?

>и где-ты увидел реалтайм систему
travel-reservation mojet bit' sdelana off-line without any transactions?

i opyat' je - vrode na brudershaft vrode ne pili...

ladno, uspehov. _Vi_ k etomu echo pridiote.
sorry for translit.

> Da vi escho hotite otdelniy webserver ustasnovit' chtobi http://travelcompany.example za schemoy diorgat' (cluster webserverov?:) - kajdiy message kogda ih millioni??

Ууу, как все запущено. Вопрос, а ты случайно не из JetBrains? Они тоже как в третьей версии поддержку XML сделали, так и все норовят там что-то резолвить по этим URL'ам. А ну-ка марш, читать книжку про XML!

Ты когда Java код пишешь, тоже по вебсайту открываешь на каждый пакет? А если в пакете много классов, то кластер наверное ставишь?

Кстати аналогия действительно классная. Но ни что не вечно. Вот и два года назад появилась DITA, которая способна развиваться.

ладно последний пост:

>> понятие - пример, example - тебе знакомо ?
> na brudershaft vrode ne pili...

извини, не помню - наверное нет :)

>> затрахали уже изобретатели форматов
> esli sistema s bolshim budjetom (a ne podelka) - to napisaniye protocola - samaya bistraya chast' i samaya blagodarnaya - potomu chto tam est' svoboda (potom - den' - maximum)

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

>> и почему ты решил что кто то кого-то будет "дергать за схемой"
> gde namespace hranyatsya?
откуда я знаю ? :)))
один раз возмется потом из кэша :))))

>> успехов вам в продвижении лиспа
> pri chom tut lisp?

видите-ли - Вы вклинились в дискуссию - Xml vs Lisp
это так, что то вроде - с добрым утром !

>> и где-ты увидел реалтайм систему
> travel-reservation mojet bit' sdelana off-line without any transactions?

а что транзакция должна начаться в бровзере клиента ?
--- без споров, не хочу спорить на тему realtime + transaction

>> i opyat' je - vrode na brudershaft vrode ne pili...

не помню, а вдруг ? :)))

>> ladno, uspehov. _Vi_ k etomu echo pridiote.

я не использую xml в системах реального времени или близких к ним,
я уже пришел ? :)))) не спорить - просто шутка :)))

>> sorry for translit.

ладно, но больше так не делайте :)

esli ne s webservera - to s FS, chto ne luchshe - poluchite deadlocki kogda-nibud' na bolshih ob'yomah.
Da ya v kurse - mojno zahardcodit'. No v etom sluchaye - kakoy smisl voobsche v etom vsiom (validatsiya/protocol tak je zahardcojeni).

Net, ne iz JetBrains.

Ne nujna takaya validatsiya _kajdiy_ raz i stolko vnutrennih proverok (v parsere) - na _kajdiy_ message. Potomu chto idiotizm.

I opyat' je - brudershaft...

>ладно, но больше так не делайте :)

posle etoi messagi - poprobiyu

>а что транзакция должна начаться в бровзере клиента ?
daje esli budete klast' v queue i jdat' na cliente - vsio ravno ot momenta posilki message iz browsera (kogda agent uvidit' chto-to tipa "Transaction Processing") i poka on ne poluchit "Success" - dlya agenta eto budet kak transaction. To-est' - agent vsegda jdiot vse eti validatsii - na kajdiy message. Esli ih mnogo (messagey)? Togda message server (ili cluster) nagrujayetsya v 10 raz (i kanali a takje CPU) a tak kak na udalionnih officah mojet bit' dial-up i plata mojet bit' po traffiku - to nejelaniye pisat' protocol _radi_chego_ (?) - udivlyayet. Potomu chto napisaniye ego - udovolstviye.

Poka

> esli ne s webservera - to s FS, chto ne luchshe - poluchite deadlocki kogda-nibud' na bolshih ob'yomah.

Ну откуда ты эту фигню взял? Источник в студию! Эта строка (неважно URL там или нет) - это уникальный идентификатор схемы. И все. Твоему приложению достаточно посмотреть на эту строку чтобы определить может ли оно работать с этой схемой документа. Какие кластеры, какие deadlock'и??? Одно сравнение двух строк!

> I opyat' je - brudershaft... Ты, по поводу формы обращения? Извини, застал времена FIDO, где обращение на Вы было не принято, чтобы не сказать, что считалось оскорблением. И, в приницпе, мне казалось, что данный сетевой этикет без изменений перекочевал в РУнет (причем в его ИТ-шную часть). Но, если, обращение на "ты" напрягает, то не вопрос, только не забывай проставлять имя.

Потому как, пока что, я вижу, что я должен обращаться на "Вы" ко всем anonymous'ам.

2 azakharchuk
просто было несколько продуктов - где они лазили в фаиловую систему за дтд.
Если ДТД динамический - то его надо откуда-то брать, а если захардкожен - то протокол - то же самое, т.е. нет смысла в валидациях. И вообще валидацию неотключать нельзя! (+100-400% of parsing sometimes) Потом - интерпретированиые на каждый месседж??.
Вопрос - зачем весь этот огород вообще - с такими оверхедами _во_всём_: в читаемости, канале, ЦПУ, леарнинг-курв, потери всех уних-инструментов, большего времени разработки итд? Только потому что лемминги начитались рекламок - засорять индустрию заведомо плохими решениями?
Ето же массовое зомбирование, ей-богу. Которое скоро станет обязательным только потому что стандард.

последняя мессага - моя

Anode

Что-то сумбурное какое-то изложение, понял мало что, отвечу на то, что понял.

> просто было несколько продуктов - где они лазили в фаиловую систему за дтд.

Несколько продуктов из какого общего количества? Ну и что? Это показатель? EntityResolver никто еще не отменял, не нравится лазить в файловую систему, пишешь свой и лазишь куда угодно: в память, в карман, в бутылку...

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

Смутно понял. Приходит сообщение. Можно посмотреть на publicID, и еслиы мы его не поддерживаем сразу дать отбой. Но нам могут прислать ложное сообщение с нужным publicID, но несоответствующим схеме content'ом. Когда есть валидация, в момент прихода сообщения мы знаем о том, что оно имеет правильную структуру и содержит всю необходимую информацию (установлены все required attributes и пр.).

Чем плохо? Тем что для каждого нового протокола, я должен написать парсер/валидатор/сериализатор сам?

> канале, ЦПУ, wbXML? если уж совсем невтерпеж...

> леарнинг-курв,

> потери всех уних-инструментов, А других ОС значит уже нет? И других инструментов тоже нет.

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

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

>пишешь свой и лазишь куда угодно: в память

вот именно - в память. А зачем - если протокол у меня в памяти тож и он гораздо проще, так как там - набор проверок на языке с нормалными flow-control statements.
Я уже писал что многоуровневые <иф> в ЙСТЛ делает почти невозмойними последующие изменения/редезигн (в сравнении с тем же кодом любого 3GL-языка, который можно и в дебаггере запустить и понапечатать в логи).
Зачем вам перепроерять вообще что-то - вами же посланное???
itd
"Смотрите в корень" (Козьма Прутков)

нигде он не облегчает жизнь - ето иллюзия.

s/ЙСТЛ/JSTL

Чем дальше, тем больше теряю нить обсуждения.

> Зачем вам перепроерять вообще что-то - вами же посланное???

А кто сказал что мною? Если это web service, то запрос может быть отправлен кем угодно.

Кстати, по поводу web services/SOAP приведу пример из практики. Представь, себе smart home. Вся электроника подключена к home gateway, необходим интерфейс для управления. На самом деле интерфейсов много, но один из них - .NET приложение.

Home gateway - это коробочка с 200 МГц ARM процессором, 64MB Flash, 64MB RAM (это к вопросу о ресурсоемкости, ниже уже почти некуда, у меня в телефоне процессор мощнее). Там бежит Linux, JVM J9 и OSGi framework (есть такая штука для embedded систем). Суть такова: что пишется все на Java и там уже есть весь софт (у которого есть API), который управляет всей домашней электроникой (включает выключает стиральные машинки, холодильники и пр).

Итак стоит задача создать .NET приложение, которое управляет электроникой дома, через home gateway.

Решение: - пишется 1 java facade, к нему создаются web service proxies, генерируется WSDL. - в .NET из WSDL, генерируется готовый C# интерфейс, и Helper из трех строчек кода, поверх которого пишется приложения.

Был у меня в java getAppliancesCount(), стал в C# GetAppliancesCount(). При том что я не написал ни строчки кода, для того чтобы обеспечить работоспособность протокола. Я не заморачиваюсь протоколом вообще. Я сосредотачиваюсь на логике приложения.

Следующая задача, обеспечить доступ к тому же gateway из Flash applet'а. В dreamweaver втягиваем WSDL и получаем ActionScript класс со всеми методами.

Туда же. Реализовать управление все тем же со спутникового тюнера (есть такая штука Dreambox - SAT TV тюнер, внутри Linux, в старших моделях HDD, dvd recorder etc). Вопрос "На фига?" - из другой оперы, но любопытным скажу.

Сидишь смотришь ТВ, а снизу в бегущей строке состояние всей твоей бытовой техники (температура в духовке, например, если 200 можно идти ставить торт). Или message box выпрыгивает "Стиральная машина: программа окончена", можно идти белье вынимать. Дико? Мы первые два-три года тоже фигели, теперь привыкли. У буржуев еще и не такие хотелки нарасхват идут.

Короче, в тюнере с ресурсами еще хуже чем на gateway, поэтому пишем только на C++. Как ты догадываешься, берем WSDL генерим исходный код интерфейса (все тот же facade), и поверх него пишем логику.

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

DCOM - в такие ресурсы на Linux не сильно влезет.

embedded CORBA - могу порадоваться за цену и с интересом понаблюдать за написанием CORBA client на ActionScript.

RMI - ИМХО, понятно без комментариев.

custom HTTP (or socket)-based protocol - четыре раза писать handler протокола? Вперед!

Я что-то упустил?

Кроме того архитектура остается открытой, web service на home gateway, дает возможность быстро создать средство доступа с любой другой платформы: Palm, Mac да все что угодно.

>Я что-то упустил?
da

WSDL menyayte na stroki. Code chteniya iz javi, C#, C, C++, Perla, shella itd - po neskolko strok (a takje poluchite vozmojnost' obrabativat' iz vseh unix-tools - o chom ya raz 5 uje govoril) i po-lubomu prosche chem vi gorodite s xml parserami.
A uj kak razgruzite CPU i canali (blin, nadoyelo pro odno i toje veschat')

Davayte uje zavershim etot spor - ya naprimer viju chto vi gorazdo bolshe coda pishete, bibliotek taschite itd (chem esli bi bili stroki)

Bud'te zdorovi.

>custom HTTP (or socket)-based protocol - четыре раза писать handler протокола? Вперед!

prosteyshiy HTTP - elementaren
GET/POST HTTP/1.0\n\n
<vashi properties as above in the thread - here>

a socketi otkrit'-zakrit - poryadka 10 strok

nado multipart - implementiruyte nemnogo ot MIME

potom gotovogo coda - more

*** eto bil posledniy mail ***

> WSDL menyayte na stroki. Code chteniya iz javi, C#, C, C++, Perla, shella itd - po neskolko strok

Помимо того что, я не знаю что тебе даст WSDL, так как у нас она используетя всего лишь один раз (при генерации proxy/stubs). Но допустим я понял, что ты хотел сказать и предложил мне на строки заменить SOAP собщения.

И что я с этими строками делать буду?

1. Пару строчек чтобы создать socket.

2. Пару строчек чтобы читать.

3. Пару строчек чтобы писать.

4. Пару строчек чтобы распарсить.

5. Пару строчек чтобы сериализовать.

6. К каждому шагу по пару строчек чтобы обработать все ошибки.

Понятно все, что же тут непонятного. Что я протоколов никогда не писал.

А unix-tools у меня на Palm просто завались, да и чего уж там, на каждый виндовый десктоп по cygwin'у поставить. И Macromedia в следующей версии флеша встроит LinuxVM.

> Davayte uje zavershim etot spor - ya naprimer viju chto vi gorazdo bolshe coda pishete, bibliotek taschite itd (chem esli bi bili stroki)

Давайте, тем более, что я в упор не вижу где я его пишу больше. И ладно бы, если бы у меня не было иного опыта. Но по иронии судьбы именно сейчас я работаю над проектом, в котором необходимо было реализовать посредника, через которого плагины для Adobe Framemaker, ArborText Epic и BlastRadius XMetal должны общаться с неким сервером.

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

Вот. Сидим балуемся. У Adobe плагин на С, у Epic на java, у XMetal на JScript. По полтора-три дня рутинной работы на обработчик протокола, вместо того чтобы все три сделать за полдня.

Так что, мне спорить тут больше не о чем. Особенно учитывая то, что я под каждый свой аргумент привел пример из практики если не своей, то своих коллег, нашей компании (описываемый мной код не всегда был мой, но во всех этих проектах я участвовал). От тебя я слышу только "я знаю", "я вижу", "по любому проще", "это иллюзия", "начитались рекламок" и пр. При этом ты (в отличии от того же Evgueni, с которым мы оставшись при своих точках зрения довольно плодотворно пообщались, для себя я, по крайней мере, узнал много нового) еще и демонстрируешь (не буду писать полное) незнание предмета спора ("Слышал звон, да не знаю где он"). Подрастешь, изучишь матчасть, поднакопишь жизненных примеров, будешь готов спорить аргументированно, приходи, с удовольствием пообщаюсь.

> Bud'te zdorovi.

И тебе не хворать!

>привести пример парсера xml на с++ меньше 7k ?

Не приведёшь ты нифига. Одна только таблица спецзакорючек на две трети этого объёма потянет. Про таблицу Unicode-символов вообще молчу.

Недопарсеры недо-XML - это же не то, о чём идёт речь, правда?

>Гибкость и отсутствие проблем с версионностью.

1. Гибкость.

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

- Реально применение такой схемы как раз обязывает использовать _только_ узкий стандартный набор виджетов (см. также ниже про версионность). Т.е. какая-то гибкость наоборот получается, находите?

- А вот допустим нужно мне, чтобы количество контролов измнялось в зависимости от чего-то, что я на этой же форме ввожу в текстовое поле. Это мне прикажете на каждый чих городить обработчики, работающие c DOM формы? ЭТО - гибко?

2. Отсуствие проблем с версионностью

- Хм... Есть версия 1.0 платформы X, содержащая 5 стандартных виджетов. В версии 1.1 платформы X появляется ещё один стандартный виджет, итого 6. Есть xml-файл, описывающий форму для версии 1.1 платформы. Мы пытаемся запустить это на версии 1.0. Результат? Это получится нормальный, юзабельный интерфейс?

- Пример Firefox показывает, что xml _никак_ не помогает от проблем с версионностью. И помочь тут может только устаканивание платформы (читай отсутствие "проблем с версионностью" по умолчанию). Действительно, нельзя использовать то, чего нет (или то, что работает не так как ожидается).

3. Тормоза

Про тормоза ничего не было в вашем сообщении, но я таки напишу снова. Применение схемы с xml-layout приводит к тормозному GUI. Потому что закэшировать layout мы не можем (исчезнет даже та "гибкость", которую даёт xml-layout) - а парсить и переделывать DOM на каждое движение мышки на три пикселя.... Это не просто оверхед - это за гранью добра и зла.

4. Описание виджетов, их свойств, способа расположения и реакций на события в рамках приложений GUI.

Есть рабочая зона некоего редактора, есть сетка на ней. Мне нужно размещать примитивы, но так чтобы они при движении пытались по возможности "прилипнуть" к сетке. Опишите кратко плиз, как такое может выглядить с применением xml-layout, по вашему мнению.

>видите-ли - Вы вклинились в дискуссию - Xml vs Lisp

Это Вы "вклинились" со своими священными войнами в тему обсуждения [недостатков] XML.

См. заголовок.

>> привести пример парсера xml на с++ меньше 7k ?
> Не приведёшь ты нифига. Одна только таблица спецзакорючек на две трети этого объёма потянет. Про таблицу Unicode-символов вообще молчу.

> Недопарсеры недо-XML - это же не то, о чём идёт речь, правда?

речь идет о парсере xml эквивалентном парсеру ini
эквивалентный парсер xml - строит только дерево
для первого шага парсинга и работы с недо-ini подобным недо-xml
вполне достаточно
и даже если транслировать спецзакорючки - оставшегося объема - достсточно
а Unicode тут совсем не причем, -единственное наверное
сможет парсить только ascii или utf16

> Одна только таблица спецзакорючек на две трети этого объёма потянет.

Я наверное невнимательно читал спецификацию XML, или забыл что-то (все-таки 7 лет прошло уже). Но я не припомню термина "спецзакорючка".

> Про таблицу Unicode-символов вообще молчу.

А зря, хотелось бы услышать. Какое это имеет отношение к размеру парсера.

> Koroche pioneriya eto vsio.

Ага, Гугль - пионерия с их веб-сервисами и миллионными запросами?! Наверно, потому что про Lisp не знают. :)

Идите, в школе уже начались уроки!

Пару уточнений.

> эквивалентный парсер xml - строит только дерево

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

> транслировать спецзакорючки

Может ты хоть объяснишь что это такое? :)

> сможет парсить только ascii или utf16

Не "сможет только", а "обязан поддерживать" "utf-8" и "utf-16".

> видите-ли - Вы вклинились в дискуссию - Xml vs Lisp
>> Это Вы "вклинились" со своими священными войнами в тему обсуждения [недостатков] >> XML.
>> См. заголовок.

священную войну начали лисперы
начав доказывать что я _обязан_ пользоваться лиспом
так как бесмысленно использовать xml
когда есть лисп