> представьте веб страницу закодированную ASN .....

Не для того он делался. А xml - зачастую - тоже использование не по назначению. Ибо отпочкован он для языка резметки, а передают им данные.

> в третьих, XML не избыточен

Избыточен. Именно за счёт прототы базовой реализации (тэги, свойства). Отсутсвие более сложных конструкций, вынуждает, для их реализации прибегать к "извращениям". Но это и упрощает задачу парсинга. (Для универсального парсера).

> в четвертых, парсеры XML очень просты - вплоть до пары сотен комманд ассемблера

Это действительно так. Хотя, надо чётко понимать, что в этом случае речь идёт о самом простом случае xml.

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

А вот здесь не надо. Какая по сути разница - интерпритатор чего ты пишешь? Есть мнение, что написать полный интерпритатор xml (с DTD, ns и т.д.) будет не менее просто, чем интерпритатор lisp.

> XML парсер легко пишется и на ассемблере

Как я уже говорил - быстро написанный парсер подойдёт для самого простого случая. Что касается более продвинутых вариантов...

Наверное, я просто не в теме. Но, допустим java считается богатой на парсеры, а другие языки? Скажем в linux используется libxml2, которая, согласно доке (когда я её читал последний раз) поддерживает только DOM1, а DOM2 реализуется средствами Gnome. Не подумай, Gnome мне нравится, но программу хотелось бы видеть более универсальную.

Ну когда же ты наконец осознаешь, что ты - дурак? Пора бы прекратить с умным видом пороть чушь!

* SXML парсить тривиально. Проще, чем XML.

* Парсер SXML ни фига не обязан включать в себя интерпретатор какого либо лиспа.

* SXML входит в стандарт SOAP

* взаимно-однозначное преобразование XML <-> SXML тривиально, софт переделывать не надо

Так что кончай безгремотный бред тут толкать. Достал уже чрезвычайно. Не место здесь таким упертым тупым баранам, как ты.

Лисп -- это язык 1950х годов для ламеров. Настоящие программисты используют C++ или Delphi.

смешно, спасибо! (дома телек сгорел а без петрасяна жизне не жизнь)

Очень интересно на это посмотреть ;) Некоторые требования из реального проекта (реализованного с РСУБД и XML и весьма неплохо работающего, между прочим): - Неограниченная вложенность дерева - Настраиваемые структуры данных в каждой ветке - Неограниченные размеры полей - Экспорт/импорт всго этого в файл/из файла

PS: Одобряю каждое слово geek-а

А вообще статья баян, уже обсудили год назад, с песнями и плясками с гиканьем и воплями лисперов под предводительством Луговского www.linux.org.ru/view-message.jsp?msgid=872270 . Кстати, когда мы услышим начальника транспортного цеха?

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

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

Ты сначала с FAQ-ом то http://www.raleigh.ru/wiki/ ознакомься, а когда оборешь, вылазь на трибуну. А то пустословие щас не в почете.

>Кстати, когда мы услышим начальника транспортного цеха?

Не надо!!!

>Потрясающая история получилась ?

Да вы батенька фантаст. Подобную фантасмагорию только у Дена Брауна почитать можно. Перед тем как нести чушь до просветления читать по ключевым словам client side XSLT transformation и AJAX(HttpXMLRequest-remote scripting). А еще глядеть на GMAIL как портал с AJAX/JavaScript-based-xslt (sf project ajaxslt). Это все жестокая реальность уже давно.

Как нам подсказывает наш телефонистский опыт: конечно, не протокол, а средство для описания протоколов, ну так и XML не протокол, а как нам верно подксазывают товарищи -- расширяемый язык разметки. И что теперь делать?

>XML как тип машинных интсрукций давно уже есть "язык программирования". Посморите правде в глаза!

XML ни разу не ЯП. А вот XSLT это как раз функциональный Тюринг-полный ЯП. XML язык описания данных, Markup Language

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

>Дайт ссылку на доку или вводное описалово, аля getting started

Вот же дали тебе ссылку http://www.raleigh.ru/wiki/

Я использую связку xml-xslt-xsd. Очень удобно когда нужно передавать большое количество данных( например с веб страницы в базу данных и наоборот ). Использую след. схемы: DB->XML->XSLT->HTML - для отображения инфы в веб. XML->XSD->DB - для изменения базы данных XML - собственно данные XSLT - очень гибкая схема преобразования данных в другой формат XSD - проверка входных данных на валидность ( кстати, выдает очено понятные и ясные сообщения об ошибках ) Это схема упростила программы парсинга входных данных на 70-80%. Из опыта могу сказать, что надежность проверки входных данных, простота масштабируемости программы намного выше ценится чем незначительные задержки в работе программы. И еще, на мой взгляд для обработки данных должен быть применен научный подход, например, специализированные языки для изменения и отбора данных, такие как SQL, XPath и т.п.

P.S. Предлагаю след. вариант описания данных: контекстно свободные грамматики - мощный, быстрый, понятный всем подход т.е. данные должны описываться двумя файлами - собственно файлом данных и файлом описания грамматики. На текущий момент существует множество программ, которые могут парсить файл по входящей грамматике. Почему же такой подход не используется? Ведь данные можно представить природно, и описывать их теми средствами и языком кот. максимально подходит для этих данных. Ответа я так и не нашел. Может кто знает ... Dem0n

>... и частенько встречаются перекрытия тегов.

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

>в XHTML недопустимо - явная ошибка

я в курсе :) я говорил про HTML

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

>Ты сначала с FAQ-ом то http://www.raleigh.ru/wiki/ ознакомься, а когда оборешь, вылазь на трибуну. А то пустословие щас не в почете.

Полностью с вами согласен - особенно что касается вашего пустословия.

Что-то не видно в том FAQе как сделать docbook эффективнее, MathML понятнее, транслятор XML в pdf прямее.

>> Ну когда же ты наконец осознаешь, что ты - дурак? Пора бы прекратить с умным видом пороть чушь!

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

>> * SXML парсить тривиально. Проще, чем XML.

одинаково ... просто, дурачек

>>* Парсер SXML ни фига не обязан включать в себя интерпретатор какого либо лиспа.
>>* взаимно-однозначное преобразование XML <-> SXML тривиально, софт переделывать не надо

SXML ... не лисп, а XML, но с изменненой грамматикой
в нем вообще нет лиспа и поэту все местные лисп идеи идут лесом
все правильно, но после этого возникает вопрос - и ?
ну есть 2 грамматики для XML ....
оргазм испытать ?

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

>> Так что кончай безгремотный бред тут толкать. Достал уже чрезвычайно. Не место здесь таким упертым тупым баранам, как ты.
.....
в общем - еще один идиот, обостренный весной
.....
спокойнее надо быть, :)))))

>P.S. Предлагаю след. вариант описания данных: контекстно свободные грамматики - мощный, быстрый, понятный всем подход т.е. данные должны описываться двумя файлами - собственно файлом данных и файлом описания грамматики. На текущий момент существует множество программ, которые могут парсить файл по входящей грамматике. Почему же такой подход не используется? Ведь данные можно представить природно, и описывать их теми средствами и языком кот. максимально подходит для этих данных. Ответа я так и не нашел. Может кто знает ... Dem0n

Потому что первичны данные, а не их обработка. Важен результат, а не процесс.

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

XML:
<book xmlns='urn:loc.gov:books'
xmlns:isbn='urn:ISBN:0-395-36341-6'>
<title>Cheaper by the Dozen</title>
<isbn:number>1568491379</isbn:number>
<notes>
<p xmlns='urn:w3-org-ns:HTML'>
This is a <i>funny</i> book!
</p>
</notes>
</book>

SXML:
(*TOP*
(urn:loc.gov:books:book
(urn:loc.gov:books:title
"Cheaper by the Dozen")
(urn:ISBN:0-395-36341-6:number "1568491379")
(urn:loc.gov:books:notes
(urn:w3-org-ns:HTML:p
"This is a "
(urn:w3-org-ns:HTML:i "funny")
" book!"))))

и ???
читабельнее ?
проще ?
меньше ? намного ?

> yeolahim * (*) (10.04.2006 13:47:08)

Уж что-что, а списки литературы следовало бы в bibtex кодировать.

>> Уж что-что, а списки литературы следовало бы в bibtex кодировать.

это не мой пример, а со страницы этого самого SXML

>Потому что первичны данные, а не их обработка. Важен результат, а не процесс.

Мусор на входе - мусор на выходе. Данные без интерпретации никому не нужны. А интерпретация задаётся обрабатывающей "программой".

(возвращаясь к теме) А вот метод кодирования данных действительно вторичен - и лучшее, что можно было придумать - его описание в виде, пригодном для автоматической генерации парсеров/пр. Т.е. asn с обвязкой опять рулит, а XML решает не ту проблему (т.к. проблема разметки текста уже давно решена, и не один раз).

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

>>Потому что первичны данные, а не их обработка. Важен результат, а не процесс.

>Мусор на входе - мусор на выходе. Данные без интерпретации никому не нужны. А интерпретация задаётся обрабатывающей "программой".

А-йа-йай такой большой мальчик, а всё мусор на вход тащишь. Надо же думать что писать.

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

> может, нелюбители xml-а просто не представляют, что с помощью этого-самого зумля можно сделать? =)

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

В случае LISP у тебя есть _один_ _универсальный_ язык. Твой XML'ный конфиг будет короче и читабельнее, если перевести его в S-expr, при этом программа-обработчик написана опять же на LISP и у тебя есть возможность использовать всю мощь LISP прямо в твоем конфиге, не трогая программу-обработчик. Как пример --- emacs. Конфиг на LISP, при желании можно сделать с emacs'ом что угодно, либо прямо в конфиге написать парсер какого-нибудь ini-файла с опциями "for dummies". Ни в одной программе с XML я такой гибкости не видел, а если она будет, то это будет LISP с ужасным синтаксисом XML.

>Интерпритация данных может меняться, а данные нет

42:-)

>Знают. Но с помощью XML нельзя сделать ничего. Тебе потребуется программа на каком-либо языке, в которую будет включен парсер этого самого XML. И обработка всей логики твоего XML'я. Причем, это будут абсолютно оторванные друг от друга вещи --- XML и программа-обработчик

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

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

Вот именно! В виду закрытости, а не бинарности. Попробуй сходу понять семантику тэгов в файлах OpenOffice без доп. документации, это ведь "самодокументируемый" формат. А нормальные реализации TCP/IP есть, хотя пакеты ни разу не в XML, а очень даже бинарные --- просто формат описан. Так что не путай теплое с мягким.

>Вот именно! В виду закрытости, а не бинарности.

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

>А нормальные реализации TCP/IP есть, хотя пакеты ни разу не в XML, а очень даже бинарные

1. а кто-то предлагал tcp/ip на зумль перевести?

2. и что будет с tcp/ip если я немного расширю формат пакета? :)

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

Господи, какой ужас! А для парсинга своих ini-подобный конфигов ты наверно ничего не пишешь, да? Или найти парсер на любимом яп-е тебе уже никак не получается?

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

Ты сейчас про ХМЛ??? Даже при обыкновенных плэйн-текстовых конфигах таким никогда не занимался. Может просто надо писать не через жопу?

>В случае LISP у тебя есть _один_ _универсальный_ язык. Твой XML'ный конфиг будет короче и читабельнее, если перевести его в S-expr, при этом программа-обработчик написана опять же на LISP и у тебя есть возможность использовать всю мощь LISP прямо в твоем конфиге, не трогая программу-обработчик.

Вот оно что! Просто мосье научился тыкать кнопки, но не научился выстраивать архитектуру программы. Очень сложно наверно написать пару классов с парсером конфигов, да? А тут бац - запарсил файл нативным лиспом и вуаля - кусок конфигов в памяти. Мой тебе совет - попробуй потом свой конфиг выпарси из чего-нибудь быдлокодерского (джавы, С, бэйсика...).

Меня вообще поражает как __лисп__ подпихивают вместо ХМЛ! Вы ребята совсем идиоты? Нет, я без шуток - серьёзно спрашиваю. Вы вместо SQL-я тоже будете свой лисп пропихивать?

ЗЫ: против лиспа ничего лично не имею.

весна наверное
все кажется что watashiwa_daredeska - девушка :)))))

поэтому полностью соглашусь
с лиспом и тд :))))

одно только
как в мою java программу встроить лисп интерпретатор
желательно соответствующий какому нибудь стандарту :))))
а кроме java у меня есть c#, c++, paskal, ocaml, haskel :))) .... ужос

и схему работы такой связки покажи пожалуста - интересно :)))
поподробнее :)))

а то ведь emacs - IDE для лиспа ....

PS: 42

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

>а кроме java у меня есть c#, c++, paskal, ocaml, haskel

выкидываешь это всё, и используешь исключительно лисп.

:)

> Меня вообще поражает как __лисп__ подпихивают вместо ХМЛ! Вы ребята совсем идиоты? Нет, я без шуток - серьёзно спрашиваю.

Если человек думает иначе это не значит что он идиот. Вполне может оказаться, что идиот это ты.

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

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

XML - Model
транслятор - View
твое приложение - Control

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

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

а типа лисп в любую нишу влезет, да? :) может перестанете гнать? Специализированное - оно всегда эффективнее, но часто и дороже.

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

так никто не спорит
в ряде случаев он удобен
для веба вообще сказка
так что ниша есть ! :))))

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

Естественно представляют. Вы можете копить данные, что бы обработать потом. Данные есть программы нет. Или, например, обработкой может заниматься не программа (бывает и такое).

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

Вы не всегда всё знаете об источники. Более того я утверждаю, что об источнике данных никогда абсолютно всё узнать не удастся.

Статьи, в которых описывается, как всё плохо, научного интереса не представляют. Интерес представляются статьи, где описывается, что именно нужно сделать, чтобы было лучше. Желательно, пошагово. Не тот случай.

> представьте веб страницу закодированную ASN

Представил. Ничего страшного, разве что не текст.

> только после того как вы перепишите весь софт работающий с XML под работу SExp и примете еще кучу стандартов для этого

Достаточно написать конвертор SExp<->XML и соблюдать некоторые правила при написании SExp'ов, чтоб не превысить возможности XML, а дальше плавный переход на SExp.

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

Неправда. См. http://www.cliki.net/HTML-from-sexpr

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

Если парсить так же, как эта пара сотен команд, то парсер SExp'ов будет не длиннее. Сами по себе SExp'ы не подразумевают наличия интерпретатора, но позволяют при необходимости легко интегрироваться с мощнейшим на сегодня языком.

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

... и будет тормознее, глючнее, намного беднее возможностями, чем LISP, язык на базе XML будет хуже интегрирован в проект, чем SExp'ы в LISP. В общем, десятое правило Гринспуна во всей красе. Да и LISP --- не только интерпретатор, но и компилятор.

> т.е. -у XML

с масштабируемостью всё очень плохо.

> XML парсер легко пишется и на ассемблере

Этот пасер также будет уметь валидацию по DTD, XML Schema, Namespaces, преобразования XSLT и пр. И всё это в 200 строк на асме! Сказочник. Скорее, тебе придется ходить каждый день 5 км в гору пешком, как Санычу :)

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

Никто на все вопросы не отвечает - xml в первую очередь предназначен для обмена данными. Всё - всё остальное от незнания.

Теперь давай спрошу - не хочешь ли ты доказать собравшимся тут господам, что на этой нише ему есть замена? Если да, то сразу давай пример - есть вэб-сервисы, общающиеся по XML: A <-xml-> B Получаемые от А данные проходят валидацию по DTD и при помощи XSLT переводятся во внутренний формат (например для скармливания БД).

Давай опиши мне используемое ПО и алгоритмы для обоих сервисов. Допустим ЯП - питон.

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

>а типа лисп в любую нишу влезет, да? :) может перестанете гнать? Специализированное - оно всегда эффективнее, но часто и дороже.

Даже интересно стало читаете ли вы то, на что отвечаете. Это риторический вопрос - очевидно нет.

Лисп крут в своём уголке, LaTeX в своём, plain text + unix-утилиты в своём - это разные нишы и решать эти задачи одним способом вовсе не признак ума.

>Почему же такой подход не используется?

По той же причине по которой ты используешь XSLTб а не ходишь циклами по дому. Результатом такого парсинга может быть только абстрактное дерево. Все остальные обходы кривоваты - прямая XSL трансформация выглядит более приятно.

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

Я где-то сказал про "сам по себе"? Я сказал, что при желании, ты можешь сдизайнить свой SExpr-based язык с возможностью использования полноценного LISP внутри, а не лепить убогий костыль вроде JavaScript. Как там, кстати, дела с описанием документов на XML aka XHTML, XJavaScript не слепили ишшо?

>Лисп крут в своём уголке, LaTeX в своём, plain text + unix-утилиты в своём - это разные нишы и решать эти задачи одним способом вовсе не признак ума.

нуну. А зумль, значит пихают во все дыры. И лисперы в этом треде вовсе не предлагали заменить зумль на лисп. Поделись травой, пжлста :)

>Никто на все вопросы не отвечает - xml в первую очередь предназначен для обмена данными. Всё - всё остальное от незнания.

О. Золотые слова. Между кем и кем обмен данными? Между програмами? То есть XML людям показывать ни в коем разе нельзя - скрывать надо.

> Статьи, в которых описывается, как всё плохо, научного интереса не представляют.

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

>Между кем и кем обмен данными? Между програмами? То есть XML людям показывать ни в коем разе нельзя - скрывать надо.

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

> только почему-то открытого бинарного im-протокола мир так и не увидел.

Честно говоря, я не ощущаю сильной потребности в IM, даже как-то наоборот. По последним исследованиям медиков, появилась новая зараза --- "синдром рассеянного внимания" называется, связана как раз с IM, SMS и прочей хреномутью. Те, кто работает, предпочитают выключать мобильник, даунить IMы, выдергивать телефон из розетки и пользоваться только почтой, чтоб не отвлекали всякие отморозки. Поэтому ничего удивительного, что IMы ваяют одни недоучки, которым просто делать нефиг.