XML, вероятно, худший из когда-либо появлявшихся языков программирования. Я не говорю об XML как о языке описания данных, которым он был в своем первоначальном дизайне. Я говорю о извращении XML для программирования приложений. Неуместно использовать XML как скриптовый язык (например, ANT), как язык описания тестов (например, TestNG), как язык описания объектно-реляционного отображения (например, Hibernate, JDO), как язык описания потоков управления (например, JSF) и т.д. Подобные XML "программы" нечитаемы, несопровождаемы, на порядок больше в размерах и безрассудно не эффективны в время исполнения.
Так почему же XML используется таким неподходящим образом? Насколько я могу судить, это потому, что многие так называемые программисты просто не знают, как сделать компилятор...
...Знать как сделать компилятор -- это, определенно, один из элементов в списке того, что нужно знать. Компиляторы являются фундаментом того, что мы делаем каждый день как программисты. Знание того, как компилятор работает позволит вам сделать грамотные решения о структуре программы, решения, которые имеют реальное влияние на качестве наших программ. Более того, множество программ занимаются разбором ввода (как от человека, так и от машины) и работают в зависимости от его содержимого. Чтобы сделать это, вам нужно сделать маленький компилятор. Портить XML для этих целей, просто из-за того, что у вас под рукой есть XML парсер, по меньшей мере, неуместно...
После чего он сетует на то, что хороших книг и ресурсов, которые бы способствовали изучению ремесла построения компиляторов не так уж и много.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Представляю себе цепочку причинно-следственных связей: E>
E>Используем XML чтобы не писать транслятор.
E>`-> Получили нечитабельные скрипты, используем XSTL (XML опять же)
E> чтобы получить читабельность.
E> `-> Невозможно преобразовать модифицированные читабельные скрипты
E> обратно в XML.
E> `-> Пишем транслятор читабельных скриптов чтобы преобразовать
E> их в XML. Который нечитабельный.
E> `-> Вспоминаем, что XML использовалься для того, чтобы не
E> писать транслятор.
E>
Ну кто так оформляет данные?!! Вот как надо:
<?xml version="1.0" encoding="windows-1251"?>
<ns1:problem subject="не хотим писать транслятор">
<ns1:solution rule="Используем XML">
<ns1:problem subject="Получили нечитабельные скрипты">
<ns1:solution rule="Используем XSLT" why="чтобы получить читабельность">
<ns1:whatIs what="XSLT">
<ns1:is-a-kind-of child="XSLT" parent="XML"/>
</ns1:whatIs>
<ns1:problem subject="Невозможно преобразовать модифицированные читабельные скрипты обратно в XML">
<ns1:solution rule="Пишем транслятор читабельных скриптов" why="чтобы преобразовать их в XML"> <!-- XML нечитаемый -->
<ns1:remember what="XML использовался для того, чтобы не писать транслятор">
</ns1:solution>
</ns1:problem>
</ns1:solution>
</ns1:problem>
</ns1:solution>
</ns1:problem>
Видишь, насколько удобнее стало? А понятнее? А проще? Вот! А ты говоришь!
XML — это язык конфигурирования и программирования данных. Я НЕ хочу
разбираться с кучей яызков для описания ДАННЫХ — я хочу один формат,
который я могу разбирать автоматическими средствами и не писать на
каждый чих по парсеру и компилятору. Я хочу иметь автокомплит, подсветку
ошибок на лету, поддерживаемость всеми современными IDE.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
kan>>>Напиши xsl-ку переводящую неудобный тебе формат в любой по вкусу. E>>А обратно?
ANS>Напиши транслятор
Представляю себе цепочку причинно-следственных связей:
Используем XML чтобы не писать транслятор.
`-> Получили нечитабельные скрипты, используем XSTL (XML опять же)
чтобы получить читабельность.
`-> Невозможно преобразовать модифицированные читабельные скрипты
обратно в XML.
`-> Пишем транслятор читабельных скриптов чтобы преобразовать
их в XML. Который нечитабельный.
`-> Вспоминаем, что XML использовалься для того, чтобы не
писать транслятор.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, kan, Вы писали:
kan>Mamut wrote:
>> Смотрим, например, вот в небольшой список XML Languages >> <http://xml.coverpages.org/xmlApplications.html>. Их там — 600 штук. И >> каждый — со своим, наверняка неудобочитаемым синтаксисом. И для каждого kan>Бред. Синтаксис всех XML-based языков одинаков и стандартизован.
Это вы бред говорите. Для компьютера он может и стандартизирован, а человеку по любому все время приходится учить новый язык. XML — это лишь оболочка, как другая кодировка, не более того. Для того, чтобы использовать VoiceXML, например, придется выучить новый язык и то, что он оформлен в виде XML НИЧЕМ абсолютно тебе в этом предприятии не поможет. XML помогает только ленивым программистам, которым в падлу написать компилятор/интрепретатор для более удобной для человека формы.
А вот писать потом программы на XML языке — это ад. Я, как однажды имевший несчастье это делать, готов плюнуть в лицо любому, кто станет проталкивать убожество типа VoiceXML и прочий креатив больных на голову разработчиков.
C# Application Markup Language (CSAML): An Evolutionary Leap
...
In fact, CSAML is able to rid itself of every symbol used in old-syntax C#. For example, consider the following old-syntax C# assignment statement:
A = 5 * (B + 27 * C);
This statement translates without much fuss into the following chunk of CSAML:
The advantages of this notation are obvious. Because no parentheses are required (or allowed), the programmer has composed the CSAML by carefully considering the problem. Errors are much less likely. The compiler can become more efficient as well because the statement has, in effect, been pre-parsed by the programmer.
...
Мне всегда казалось, что основная проблема XML — плохое отображение на привычные структуры данных.
Т.е. "в жизни", грубо говоря, "встречаются" основные структуры данных — скаляр, вектор, словарь (и вроде как бы и все, учитывая их вложенность — элемент вектора может быть скаляром-вектором-словарем и т.п.)
А в XML — "именованный данные с аттрибутами". Отсюда вечные проблемы отображения:
[1,2,3] => <array><value>1</value><value>2</value><value>3</value></array>
или
[1,2,3] => <array values='1,2,3'>
или
[1,2,3] => <array><item value='1'><item value='2'><item value='3'></array>
то же самое и со словарями.
Т.е. для сериализации данных удобнее какая-нито хрень типа помянутого JSON или более продвинутого YAML, которые базируются именно на "естественных" для программера структурах данных.
С другой стороны, вокруг XML накоплен интересный опыт: XPath, XSD, XSLT и т.п. — это все крайне полезные идеомы (паттерны, если хотите), которые могут (и должны) быть применены к другим, более удобным языкам описания данных.
ArtDenis wrote:
>> Напиши xsl-ку переводящую неудобный тебе формат в любой по вкусу. > Это не выход
А что выход? Изучать ещё один синтаксис? Если бы каждый писал свой компилятор на каждый случай, ты бы запоминал, что в
hibernate-маппингах в конце строки надо ставить ";", в ant надо ставить ".", в TestNG не надо ничего ставить, а вот в
jsf надо ";", но отделить пробелом. И в итоге ты бы также "Нае...лся с ant-ом по самое нехочу", т.к. там всё не так, как
в привычном тебе hibernate.
Плюс поиметь все радости проблем с кодировками.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Mamut, Вы писали:
M>Вот вопрос. Чем их ASN.1 не устроил?
a) ASN.1 совершенно не приспособлен к чтению людьми. Бинарная передача данных -- это задача ASN.1, но вот ручками там поправить что-нибудь, или хотя бы без какого-либо инструмента проверить значения в потоке данных, тут текстовые форматы удобнее. Не случайно Эрик Реймонд в своей книги "Искусство программирования под Unix" заостряет внимание на том, что текстовые форматы часто удобнее бинарных.
b) ASN.1, вообще-то говоря, не столь расширяем, как это может показаться. AFAIK, при проектировании протокола нужно специальным образом помечать места, в которых возможны дальнейшие расширения протокола. Что не просто. В XML-е (да и другом формате текстовой разметки), если не фиксировать жестко DTD, то можно при необходимости расширить любой тег (например, добавить в него атрибутов или дочерних элементов).
c) ASN.1 сразу ставит тебя перед высоким порогом вхождения. Во-первых, язык спецификаций. Во-вторых, ASN.1 компиляторы (писать вручную можно разве что ASN.1 BER, да и то не просто, а уж ASN.1 PER...). Их нужно искать, их нужно изучать, за хорошие нужно платить и не мало. В случае же с XML можно вооружиться инструментом, максимально подходящим для твоих нужд. Например, один раз мне потребовалось получить по HTTPS с сервера коротенькую XML-ку из которой мне нужно было значение только одного элемента. Воспользовался просто regex-ом. Генерить, опять же, XML вручную очень просто (если не сложный). Хотя низкий порог входжения в XML, как показал Голуб, как раз затем и приводит к необдуманному применению XML.
d) Насколько мне известно, ASN.1 не специфицирует отображение своей спецификации в язык программирования. Из-за этого каждый ASN.1 предоставляет собственный маппинг спецификации в классы/функции целевого языка. А из-за этого пользователи ASN.1 привязываются к производителю ASN.1 компилятора.
Так что, имхо, далеко не всегда ASN.1 является более выгодной альтернативой, чем XML. И наоборот. Хотя в некоторых случаях действительно задаешься вопросом: какого черта XML использован? Например, есть такая, имхо, маразматическая штука, как подписанный XML. Вот вместо него ASN.1 вполне мог применяться. Тем более, что области, в которых подписанный XML применяется (электронная коммерция), отнюдь не дешевые. И при разработке в них прикладных решений затраты на ASN.1 компиляторы вовсе не такие чувствительные.
Плохо то, что XML раскручен, а ASN.1 нет. Я, например, про него совершено случайно узнал. Поэтому при выборе решений многие разработчики такой альтернативы XML, как ASN.1 или, скажем, скриптовые языки, даже не видят. Из-за элементарного незнания.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
eao197 wrote:
> Судя по их истории <http://www.authorize.net/company/aboutus/>: > * November 1996 — Authorize.Net is founded in Provo, UT. > * March 1997 — Authorize.Net launches the eCheck.Net service. > * September 1997 — Authorize.Net partners with its first reseller, U.S. > Merchant Systems, initiating its world class reseller channel. > * December 1998 — Authorize.Net surpasses 10,000 active merchants. > основные проектные решения они принимали, когда XML еще не был в таком > фаворе, как сейчас.
Не то что фаворе, а его вообще не было! Первая релизная версия <br />
спецификации от 1998-года, когда Authorize.Net уже развернулись на всю катушку.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Вот хороший пример того, как делать не надо (VoiceXML) :
<?xml version="1.0"encoding="UTF-8"?>
<vxml version = 2.1 >
<meta name="maintainer" content="YOUR_EMAIL@SOMEWHERE.COM"/>
<form id="CallTransfer">
<block>
<prompt>Preparing to dial the number</prompt>
</block>
<!--
Make sure you have outbound dialing priveleges,
else any call attempts will result in a 'busy' event.
Contact support@voxeo.com for details
-->
<transfer name="MyCall" dest="tel:+1234567890"
bridge="true" connecttimeout="20s" maxtime="60s">
<filled>
<if cond="MyCall == 'busy'">
<prompt>
Sorry, our lines are busy. Please try again later.
</prompt>
<exit/>
<elseif cond="MyCall == 'noanswer'"/>
<prompt>
Hey, nobody is answering the phone.
</prompt>
<elseif cond="MyCall == 'far_end_disconnect'"/>
<prompt>
Your party must have hung up. how rude.
</prompt>
<elseif cond="MyCall == 'near_end_disconnect'"/>
<submit next ="MyCoolCleanupPage.jsp"/>
<elseif cond="MyCall == 'maxtime.disconnect'"/>
<prompt>
Your call ran over the maxtime of sixty seconds,
and your called party has been disconnected.
</prompt>
</if>
</filled>
</transfer>
</form>
</vxml>
Самое интересное, что даже в этой схеме им не удалось избавиться от скриптового языка — в ветках elseif используется атрибут cond, содержимое которого — JavaScript. Здесь это еще не так заметно, но я видел и более "ветвистые" условия, записанные на JS. Т.е. в результате получили ни то ни се — из XML взяли исключительно недостатки, выбросив достоинства. Результат — налицо.
Здравствуйте, Turtle.BAZON.Group, Вы писали:
TBG>Здравствуйте, ZevS, Вы писали:
ZS>>Я как раз про то, что удобно должно быть конечному пользователю продукта. Кроме того надеюсь ни кто не будет спорить что XML имеет множество приемуществ.
TBG>Хотелось бы послушать про преимущества ХыМыЛа для конечного пользователя продукта.
Пожалуйста:
Регулярный простой синтаксис.
Возможность просматривать данные в любом виде
Легкость контроля валидности
Относительная легкость интеграции и, возможно, перехода на новую версию продукта
Относительная легкость создания своих средств автоматизации и их простота
Относительная легкость анализа
Можно продолжить.
К реальным минусам можно отнести:
Громоздкость + избыточность
Сложность описания очень сложных читай не деревянных данных
Кривость описания данных с устоявшимся синтаксисом (мат. формулы и т.п.)
При большом количестве элементов желательность спец. редакторов, но от этого не избавляют и свои языки
eao197 wrote:
> После чего он сетует на то, что хороших книг и ресурсов, которые бы > способствовали изучению ремесла построения компиляторов не так уж и много.
xml к это не замена компилятора, а всего лишь лексического и синтаксического анализатора. Компилятор помимо этих двух
должен ещё иметь сематнический анализатор и кодогенератор (который не всегда нужен-то).
Так что рассуждения основаны на ложных посылках. В общем непонятно каким боком компилятор "заменяет" xml или в лушчем
случае похоже на рассуждения "вылить воду из чайника, сведя задачу к предыдущей".
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, kan, Вы писали:
>> Прошу перечитать первый абзац из высказываний Голуба (хоть на русском в >> моем переводе, хоть на английском в оригинале) -- проблемы с XML >> начинаются тогда, когда на нем начинают писать программы вместо >> декларативных описаний. Может быть кто-то и может воспринимать что-то >> подобное за нормальный if: kan>Ну так рассуждать, в когда вообще декларативное описание будет выгодее? kan>
Вполне нормальный вариант. В LaTeX-овой разметке, или в Wiki, или в ReST, конечно, компактнее, но вполне себе хорошо. Это как раз идеальная задача для XML подобной разметки. Для того и создавался.
kan>и что-то вроде kan>
Andrei N.Sobchuck wrote:
> M>ASN.1 *XER* > С таким названием, не удивительно, что они в массы не пошли
Есть такая штука XEP (вторая ссылка в русском гугле, не первая ).
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, trophim, Вы писали:
T>>Заметьте, кто поставил минус на основной пост... А я что? Так, просто...
E>Видимо, я перевод некачественный сделал
Здравствуйте, Mamut, Вы писали:
M> Экономить всегда полезно.
Вообще-то нормальные девелоперы, для того чтобы уменьшить трафик включают gzip, который собственно именно для этого и предназначен. А через LZW алгоритмы, xml скукоживается на порядки.
GZ>>Сложности возникают только когда начинают делать свои велосипеды из-за нереальной мысли что будет лучше. Как нибудь попробуй прочитать спецификацию XML(даже без остальных технологий). Он только кажется простым. И там учтено много подводных камней.
E>Здесь я с тобой согласен. Но меня вообще интересует, чтоже это за платежная система, которая вместо стандартных (хоть и сложных, и дорогих) решений позволяет использовать собственные key=value.
Нашел-таки Зрительная память — это вещь Ввел в гугле Payment Gateway и начал искать сайт, вид которого я отдаленно помнил
The Standard Transaction Submission API defines the information that can be submitted to the gateway for real-time transaction processing. The API consists of a set of fields that are required for each transaction, and a set of fields that are optional. Under the API, the gateway accepts a NAME/ VALUE pair. The NAME is the field name and indicates to the gateway what information is being submitted. VALUE contains the content of the field.
Дальше идут таблицы с необходимыми названиями полей.
И я на самом деле вас ... кхм ... напарил Там инициируется POST запрос к серверу по HTTPS, в котором передаются пары Name/Value. То есть, Authorize.net получает уже готовый разбор значений на халяву.
Здравствуйте, kan, Вы писали:
kan>Cyberax wrote: >>> вот в jsf надо ";", но отделить пробелом. >> Это не jsf, а jam. И я это пофиксил kan>ты лучше xml прикрути туда
Уже поздно. Я уже Питоновый backend туда прикручиваю.
Здравствуйте, kan, Вы писали:
>> Представляю себе цепочку причинно-следственных связей: kan>Это нужно делать только если ты эстет и проблемы со зрением "из-за обилия тегов и неудобной для восприятия глазом kan>структуры разметки". Лично мне при нормальном xml-редакторе (да если ещё и специально обученном данной xsd-шкой) kan>воспринимать структуру никто не мешает.
Прошу перечитать первый абзац из высказываний Голуба (хоть на русском в моем переводе, хоть на английском в оригинале) -- проблемы с XML начинаются тогда, когда на нем начинают писать программы вместо декларативных описаний. Может быть кто-то и может воспринимать что-то подобное за нормальный if:
Здравствуйте, Mamut, Вы писали:
M>И я на самом деле вас ... кхм ... напарил Там инициируется POST запрос к серверу по HTTPS, в котором передаются пары Name/Value. То есть, Authorize.net получает уже готовый разбор значений на халяву.
* November 1996 — Authorize.Net is founded in Provo, UT.
* March 1997 — Authorize.Net launches the eCheck.Net service.
* September 1997 — Authorize.Net partners with its first reseller, U.S. Merchant Systems, initiating its world class reseller channel.
* December 1998 — Authorize.Net surpasses 10,000 active merchants.
основные проектные решения они принимали, когда XML еще не был в таком фаворе, как сейчас.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, ZevS, Вы писали:
E>>Но ведь он и прав: даже если для задачи будет удобно сделать свой транслятор, мало кто будет сразу знать, за что хвататься.
ZS>Это вопрос квалификации, а не XML.
Так в том-то и смысл! По мнению Голуба (и не только его), квалификация сейчас у многих разработчиков настолько низкая, что они даже не смогут сделать оценку трудозатрат/рисков/преимуществ собственного транслятора перед XML (или наоборот). Это плохо, но и выхода не видно, т.к. нормальной литературы для обучения практики построения компиляторов по мнению Голуба не много. Такой-вот замкнутый круг.
ZS>Настораживает формулировка "если для задачи будет удобно сделать свой транслятор". Что заначит удобнее? Кому удобнее? Программисту Пете — фанату трансляторов и "красивых решений", а дальше хоть трава не расти?
Универсального ответа здесь нет, нужно смотреть на конкретные условия. Если речь идет о создании чего-либо, вроде Interface Definition Language или Data Definition Language, который будет предназначен для работы пользователей (как написанию, так и чтению) без наличия специализированных инструментов, то собственный транслятор может оказаться оправданным. Вот, к примеру, есть DocBook. Не знаю как кому, но я за него так и не взялся, поскольку набирать текст в VIM-е в XML не так уж просто. Нужны специализированные XML редакторы, заточенные под удобное редактирование DocBook-а. Между тем, LaTeX, при тех же, в общем-то, возможностях, совершенно спокойно редактируется как в VIM-е, так в Notepade, так и в FAR-е. Просто потому, что LaTeX-овый синтаксис ориентирован на работу человека с текстом. А Wiki-форматирование пошло еще дальше -- очень простой формат текста, но отлично решает поставленные перед ним задачи.
Вот вам бы, например, было бы удобно писать Wiki-странички в формате XML? И как вы думаете, получили бы Wiki-системы такое распространение, если бы в качестве языка разметки они предлагали пользователю XML?
Если же подразумевается передавать данные между приложениями, тогда изобретение собственного языка и транслятора действительно вряд ли будет оправдано (если только не вмешаются какие-нибудь специфические требования по эффективности/компактности, но и здесь есть возможность взять ASN.1). Для таких вещей XML предназначался и пусть именно для этого используется.
ZS>Очень спорная статья, я бы даже сказл — провокационная.
Я думаю, у нее изначально такая цель была -- спровоцировать внимание к этому вопросу. А то ведь под лежачий камень вода не течет.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
FR wrote: >> >> Напиши xsl-ку переводящую неудобный тебе формат в любой по вкусу. >> > Это не выход > kan>А что выход? Изучать ещё один синтаксис? > Зачем новый хватит или S-выражений или например чего-то forth образного.
А с кодировками как быть? А с entity (чтобы не ломать пальцы, набирая
какие-нибудь экзотические символы)?
Вот если все это прикрутить — получится ТОТ ЖЕ САМЫЙ XML, только вид с
профиля.
Mamut wrote:
> *Абсолютно* то же самое происходит и с ХМЛем
> <!-- version 1-->
> Это уже два абсолютно разных синтаксиса, каждый из которых надо учить. И
Это семантика, не путаем, плз. Редактор обученный xsd-шкой поможет в данном случае.
> помнить их различия, и орать матом на разработчиков, если в новой версии > они перейдут с одного синтаксиса на другой (а такое тоже бывает).
Если не сделают xsl-ки для конвертирования из старой версии — наорать, да самому наваять за пол часа.
>> > надо писать свой, неповторимый компилятор/интерпретатор/парсер. > kan>Чем обычные DOM/SAX парсеры не устраивают? А всякие хрени, генерящие > код объектной модели по xsd и прочие xml-object > kan>мапперы? > Потому что DOM/SAX парсеры — это хорошо. Но что делать, если verson 1 > будет заменен на version 2? Тогда мне все равно придется переписывать ту > часть программы, которая пользуется парсером, и перенастраивать маппер. > Причем мапперы каждый используют свой формат, который опять же придется > изучать с нуля. Потому что Castor > <http://www.castor.org/xml-mapping.html#3.-The-Mapping-File> > несовместим, например, с JAXB > <http://java.sun.com/webservices/docs/1.4/tutorial/doc/JAXBUsing3.html#wp150676>
БезXMLные альтернативы в студию. Да чтобы с совсместимостью, какую вы тут требуете.
> kan>А компилятор/интерпретатор, если нужен, придётся писать в любом случае. > kan>Часть этих 600 языков — языки разметки (FOP, DocBook, XBRL,...), для > них вообще не нужно писать > kan>компиляторы/интерпретаторы. Достаточно заюзать готовые либы > трансляции в html/pdf/rtf/etc. > А если либ нет?
А если компьютера нет? Свой паять?
> В общем, нет в ХМЛ ничего такого, что делало бы его панацеей... для чего > бы то ни было. Просто еще один формат данных, да еще не совсем удачный
А он и не панацея. Есть места где он неприменим, но те наезды что звучат здесь — мимо тазика.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, ZevS, Вы писали:
ZS>>Весь смысл статьи — "Печально я гляжу на не наше поколенье" и "да молодежь нонче не та, вот в наше время.."
E>Есть такое дело. E>Но ведь он и прав: даже если для задачи будет удобно сделать свой транслятор, мало кто будет сразу знать, за что хвататься.
Это вопрос квалификации, а не XML. Настораживает формулировка "если для задачи будет удобно сделать свой транслятор". Что заначит удобнее? Кому удобнее? Программисту Пете — фанату трансляторов и "красивых решений", а дальше хоть трава не расти?
Рассуждая в сторону, любую программу можно рассматривать как транслятор/интерпритатор/компилятор. Так что же теперь, для всех задачь придумывать свой язык? Кроме того, давно известно: больше кода — больше ошибок. Так что даже не знаю... Очень спорная статья, я бы даже сказл — провокационная.
Здравствуйте, Turtle.BAZON.Group, Вы писали:
TBG>Здравствуйте, ZevS, Вы писали:
TBG>>>Хотелось бы послушать про преимущества ХыМыЛа для конечного пользователя продукта.
ZS>>Пожалуйста: ZS>>
ZS>>Регулярный простой синтаксис. TBG>Особенно для тети Тани. Несомненно. ZS>>Возможность просматривать данные в любом виде TBG>Теперь следует объяснить пользователю его эту возможность и он возрадуется. Быть может. ZS>>Легкость контроля валидности TBG>Ты, как пользователь HTML, часто его на валидность проверяешь? ZS>>Относительная легкость интеграции и, возможно, перехода на новую версию продукта TBG>Мне, как пользователю это совершенно фиолетово. ZS>>Относительная легкость создания своих средств автоматизации и их простота TBG>Опять же, предыдующий пункт. ZS>>Относительная легкость анализа TBG>Для дотошного пользователя, может быть. ZS>>
Извините, но это демагогия.
TBG>Даже конфигурационный файл оказывается проще что-то в стиле KEY=VALUE. TBG>Я не за языки вместо ХМЛ — они тоже проблему не решат. Я за то, чтобы конечный пользователь владел все же мышой или чем-нибудь там и особо не напрягался, так как не любит.
Правда? А если конфигурация — это не пара значений, а сложная иерархическая структура?
Здравствуйте, eao197, Вы писали:
E>Вот вам бы, например, было бы удобно писать Wiki-странички в формате XML? И как вы думаете, получили бы Wiki-системы такое распространение, если бы в качестве языка разметки они предлагали пользователю XML?
Мне лично удобнее был бы XML. Просто по той причине, что разметочные маркеры предлагаемые многими wiki конфликтуют с тем, как мне нужно что-то записать, причём регулярно.
Например, где-то для подчёркивания пишется __x__. А если мне нужно описать например питоновый __init__? Или в MediaWiki пробел в начале строки создаёт (грубо говоря) таблицу. А если мне надо сделать отступ?
У XML регулярный конфликт только по трём символам "<>&" (ну, может ещё " — но это уже в полях, которые тут не интересуют). Элементарно сделать автоматическую подстановку при импорте текста. А с wiki — у каждой свои правила, все заточены на "интуитивные" подходы типа "вот тут оберните звёздочками" как будто никакой информации кроме плоского английского текста нет. И если делать импорт текста то приходится его чуть ли не целиком заворачивать, например, в две двойные кавычки (для WackoWiki). А если в тексте будут две двойные кавычки (а они будут, например, в сишной константе "строка длины 0")? Разворачивать перед ними, как-то их эскейпить, заворачивать обратно? Последний раз я такие извраты видел, когда передавались строки в команду для /bin/sh...
Видеть вместо всего этого бардака простые и понятные <u>...</u> в разы понятнее и проще. Подход один, единообразен, достаточно удобен как человеку, так и машине. И что важно — общие правила просты и немногочисленны. Думаю, это и есть те причины, по которым вообще продвигается XML: вместо туевой хучи локальных язычков, сляпанных обычно кое-как на коленке и постоянно страдающих от недоработки, он дал один общий метод и инфраструктуру (те же валидаторы и преобразователи). Фактически я видел до того (если не считать SGML) только один более-менее нормальный язык разметки — roff. Но у того всё-таки ориентация на форматирование для печати, а не на представление "вообще".
Вот уже на языки программирования я бы такой подход не распространял — там обычно немного другая... мнэээ... мотивация принятых решений.
>>> Напиши xsl-ку переводящую неудобный тебе формат в любой по вкусу. >> Это не выход kan>А что выход? Изучать ещё один синтаксис? Если бы каждый писал свой компилятор на каждый случай, ты бы запоминал, что в kan>hibernate-маппингах в конце строки надо ставить ";", в ant надо ставить ".", в TestNG не надо ничего ставить, а вот в kan>jsf надо ";", но отделить пробелом. И в итоге ты бы также "Нае...лся с ant-ом по самое нехочу", т.к. там всё не так, как kan>в привычном тебе hibernate. kan>Плюс поиметь все радости проблем с кодировками.
Как говорится, ню-ню
Смотрим, например, вот в небольшой список XML Languages. Их там — 600 штук. И каждый — со своим, наверняка неудобочитаемым синтаксисом. И для каждого надо писать свой, неповторимый компилятор/интерпретатор/парсер.
То, что ХМЛ — это одинаковая для всех панацея, — миф, уже неоднократно развенчанный.
M>>Вот вопрос. Чем их ASN.1 не устроил?
E>a) ASN.1 совершенно не приспособлен к чтению людьми. Бинарная передача данных -- это задача ASN.1, но вот ручками там поправить что-нибудь, или хотя бы без какого-либо инструмента проверить значения в потоке данных, тут текстовые форматы удобнее. Не случайно Эрик Реймонд в своей книги "Искусство программирования под Unix" заостряет внимание на том, что текстовые форматы часто удобнее бинарных.
Тут фишка еще в том, что, ИМХО, ASN.1 можно было бы легко передавать и напрямую в тексте, то есть, не компилируя его в бинарный формат. И наоборот, ХМЛ тоже можно было бы копилировать, если бы кто-нить задался бы таким вопросом
Неее... ХМЛ — это зло
E>b) ASN.1, вообще-то говоря, не столь расширяем, как это может показаться. AFAIK, при проектировании протокола нужно специальным образом помечать места, в которых возможны дальнейшие расширения протокола. Что не просто. В XML-е (да и другом формате текстовой разметки), если не фиксировать жестко DTD, то можно при необходимости расширить любой тег (например, добавить в него атрибутов или дочерних элементов).
Unlike many other syntaxes which claim to be extensible, ASN.1 offers extensibility which addresses the problem of, and provides support for, the interworking between previously deployed systems and newer, updated versions designed years apart.
Я, правда, тоже не спец
E>c) ASN.1 сразу ставит тебя перед высоким порогом вхождения. Во-первых, язык спецификаций. Во-вторых, ASN.1 компиляторы (писать вручную можно разве что ASN.1 BER, да и то не просто, а уж ASN.1 PER...). Их нужно искать, их нужно изучать, за хорошие нужно платить и не мало.
Есть такое. Но, имхо, если бы тот же W3C взялся бы за ASN.1, оставил бы его в текстовом формате, да продвинул бы его, стуация была бы иной.
E>Хотя низкий порог входжения в XML, как показал Голуб, как раз затем и приводит к необдуманному применению XML.
См. также Don’t Invent XML Languages
E>d) Насколько мне известно, ASN.1 не специфицирует отображение своей спецификации в язык программирования. Из-за этого каждый ASN.1 предоставляет собственный маппинг спецификации в классы/функции целевого языка. А из-за этого пользователи ASN.1 привязываются к производителю ASN.1 компилятора.
Ну так то же самое можно сказать и о ХМЛ
E>Так что, имхо, далеко не всегда ASN.1 является более выгодной альтернативой, чем XML. И наоборот. Хотя в некоторых случаях действительно задаешься вопросом: какого черта XML использован? Например, есть такая, имхо, маразматическая штука, как подписанный XML. Вот вместо него ASN.1 вполне мог применяться. Тем более, что области, в которых подписанный XML применяется (электронная коммерция), отнюдь не дешевые. И при разработке в них прикладных решений затраты на ASN.1 компиляторы вовсе не такие чувствительные.
Кстати, читал я описание протокола обменна данными с каим-то из payment gateways. Там народ поступил легко и просто Никакого ХМЛ. Пары ключ-значение, разделенные точками с запятыми и переводами строки. Аж глаз отдыхает
E>Плохо то, что XML раскручен, а ASN.1 нет. Я, например, про него совершено случайно узнал. Поэтому при выборе решений многие разработчики такой альтернативы XML, как ASN.1 или, скажем, скриптовые языки, даже не видят. Из-за элементарного незнания.
Здравствуйте, Mamut, Вы писали:
M>Ну и так далее вся секция integration такая
M>И я на самом деле вас ... кхм ... напарил Там инициируется POST запрос к серверу по HTTPS, в котором передаются пары Name/Value. То есть, Authorize.net получает уже готовый разбор значений на халяву.
Довелось работать с 3мя платежками: Verisign, YourPay и Authorize.net. Так вот скажу, что Authorize.net как раз таки самая неудобная из этих 3-х.
Здравствуйте, Mamut, Вы писали:
M>>>И я на самом деле вас ... кхм ... напарил Там инициируется POST запрос к серверу по HTTPS, в котором передаются пары Name/Value. То есть, Authorize.net получает уже готовый разбор значений на халяву. ie>>Довелось работать с 3мя платежками: Verisign, YourPay и Authorize.net. Так вот скажу, что Authorize.net как раз таки самая неудобная из этих 3-х. M>А что в Verisign и Yourpay испольщуется? Таки ХМЛ?
E>XML, вероятно, худший из когда-либо появлявшихся языков программирования. Я не говорю об XML как о языке описания данных, которым он был в своем первоначальном дизайне...
Еще пару капелек масла в огонь священной войны против XML На этот раз в качестве информации к размышлению о производительности. Разработчики распределенной системы контроля версий Bazaar в новой версии 0.15 отказались от использования XML в качестве формата для хранения описаний в рабочей копии. За счет чего получили серьезный прирост производительности на некоторых операциях (по ссылке рассказывается об ускорении операции status на дереве исходников ядра Linux-а от 2.2 до 13.9 раз(!)). До этого разработчики Subversion так же отказались от использования XML в описателях рабочей копии (см. 1.4 release notes, раздел Working copy performance improvements).
Т.е. имеет смысл задумываться о выборе XML в качестве хранилища данных. Далеко не все ладно в Датском-то королевстве
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, ZevS, Вы писали:
ZS>Я как раз про то, что удобно должно быть конечному пользователю продукта. Кроме того надеюсь ни кто не будет спорить что XML имеет множество приемуществ.
Хотелось бы послушать про преимущества ХыМыЛа для конечного пользователя продукта.
Полностью с ним согласен. Нае...лся с ant-ом по самое нехочу
Заставить работать скрипт анта не так уж и сложно. Гораздо сложнее --
через какое-то время понять, что ты там такое понаписал и что твой код
делает. А всё это — из-за обилия тегов и неудобной для восприятия глазом
структуры разметки.
ArtDenis wrote:
> Полностью с ним согласен. Нае...лся с ant-ом по самое нехочу > Заставить работать скрипт анта не так уж и сложно. Гораздо сложнее -- > через какое-то время понять, что ты там такое понаписал и что твой код > делает. А всё это — из-за обилия тегов и неудобной для восприятия глазом > структуры разметки.
Напиши xsl-ку переводящую неудобный тебе формат в любой по вкусу.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Andrei N.Sobchuck wrote:
> kan>>Напиши xsl-ку переводящую неудобный тебе формат в любой по вкусу. > E>А обратно? > Напиши транслятор
Точнее следует ответить так:
Напиши то, что советует писать автор статьи каждый раз в обязательном порядке.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
C>eao197 wrote: >> Мнение Алана Голуба: Just Say No to XML >> <http://www.sdtimes.com/fullcolumn/column-20060901-05.html> C>Досталлллло!
C>XML — это язык конфигурирования и программирования данных. Я НЕ хочу C>разбираться с кучей яызков для описания ДАННЫХ — я хочу один формат, C>который я могу разбирать автоматическими средствами и не писать на C>каждый чих по парсеру и компилятору. Я хочу иметь автокомплит, подсветку C>ошибок на лету, поддерживаемость всеми современными IDE.
Dmitry Azaraev: не скажу шо очень понятно, но целевая штука другая всё таки
Dmitry Azaraev: xml сам по себе ничо не стоит. а его схемы — это пестец
Dmitry Azaraev: их в нормальном здравом уме ж писать нивазможна
Dmitry Azaraev: а править автосгенерированные это ишо хуже
dmitriid: ну а в асн можно передавать сложные структуры данных, и не бояться, что принимающая сторона их не пройдет
dmitriid:
Dmitry Azaraev: ну пройдёт или не пройдёт — всё равно принимающая сторона должна знать шо за данные и чо с ними делать
Dmitry Azaraev: само ж оно не сделаетсо
dmitriid: ну, это верно
dmitriid: в общем, ХМЛ cpommittee придумали очередной баян и радуются
Здравствуйте, kan, Вы писали:
kan>ArtDenis wrote:
>>> Напиши xsl-ку переводящую неудобный тебе формат в любой по вкусу. >> Это не выход kan>А что выход? Изучать ещё один синтаксис?
Зачем новый хватит или S-выражений или например чего-то forth образного.
Mamut wrote:
> Смотрим, например, вот в небольшой список XML Languages > <http://xml.coverpages.org/xmlApplications.html>. Их там — 600 штук. И > каждый — со своим, наверняка неудобочитаемым синтаксисом. И для каждого
Бред. Синтаксис всех XML-based языков одинаков и стандартизован.
> надо писать свой, неповторимый компилятор/интерпретатор/парсер.
Чем обычные DOM/SAX парсеры не устраивают? А всякие хрени, генерящие код объектной модели по xsd и прочие xml-object
мапперы?
А компилятор/интерпретатор, если нужен, придётся писать в любом случае.
Часть этих 600 языков — языки разметки (FOP, DocBook, XBRL,...), для них вообще не нужно писать
компиляторы/интерпретаторы. Достаточно заюзать готовые либы трансляции в html/pdf/rtf/etc.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
>> Смотрим, например, вот в небольшой список XML Languages >> <http://xml.coverpages.org/xmlApplications.html>. Их там — 600 штук. И >> каждый — со своим, наверняка неудобочитаемым синтаксисом. И для каждого kan>Бред. Синтаксис всех XML-based языков одинаков и стандартизован.
Стандартизирован настолько, насколько буквы русского алфавита стандартизированы для русского языка — не более.
А что выход? Изучать ещё один синтаксис? Если бы каждый писал свой компилятор на каждый случай, ты бы запоминал, что в
hibernate-маппингах в конце строки надо ставить ";", в ant надо ставить ".", в TestNG не надо ничего ставить, а вот в
jsf надо ";", но отделить пробелом. И в итоге ты бы также "Нае...лся с ant-ом по самое нехочу", т.к. там всё не так, как
в привычном тебе hibernate.
Абсолютно то же самое происходит и с ХМЛем
Потому что:
<!-- version 1-->
<dataElement type="MyType">
<publicfields>
<field type="subType">value</field>
</publicfields>
</dataElement>
и
<!-- version 2-->
<dataElement type="MyType">
<field type="subType" visibility="public">value</field>
</dataElement>
Это уже два абсолютно разных синтаксиса, каждый из которых надо учить. И помнить их различия, и орать матом на разработчиков, если в новой версии они перейдут с одного синтаксиса на другой (а такое тоже бывает).
>> надо писать свой, неповторимый компилятор/интерпретатор/парсер. kan>Чем обычные DOM/SAX парсеры не устраивают? А всякие хрени, генерящие код объектной модели по xsd и прочие xml-object kan>мапперы?
Потому что DOM/SAX парсеры — это хорошо. Но что делать, если verson 1 будет заменен на version 2? Тогда мне все равно придется переписывать ту часть программы, которая пользуется парсером, и перенастраивать маппер. Причем мапперы каждый используют свой формат, который опять же придется изучать с нуля. Потому что Castor несовместим, например, с JAXB
kan>А компилятор/интерпретатор, если нужен, придётся писать в любом случае. kan>Часть этих 600 языков — языки разметки (FOP, DocBook, XBRL,...), для них вообще не нужно писать kan>компиляторы/интерпретаторы. Достаточно заюзать готовые либы трансляции в html/pdf/rtf/etc.
А если либ нет?
В общем, нет в ХМЛ ничего такого, что делало бы его панацеей... для чего бы то ни было. Просто еще один формат данных, да еще не совсем удачный
Здравствуйте, ZevS, Вы писали:
ZS>Это вопрос квалификации, а не XML. Настораживает формулировка "если для задачи будет удобно сделать свой транслятор". Что заначит удобнее? Кому удобнее? Программисту Пете — фанату трансляторов и "красивых решений", а дальше хоть трава не расти?
Ну всегда удобно кому-то. Ты предлагаешь заменить Петю на Ваню, фаната xml?
ZS>Рассуждая в сторону, любую программу можно рассматривать как транслятор/интерпритатор/компилятор. Так что же теперь, для всех задачь придумывать свой язык? Кроме того, давно известно: больше кода — больше ошибок. Так что даже не знаю... Очень спорная статья, я бы даже сказл — провокационная.
Может оказаться, что кода получится меньше. Использование скриптов — возможность вынести логику из основного кода. В результате сам "основной код" может стать проще и короче. И гибкость повысится — скрипты проще модифицировать. Я думаю, это и значит "удобнее для задачи".
Здравствуйте, Quintanar, Вы писали:
Q>Это вы бред говорите. Для компьютера он может и стандартизирован, а человеку по любому все время приходится учить новый язык.
Вы оба правы и не правы. Синтаксис одинаков если за него принимать сам ХМЛ. И разный если оговориваться, что ХМЛ уточняется специаьными конструкциями и ключевыми словами.
Что до чтения, то с одной стороны базирующиеся на ХМЛ языки проще изучать так как часть синтаксиса уже ясна, но конечно их все равно нужно изучать для понимания формата. Потому и говорят "формат основанный на ХМЛ".
Что касается применений, то ХМЛ конечно никуда не годен как основа для ЯП. Но как формат хранения данных он очень неплох. Формат на то и нужен чтобы него не читать в таком виде постянно, а чтобы хранить в нем что-то с возможностью если нужно открыть файл в текстовом редакторе и подправить что нужно. Так что для разного роде конфигов, форматов файлов (например, Word/Excel/MSBuild), форматов передачи данных по сети и т.п. он отлично подходит. А делать из чего-то панаценю и не надо.
ЗЫ
Не надо бравировать словами панацея и серебрянная пуля. Что за манера наклеивать ярлыки?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Так почему же XML используется таким неподходящим образом? Насколько я могу судить, это потому, что многие так называемые программисты просто не знают, как сделать компилятор...
Именно. Это вечный "наш" аргумент в борьбе с использованием XML направо и налево. Хорошо, что авторитеты начали озвучивать это же мнение.
eao197 wrote:
> Вот так же и про XML авторитеты могут говорить и даже показывать личным > примером, как от этого отказаться. Но командовать парадом будет > засыпанный с головы до ног синтаксическим сахаром мейнстрим. Ведь дело
Мейнстрим становится таковым не просто так.
> дошло даже до того, что, например, в Scala XML может включаться > непосредственно в текст программы.
Кстати, в Firefox 1.5 уже можно в Javascript (ECMAScript) <br />
включать.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Mamut, Вы писали:
M>Вот интересно, почему все же был выбран SGML за основу
В первую очередь, чтобы построить связку XHTML+CSS. HTML, в котором сразу замешаны и данные, и визуализация не очень удовлетворял. А затем ребят понесло. Но должен сказать, что в том контексте, в котором он описан и применяется в W3C, XML вполне эффективен.
Здравствуйте, eao197, Вы писали:
E>Вопрос в том, почему в данном случае не был использован какой-либо из стандартных протоколов?
Стандартных? А xml у нас нестандартный получается? А теперь найди хотя бы одно бесплатное разборщик для одного из твоих протоколов(ну кроме Visa-3D, который сам по себе XML). И чтобы там легко можно было получить данные(типа DOM+XPath+XQuery), и чтобы уследить за структурированностью данных(типа XSD). E>Если это какая-то наколенная система, и сами разработчики устанавливают в ней правила, то они вполне могли обойтись и без XML, чтобы не плодить лишних сложностей.
Сложности возникают только когда начинают делать свои велосипеды из-за нереальной мысли что будет лучше. Как нибудь попробуй прочитать спецификацию XML(даже без остальных технологий). Он только кажется простым. И там учтено много подводных камней.
eao197 wrote:
> А теперь представь, что у тебя 200-ти строк такого кода, в которых ты > ищещь баг. Распечатываешь, чтобы прошерстить исходники в спокойной > обстановке с карандашом в руках. Тебе будет удобно среди <тегов> суть > выискивать?
Дело привычки и ничего более.
Я не помню, чтобы я когда либо код печатал и с карандашом над ним сидел, мне неудобно бумагу юзать.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Cyberax, Вы писали:
C>XML — это язык конфигурирования и программирования данных. Я НЕ хочу C>разбираться с кучей яызков для описания ДАННЫХ — я хочу один формат,
Google использует множество различных типов данных, которые передаются в виде сообщений между серверами. Большинство из них имеют иерархическую структуру, которую необходимо представлять в определенном виде. Использование XML в этом случае неэффективно, так как когда сеть и узлы работают на полную мощность, обработка XML отнимает слишком много ресурсов. Кроме того, код для работы с деревом DOM иногда может быть очень громоздким.
Protocol Buffers позволяет описывать простые структуры данных используя специальный язык, который затем компилируется в классы, однозначно представляющие эти структуры в любом выбранном языке программирования. Классы обрабатываются хорошо-оптимизированными парсерами и могут быть сохранены в очень компактной форме. Но что более важно, это легкость их использования: у каждого поля структуры есть свои "get" и "set" методы, и в случае надобности сохранения (или чтения) этого поля в виде массива байтов или же I/O потока, оно осуществляется вызовом соответствующего метода. Полная независимость структуры классов от программ-обработчиков позволяет безболезненно обновлять программы, скомпилированные под «старый» формат.
Mamut wrote: > Вот вопрос. Чем их ASN.1 не устроил?
Ответ: назови мне 10 полностью свободных и бесплатных решений для ASN
для С++, Java, Perl, PHP, C, C#.
eao197 wrote:
> Представляю себе цепочку причинно-следственных связей:
Это нужно делать только если ты эстет и проблемы со зрением "из-за обилия тегов и неудобной для восприятия глазом
структуры разметки". Лично мне при нормальном xml-редакторе (да если ещё и специально обученном данной xsd-шкой)
воспринимать структуру никто не мешает.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
eao197 wrote: > Прошу перечитать первый абзац из высказываний Голуба (хоть на русском в > моем переводе, хоть на английском в оригинале) -- проблемы с XML > начинаются тогда, когда на нем начинают писать программы вместо > декларативных описаний. Может быть кто-то и может воспринимать что-то > подобное за нормальный if
Понимаешь, в некоторых случаях на 10Кб декларативного кода приходится
несколько сотен байт подобного императивного. Стоит ли ради небольшого
неудобства лепить отдельный компилятор?
В принципе, для меня нет большой разницы использовать ли Ant (который
XML) или Jam (в котором свой язык) с точки зрения удобства языка. В
Ant'е я получаю подсветку ошибок и автокомплит по XSD, в Jam'е — удобное
квотирование и лаконичность.
Здравствуйте, Cyberax, Вы писали:
C>Понимаешь, в некоторых случаях на 10Кб декларативного кода приходится C>несколько сотен байт подобного императивного. Стоит ли ради небольшого C>неудобства лепить отдельный компилятор?
Ради небольшого, естественно, нет.
А вот если на 400 байт декларативного описания приходится еще 4K императивщины, тогда...
C>В принципе, для меня нет большой разницы использовать ли Ant (который C>XML) или Jam (в котором свой язык) с точки зрения удобства языка. В C>Ant'е я получаю подсветку ошибок и автокомплит по XSD, в Jam'е — удобное C>квотирование и лаконичность.
А я недавно от другого примера слегка ошалел. Для одной из утилит требовалось делать набор описаний в конфигах. Описания довольно однообразные и вручную делать их было ну очень муторно, да и черевато глупыми ошибками. Чтобы упростить их создание был сделан Ruby генератор, который на своем DSL позволял задать только часть описаний, а все остальное делал сам. Более того, чуть-чуть с ним поработав, прямо в DSL была определена вспомогательная функция, которая еще больше сокращала количество описаний. В результате DSL из десяти строчек приводил к генерации десятка конфигурационных файлов с сотнями строк в каждом. Да и сам код генератора оказался гораздо меньше по объему, чем генерируемые им файлы.
Вот теперь следующая идея ждет своего воплощения: встраивать Ruby-интерпритатор прямо в приложение, чтобы DSL им парсился и информация из DSL непосредственно в приложение поступала.
НО! Все это хорошо, пока настройки из приложения обратно в DSL сохранять не нужно.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Cyberax wrote:
>> >> вот в jsf надо ";", но отделить пробелом. >> > Это не jsf, а jam. И я это пофиксил > kan>ты лучше xml прикрути туда > Уже поздно. Я уже Питоновый backend туда прикручиваю.
Хотя бы. Но не то убожество, ещё один язык... брр...
А на каком этапе находится? Я ведь до сих пор не решился какую билд-систему заюзать... что-то идея cmake меня тоже не
вдохновила.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
FR wrote:
>> >> Напиши xsl-ку переводящую неудобный тебе формат в любой по вкусу. >> > Это не выход > kan>А что выход? Изучать ещё один синтаксис? > > Зачем новый хватит или S-выражений или например чего-то forth образного.
А как быть с DOM/SAX/XSD/XPath/XSLT? Что из этого можно прикрутить? Особенно интересуют схемы XSD/RelaxNG.
Да и мне честно говоря пофиг что писать "(" или "<", в чём выигрыш?
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
eao197 wrote:
> Прошу перечитать первый абзац из высказываний Голуба (хоть на русском в > моем переводе, хоть на английском в оригинале) -- проблемы с XML > начинаются тогда, когда на нем начинают писать программы вместо > декларативных описаний. Может быть кто-то и может воспринимать что-то > подобное за нормальный if:
Ну так рассуждать, в когда вообще декларативное описание будет выгодее?
Здравствуйте, kan, Вы писали:
kan>FR wrote:
>>> >> Напиши xsl-ку переводящую неудобный тебе формат в любой по вкусу. >>> > Это не выход >> kan>А что выход? Изучать ещё один синтаксис? >> >> Зачем новый хватит или S-выражений или например чего-то forth образного. kan>А как быть с DOM/SAX/XSD/XPath/XSLT? Что из этого можно прикрутить? Особенно интересуют схемы XSD/RelaxNG. kan>Да и мне честно говоря пофиг что писать "(" или "<", в чём выигрыш?
Уже ни в чем
Просто похоже те кто разрабатывал XML не думали что его будут использовать как скриптовый язык, по моему это дурость.
eao197 wrote:
> А это лучше заменить на <http://markaby.rubyforge.org/>: > > html { > head { > title 'Hi' > } > body { > p { > 'Hello, world!' > } > } > }
Output defaults to XHTML 1.0 Transitional
А как это проверить? И что мне сделать, чтобы оно было, скажем, WML 1.2.1?
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
eao197 wrote: > Ради небольшого, естественно, нет. > А вот если на 400 байт декларативного описания приходится еще 4K > императивщины, тогда...
Тогда действительно дело нечисто
Build-системы как раз стоят посередине между императивщиной и
декларативным описанием.
> Вот теперь следующая идея ждет своего воплощения: встраивать > Ruby-интерпритатор прямо в приложение, чтобы DSL им парсился и > информация из DSL непосредственно в приложение поступала.
А зачем?
Mamut wrote:
> M>>Вот вопрос. Чем их ASN.1 не устроил? > WH>Если мне не изменяет скалероз то он насквозь бинарный... > В нем есть XER, кодирующий его в ХМЛ (веяние времени, однако )
Подумаешь, бином Ньютона. А наоборот?
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Mamut wrote:
>> > Вот вопрос. Чем их ASN.1 не устроил? > C>Ответ: назови мне 10 полностью свободных и бесплатных решений для ASN > C>для С++, Java, Perl, PHP, C, C#. > Ну вот в том-то и дело
Кто виноват? Что делать?
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Mamut wrote:
> Кстати, читал я описание протокола обменна данными с каим-то из payment > gateways. Там народ поступил легко и просто Никакого ХМЛ. Пары > ключ-значение, разделенные точками с запятыми и переводами строки. Аж > глаз отдыхает
А в какой кодировке? А как иерархию сделать? А может ли ключ содержать ";"? А может ли значение содержать перевод
строки? А как массив значений передать (список — имя/телефон, притом телефон опционален)?
Понятно, что в данном конкретном случае ничего этого, наверное, не надо. Но не надо простые случаи обобщать.
В общем уроды, могли бы заюзать url-form-encoded формат или даже csv, нет, придумали свой велосипед.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
kan>Понятно, что в данном конкретном случае ничего этого, наверное, не надо. Но не надо простые случаи обобщать.
Так бОльшая часть случаев как раз укладывается в простые
kan>В общем уроды, могли бы заюзать url-form-encoded формат или даже csv, нет, придумали свой велосипед.
>> M>>Вот вопрос. Чем их ASN.1 не устроил? >> WH>Если мне не изменяет скалероз то он насквозь бинарный... >> В нем есть XER, кодирующий его в ХМЛ (веяние времени, однако ) kan>Подумаешь, бином Ньютона. А наоборот?
>>> > Вот вопрос. Чем их ASN.1 не устроил? >> C>Ответ: назови мне 10 полностью свободных и бесплатных решений для ASN >> C>для С++, Java, Perl, PHP, C, C#. >> Ну вот в том-то и дело kan>Кто виноват? Что делать?
Маркетинг виноват Подняли бы вокруг него столько же шумихи, сколько вокруг ХМЛ, то же самое было бы
Quintanar wrote:
>> > Смотрим, например, вот в небольшой список XML Languages >> > <http://xml.coverpages.org/xmlApplications.html> > <http://xml.coverpages.org/xmlApplications.html>>. Их там — 600 штук. И >> > каждый — со своим, наверняка неудобочитаемым синтаксисом. И для каждого > kan>Бред. Синтаксис всех XML-based языков одинаков и стандартизован. > > Это вы бред говорите. Для компьютера он может и стандартизирован, а > человеку по любому все время приходится учить новый язык. XML — это лишь > оболочка, как другая кодировка, не более того. Для того, чтобы > использовать VoiceXML, например, придется выучить новый язык и то, что > он оформлен в виде XML НИЧЕМ абсолютно тебе в этом предприятии не > поможет. XML помогает только ленивым программистам, которым в падлу > написать компилятор/интрепретатор для более удобной для человека формы. > А вот писать потом программы на XML языке — это ад. Я, как однажды > имевший несчастье это делать, готов плюнуть в лицо любому, кто станет > проталкивать убожество типа VoiceXML и прочий креатив больных на голову > разработчиков.
Тот пример voiceXML что тут приводился, действительно бред. Но это не вина xml, а тех, кто этот voicexml придумывали,
ибо люди не удосужились прочитать рекомендации как писать языки, так что ещё неизвестно, что бы они наворотили без
использования xml.
До абсурда можно довести любую идею.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Mamut wrote:
>> >> > Вот вопрос. Чем их ASN.1 не устроил? >> > C>Ответ: назови мне 10 полностью свободных и бесплатных решений для ASN >> > C>для С++, Java, Perl, PHP, C, C#. >> > Ну вот в том-то и дело > kan>Кто виноват? Что делать? > Маркетинг виноват Подняли бы вокруг него столько же шумихи, сколько > вокруг ХМЛ, то же самое было бы
Как ни прискорбно знать, но маркетинг обычно отражает реальные требования (тем более если учесть некоммерческое
происхождение XML с w3c.org), а не "единственно верные" решения.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Mamut wrote:
> kan>Понятно, что в данном конкретном случае ничего этого, наверное, не > надо. Но не надо простые случаи обобщать. > Так бОльшая часть случаев как раз укладывается в простые
И чем такая штука была бы хуже? Чем сложнее?
Зато ни у кого никаких бы вопросов не возникло бы.
> kan>В общем уроды, могли бы заюзать url-form-encoded формат или даже > csv, нет, придумали свой велосипед. > Ну, так там примерно CSV и получился
И какого хера тогда? Вместо того, чтобы взять готовый кусок кода для работы с CSV, программист вынужден писать очередной
велосипед.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, kan, Вы писали:
kan>Тот пример voiceXML что тут приводился, действительно бред. Но это не вина xml, а тех, кто этот voicexml придумывали, kan>ибо люди не удосужились прочитать рекомендации как писать языки, так что ещё неизвестно, что бы они наворотили без kan>использования xml. kan>До абсурда можно довести любую идею.
Не нефига, я неправильно выразился. VoiceXML сделан очень грамотно, многое в нем неплохо продумано. Был бы очень приятный язык, если бы не xml.
Здравствуйте, kan, Вы писали:
>> В общем, нет в ХМЛ ничего такого, что делало бы его панацеей... для чего >> бы то ни было. Просто еще один формат данных, да еще не совсем удачный kan>А он и не панацея. Есть места где он неприменим, но те наезды что звучат здесь — мимо тазика.
Изначально речь шла о том, что XML плох в качестве языка программирования. По этому поводу вы что можете сказать?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
>> <!-- version 1-->
>> Это уже два абсолютно разных синтаксиса, каждый из которых надо учить. И kan>Это семантика, не путаем, плз. Редактор обученный xsd-шкой поможет в данном случае.
Если файл больше одной страницы текста, то ни один редактор не поможет (мне, например, влом разбираться)
>> помнить их различия, и орать матом на разработчиков, если в новой версии >> они перейдут с одного синтаксиса на другой (а такое тоже бывает). kan>Если не сделают xsl-ки для конвертирования из старой версии — наорать, да самому наваять за пол часа.
А оно мне надо?
kan>БезXMLные альтернативы в студию. Да чтобы с совсместимостью, какую вы тут требуете.
Таких и нет. Но и пропагандировать ХМЛ, как панацею, которая ручками, в редакторе, за полчаса, и еще неизвестно, заработает ли, тоже пропагандировать не надо
>> kan>А компилятор/интерпретатор, если нужен, придётся писать в любом случае. >> kan>Часть этих 600 языков — языки разметки (FOP, DocBook, XBRL,...), для >> них вообще не нужно писать >> kan>компиляторы/интерпретаторы. Достаточно заюзать готовые либы >> трансляции в html/pdf/rtf/etc. >> А если либ нет? kan>А если компьютера нет? Свой паять?
Легко!
>> В общем, нет в ХМЛ ничего такого, что делало бы его панацеей... для чего >> бы то ни было. Просто еще один формат данных, да еще не совсем удачный kan>А он и не панацея. Есть места где он неприменим, но те наезды что звучат здесь — мимо тазика.
Имхо, он вообще нигде не применим Для конфигов легче использовать YAML/JSON/INI, особенно, если их руками надо править, а для всего остального он не предназначен. Имхо, конечно.
eao197 wrote:
>> > В общем, нет в ХМЛ ничего такого, что делало бы его панацеей... для чего >> > бы то ни было. Просто еще один формат данных, да еще не совсем удачный > kan>А он и не панацея. Есть места где он неприменим, но те наезды что > звучат здесь — мимо тазика.
> Изначально речь шла о том, что XML плох в качестве языка > программирования. По этому поводу вы что можете сказать?
Насчёт языков программирования ещё могу согласится, но "описания тестов", "описания объектно-реляционного отображения",
"описания потоков управления" уже со скрипом, особенно, если в качестве альтернанивы предлагается написать свой
собственный компилятор, да ещё и сетует "ремесла построения компиляторов не так уж и много".
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
>> kan>Понятно, что в данном конкретном случае ничего этого, наверное, не >> надо. Но не надо простые случаи обобщать. >> Так бОльшая часть случаев как раз укладывается в простые kan>И чем такая штука была бы хуже? Чем сложнее? kan>
kan>Зато ни у кого никаких бы вопросов не возникло бы.
Так как это payment gateway, то им критичны объемы передаваемой информации.
Что-то в стиле:
payment:1;2;34.5;;
всяко меньше, чем в ХМЛ.
>> kan>В общем уроды, могли бы заюзать url-form-encoded формат или даже >> csv, нет, придумали свой велосипед. >> Ну, так там примерно CSV и получился kan>И какого хера тогда? Вместо того, чтобы взять готовый кусок кода для работы с CSV, программист вынужден писать очередной kan>велосипед.
CSV им не особо подходит, потому что на одних значениях не уедешь, а там довольно разнообразная информация передается (аутентикация, типы карточек, суммы, типы оплат, информация о пользователе...). Жаль, я сейчас просто не вспомню, что это за gateway был Но формат у них был легчайший. А ответы могли разбираться даже простейшим split() по какому-то символу.
>>> >> > Вот вопрос. Чем их ASN.1 не устроил? >>> > C>Ответ: назови мне 10 полностью свободных и бесплатных решений для ASN >>> > C>для С++, Java, Perl, PHP, C, C#. >>> > Ну вот в том-то и дело >> kan>Кто виноват? Что делать? >> Маркетинг виноват Подняли бы вокруг него столько же шумихи, сколько >> вокруг ХМЛ, то же самое было бы kan>Как ни прискорбно знать, но маркетинг обычно отражает реальные требования (тем более если учесть некоммерческое kan>происхождение XML с w3c.org), а не "единственно верные" решения.
Тот же ASN.1 — вполне себе открытый стандарт, уже включающий в себя многое из того, чтов ХМЛ нет и не предвидится, и для чего приходится выдумывать новые стандарты. См. Re[4]: Снова XML: Just Say No to XML
w3c достаточно было оставить ASN.1 как есть, в текстовом формате, без компиляции, и был бы готовый новый ХМЛ. А там бы и тулзы подтянулись бы. Благо парсить его будет полегче, чем ХМЛ, да и на больших файлах он выгоднее.
Вот интересно, почему все же был выбран SGML за основу
Заранее прошу прощения за длинное сообщение
CS>... Ну дык json то рулез я всегда говорил...
Ну не всегда. Сейчас попробовал один из своих средних размеров конфигов в JSON представить. Дошел только до половины, затем устал -- слишком много синтаксических заморочек (необходимость использования массивов, числа не имеют шестнадцатиричного представления и пр.). Вот что получилось (извиняюсь за объем, но это всего лишь половина того, что нужно):
Здравствуйте, SergH, Вы писали:
ZS>>Это вопрос квалификации, а не XML. Настораживает формулировка "если для задачи будет удобно сделать свой транслятор". Что заначит удобнее? Кому удобнее? Программисту Пете — фанату трансляторов и "красивых решений", а дальше хоть трава не расти? SH>Ну всегда удобно кому-то. Ты предлагаешь заменить Петю на Ваню, фаната xml?
Нет, даже не так, это еще бы было полбеды. На самом деле предлагается заменить программиста и разработчика системы Петю на множество Вась — пользователей этой системы. И еще не факт, что они будут фанатеть от навязанного им XML, особенно если внедряется он не ради их удобства, а просто потому что "зачем ломать голову, если есть SAX/DOM" и "не хватало нам еще тратить ресурсы на собственный парсер".
..
SH>Ну всегда удобно кому-то. Ты предлагаешь заменить Петю на Ваню, фаната xml?
Я как раз про то, что удобно должно быть конечному пользователю продукта. Кроме того надеюсь ни кто не будет спорить что XML имеет множество приемуществ.
ZS>>Рассуждая в сторону, любую программу можно рассматривать как транслятор/интерпритатор/компилятор. Так что же теперь, для всех задачь придумывать свой язык? Кроме того, давно известно: больше кода — больше ошибок. Так что даже не знаю... Очень спорная статья, я бы даже сказл — провокационная.
SH>Может оказаться, что кода получится меньше. Использование скриптов — возможность вынести логику из основного кода. В результате сам "основной код" может стать проще и короче. И гибкость повысится — скрипты проще модифицировать. Я думаю, это и значит "удобнее для задачи".
Вынести логику из основного кода невозможно. Конечно если это — основная логика. Даже если логику забить в таблицу базы данных — основной код будет уже в таблице базы данных.
И не факт что поддерживать основной код на доморощенном языке будет проще, удобнее и гибче.... Хотя конечно все зависит он конкретной задачи, и дальше лозунгов в отрыве от нее не уйти.
VladD2 wrote:
> kan>Это семантика, не путаем, плз. Редактор обученный xsd-шкой поможет в > данном случае. > > Это ты путашь. Это как раз синтаксис. Семантика это интерпретация данных.
Ээ... Тег это синтаксическая единица. А вот тег "html" это уже семантическая, означающая корневой "оператор программы
браузеру". Как функция в С++ — синтаксическая единица, а вот функция "main" — семантическая, означающая точку входа в
программу. Разве не так?
> Ты же говоришь о базовм синтаксисе. Только языки базирующиеся на ХМЛ > добавляют к ХМЛ свои ограничения и синтаксические правила.
В случае "языки базирующиеся на С++" можно рассматривать API, библиотеки. Сделали "#include <vector>", можем
использовать семантическую единицу "std::vector", сделали "xmlns='http://www.w3.org/1998/Math/MathML'", можем
использовать "<math><apply><fn/>...".
По-моему полная аналогия. И те же проблемы с версиями, обратной совместимостью — поменяли API — переписывай программу,
поменяли XSD-шку — переписывай маппинг.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
eao197 wrote:
> ZS>Это вопрос квалификации, а не XML. > > Так в том-то и смысл! По мнению Голуба (и не только его), квалификация > сейчас у многих разработчиков настолько низкая, что они даже не смогут > сделать оценку трудозатрат/рисков/преимуществ собственного транслятора > перед XML (или наоборот). Это плохо, но и выхода не видно, т.к. > нормальной литературы для обучения практики построения компиляторов по > мнению Голуба не много. Такой-вот замкнутый круг.
Если квалификация не позволяет написать вменяемый xml (тут
), то какой же получится компилятор?
Так что xml тут совершенное не при чём.
> Вот вам бы, например, было бы удобно писать Wiki-странички в формате > XML? И как вы думаете, получили бы Wiki-системы такое распространение, > если бы в качестве языка разметки они предлагали пользователю XML?
+
Обычным смертным пользователям действительно страшно видеть xml-теги, хотя тот же MS Word уже пытается решить эту проблему.
> Если же подразумевается передавать данные между приложениями, тогда > изобретение собственного языка и транслятора действительно вряд ли будет > оправдано (если только не вмешаются какие-нибудь специфические > требования по эффективности/компактности, но и здесь есть возможность > взять ASN.1). Для таких вещей XML предназначался и пусть именно для > этого используется.
Интерфейс к платёжной системе — имхо тот случай. Однако, и тут начинают экономить <br />
непонятно на чём
...
ZS>>Это вопрос квалификации, а не XML.
E>Так в том-то и смысл! По мнению Голуба (и не только его), квалификация сейчас у многих разработчиков настолько низкая, что они даже не смогут сделать оценку трудозатрат/рисков/преимуществ собственного транслятора перед XML (или наоборот). Это плохо, но и выхода не видно, т.к. нормальной литературы для обучения практики построения компиляторов по мнению Голуба не много. Такой-вот замкнутый круг.
Что поделать — эра фаст фуда. Человек трятящий каждый день на обед 4 часа с моционом — либо очень богат и ленив, либо дурак.
ZS>>Настораживает формулировка "если для задачи будет удобно сделать свой транслятор". Что заначит удобнее? Кому удобнее? Программисту Пете — фанату трансляторов и "красивых решений", а дальше хоть трава не расти?
E>Универсального ответа здесь нет, нужно смотреть на конкретные условия.
+1
E>Если речь идет о создании чего-либо, вроде Interface Definition Language или Data Definition Language, который будет предназначен для работы пользователей (как написанию, так и чтению) без наличия специализированных инструментов, то собственный транслятор может оказаться оправданным. Вот, к примеру, есть DocBook. Не знаю как кому, но я за него так и не взялся, поскольку набирать текст в VIM-е в XML не так уж просто. Нужны специализированные XML редакторы, заточенные под удобное редактирование DocBook-а. Между тем, LaTeX, при тех же, в общем-то, возможностях, совершенно спокойно редактируется как в VIM-е, так в Notepade, так и в FAR-е. Просто потому, что LaTeX-овый синтаксис ориентирован на работу человека с текстом. А Wiki-форматирование пошло еще дальше -- очень простой формат текста, но отлично решает поставленные перед ним задачи.
Пример с форматированием текста на мой взгляд не очень убедительный. Мне лично удобнее набирать текст в том же ворде. ))
>> Если же подразумевается передавать данные между приложениями, тогда >> изобретение собственного языка и транслятора действительно вряд ли будет >> оправдано (если только не вмешаются какие-нибудь специфические >> требования по эффективности/компактности, но и здесь есть возможность >> взять ASN.1). Для таких вещей XML предназначался и пусть именно для >> этого используется. kan>Интерфейс к платёжной системе — имхо тот случай. Однако, и тут начинают экономить <br />
<span class='lineQuote level1'>kan>непонятно на чём</span>
Ну, как сказать "непонятно" Если клиентуры много и надо обрабатывать очень большое количество платежей, то тупой парсинг
key=value;key=value;key=value
будет, во-первых, быстрее парсинга(ну или маппинга на объекты) многословного ХМЛя. А во-вторых, вместо, скажем, гигабайта данных в день удастся передать 700 мегабайтов в день на экономии только тэгов. Цифры взяты с потолка, конечно, но можно и подсчитать:
Например, мы посылаем ИД клиента, тип уплаты, номер кредитки, проверосный код, кол-во денег.
У нас добавляется по 2 символа на значение, что при больших объемах влетает в копеечку
Ну и, во-вторых, парсер ХМЛ уже сложнее. Ненамного, а оно нам нужно?
Mamut wrote:
> будет, во-первых, быстрее парсинга(ну или маппинга на объекты) > многословного ХМЛя. А во-вторых, вместо, скажем, гигабайта данных в день > удастся передать 700 мегабайтов в день на экономии только тэгов. Цифры > взяты с потолка, конечно, но можно и подсчитать: > Например, мы посылаем ИД клиента, тип уплаты, номер кредитки, > проверосный код, кол-во денег.
Если 700 мегабайтов, 1 платёж — 700 байтов (а это много даже для максимально многословного xml), то это миллион
платежей, даже по одному доллару — это миллион долларов в день. Знаешь, те кто имеет такие деньги — может положить
себе крутейшие сети и этот трафик будет пофиг.
Кстати, прикольно поглядеть на jabber протокол — полностью xml-based, никто не жалуется.
> Гипотетический код платежной системы: > > payment::clientid=2ni3poicy5b8924v;ptype=VISA;ccno=1234567890123456;vcode=12345;amount=23.5;; > > > Максимально упрощенный ХМЛ: > > <payment clientid="2ni3poicy5b8924v" ptype="VISA" ccno="1234567890123456" vcode="12345" amount="23.5" /> > У нас добавляется по 2 символа на значение, что при больших объемах > влетает в копеечку
Экономия на спичках, назвается.
> Ну и, во-вторых, парсер ХМЛ уже сложнее. Ненамного, а оно нам нужно?
Да, но его не надо писать, кто его пишет — сам себе злобный буратино.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, vdimas, Вы писали:
E>>Так почему же XML используется таким неподходящим образом? Насколько я могу судить, это потому, что многие так называемые программисты просто не знают, как сделать компилятор...
V>Именно. Это вечный "наш" аргумент в борьбе с использованием XML направо и налево. Хорошо, что авторитеты начали озвучивать это же мнение.
Угу, только знаешь какая аналогия напрашивается? Вот Вирт давно говорит, что язык программирования должен быть минималистическим и простым (показывая это на примерах своих творений). Только правят бал перегруженные монстры, вроде C++ или Java.
Вот так же и про XML авторитеты могут говорить и даже показывать личным примером, как от этого отказаться. Но командовать парадом будет засыпанный с головы до ног синтаксическим сахаром мейнстрим. Ведь дело дошло даже до того, что, например, в Scala XML может включаться непосредственно в текст программы.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Я не буду судить о корректности принятого там решения, посколько совершенно не в теме. На первый взгляд кажется, что XML дейсвительно там напрашивается. Но... Платежные системы, насколько я знаю, уже обладают стандартным протоколами (например, двоичный ISO 8583, SET, основанные на HTTP+XML протоколы в системе Visa 3D Secure). Вопрос в том, почему в данном случае не был использован какой-либо из стандартных протоколов? Если это какая-то наколенная система, и сами разработчики устанавливают в ней правила, то они вполне могли обойтись и без XML, чтобы не плодить лишних сложностей.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
>> будет, во-первых, быстрее парсинга(ну или маппинга на объекты) >> многословного ХМЛя. А во-вторых, вместо, скажем, гигабайта данных в день >> удастся передать 700 мегабайтов в день на экономии только тэгов. Цифры >> взяты с потолка, конечно, но можно и подсчитать: >> Например, мы посылаем ИД клиента, тип уплаты, номер кредитки, >> проверосный код, кол-во денег. kan>Если 700 мегабайтов, 1 платёж — 700 байтов (а это много даже для максимально многословного xml), то это миллион kan>платежей, даже по одному доллару — это миллион долларов в день. Знаешь, те кто имеет такие деньги — может положить kan>себе крутейшие сети и этот трафик будет пофиг.
Экономить всегда полезно.
Это кстати, косвенное отражение общей тенденции сегодняшних дней — "пофиг, что много, мы его задавим объемами сетей/компов/памяти". Экономить разучились совсем.
kan>Кстати, прикольно поглядеть на jabber протокол — полностью xml-based, никто не жалуется.
Читаю наискосок описание. Гы. Как туториал по общению через сокеты читаю
Пошлите START
Пошлите информацию
Пошлите END
В RFC это описывают Xml Streams and Xml Stanzas.
>> Гипотетический код платежной системы: >> >> payment::clientid=2ni3poicy5b8924v;ptype=VISA;ccno=1234567890123456;vcode=12345;amount=23.5;; >> >> >> Максимально упрощенный ХМЛ: >> >> <payment clientid="2ni3poicy5b8924v" ptype="VISA" ccno="1234567890123456" vcode="12345" amount="23.5" /> >> У нас добавляется по 2 символа на значение, что при больших объемах >> влетает в копеечку kan>Экономия на спичках, назвается.
Спички-спичками, но когда таких спичек много...
>> Ну и, во-вторых, парсер ХМЛ уже сложнее. Ненамного, а оно нам нужно? kan>Да, но его не надо писать, кто его пишет — сам себе злобный буратино.
Как это не надо писать? Даже если его и написали, то это написал кто-то, доверия к кому может и не быть. И _в любом_ случае работа с ХМЛ никогда не побьет по простоте вот это:
// псевдо код
MessageArray = split(message, "::");
KeyValueArray = split(MessageArray(1), ";");
for(...)
{
KeyValuePair = split(KeyValueArray[i], '=');
}
// где split может быть невероятно шустрым
В то время, как для ХМЛ придется писать callback функции для SAX, долго разбирать структуру для DOM и т.п. Зачем? Если в нашем случае наш же собственный велосипед будет приспособлен именно для наших нужд и оптимизирован по самое нехочу?
Здравствуйте, GlebZ, Вы писали:
E>>Вопрос в том, почему в данном случае не был использован какой-либо из стандартных протоколов? GZ>Стандартных? А xml у нас нестандартный получается?
XML -- это eXtensible Makeup Language. Он никогда не являлся стандартным протоколом для какого-либо вида электронной коммерции. Поскольку кроме формата данных, в протоколе специфицируются и фазы обмена данными, ответственность сторон, поведение сторон в тех или иных ситуациях и пр.
Глеб, извини, но ты мог бы уже так дословно к словам не цепляться.
GZ>А теперь найди хотя бы одно бесплатное разборщик для одного из твоих протоколов(ну кроме Visa-3D, который сам по себе XML). И чтобы там легко можно было получить данные(типа DOM+XPath+XQuery), и чтобы уследить за структурированностью данных(типа XSD).
Для ISO 8583, например, вот.
Что касается SET, то там ситуация, насколько я помню, не простая. И инструменты для поддержки SET, помниться, подлежат сертификации.
Что касается Visa 3DS, то и там не простой парсинг, а со своими заморочками. Кроме того, XML там должен быть подписанным.
E>>Если это какая-то наколенная система, и сами разработчики устанавливают в ней правила, то они вполне могли обойтись и без XML, чтобы не плодить лишних сложностей. GZ>Сложности возникают только когда начинают делать свои велосипеды из-за нереальной мысли что будет лучше. Как нибудь попробуй прочитать спецификацию XML(даже без остальных технологий). Он только кажется простым. И там учтено много подводных камней.
Здесь я с тобой согласен. Но меня вообще интересует, чтоже это за платежная система, которая вместо стандартных (хоть и сложных, и дорогих) решений позволяет использовать собственные key=value.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Mamut wrote:
>> > будет, во-первых, быстрее парсинга(ну или маппинга на объекты) >> > многословного ХМЛя. А во-вторых, вместо, скажем, гигабайта данных в день >> > удастся передать 700 мегабайтов в день на экономии только тэгов. Цифры >> > взяты с потолка, конечно, но можно и подсчитать: >> > Например, мы посылаем ИД клиента, тип уплаты, номер кредитки, >> > проверосный код, кол-во денег. > kan>Если 700 мегабайтов, 1 платёж — 700 байтов (а это много даже для > максимально многословного xml), то это миллион > kan>платежей, даже по одному доллару — это миллион долларов в день. > Знаешь, те кто имеет такие деньги — может положить > kan>себе крутейшие сети и этот трафик будет пофиг. > Экономить всегда полезно.
Это называется преждевременной оптимизацией.
> Это кстати, косвенное отражение общей тенденции сегодняшних дней — > "пофиг, что много, мы его задавим объемами сетей/компов/памяти". > Экономить разучились совсем.
Это дорого.
> Читаю наискосок описание. Гы. Как туториал по общению через сокеты читаю > Пошлите START > Пошлите информацию > Пошлите END
Не знаю, вот лог миранды:
Не знаю что всё это означает, честно говоря.
>> > Гипотетический код платежной системы: >> > >> > > payment::clientid=2ni3poicy5b8924v;ptype=VISA;ccno=1234567890123456;vcode=12345;amount=23.5;; >> > >> > >> > Максимально упрощенный ХМЛ: >> > >> > <payment clientid="2ni3poicy5b8924v" ptype="VISA" > ccno="1234567890123456" vcode="12345" amount="23.5" /> >> > У нас добавляется по 2 символа на значение, что при больших объемах >> > влетает в копеечку > kan>Экономия на спичках, назвается. > > Спички-спичками, но когда таких спичек много... > >> > Ну и, во-вторых, парсер ХМЛ уже сложнее. Ненамного, а оно нам нужно? > kan>Да, но его не надо писать, кто его пишет — сам себе злобный буратино. > > Как это не надо писать? Даже если его и написали, то это написал кто-то, > доверия к кому может и не быть. И _в любом_ случае работа с ХМЛ никогда > не побьет по простоте вот это:
> // псевдо код
> MessageArray = split(message, "::");
> KeyValueArray = split(MessageArray(1), ";");
> for(...)
> {
> KeyValuePair = split(KeyValueArray[i], '=');
> }
>
> // где split может быть невероятно шустрым
А вот тоже самое, но для xml в случае DOM:
payment = message.getRootElement()
Вот дальше самое интересное, что ты не дописал, допиши если всё ещё считаешь, что будет просто.
function makePayment(clientId, amount, cardNo);
function checkCard(cardType, cardNo, cardVCode);
....
if(checkCard(payment.getAttribute("ptype"), payment.getAttribute("ccno"), payment.getAttribute("vcode"))
{
makePayment(payment.getAttribute("cientid"), payment.getAttribute("amount"), payment.getAttribute("ccno"))
}
А если заюзать какой-нибудь xml-object mapping, то будет вообще красота.
В случае SAX (скажем, что одним потоком можно обработать сколь угодно много запросов, которые не влезут в память) будет
чуть посложнее, конечно, но в случае поточной обработки твой подход будет гораздо сложнее.
> В то время, как для ХМЛ придется писать callback функции для SAX, долго > разбирать структуру для DOM и т.п. Зачем? Если в нашем случае наш же > собственный велосипед будет приспособлен именно для наших нужд и > оптимизирован по самое нехочу?
Ну-ну.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, eao197, Вы писали:
E>Глеб, извини, но ты мог бы уже так дословно к словам не цепляться.
Собственно, я и обратил внимание на то, что рассуждения идут о протоколах разных уровней.
E>Для ISO 8583, например, вот.
Это уже смешно: http://jpos.org/products
ISO/Bridge — ISO-8583 Made Easy
But if you are not a Java shop, or even if you are, but you just want to focus on your business logic without having to deal with low level ISO-8583 communications details, then ISO/Bridge is probably an alternative you ought to evaluate.
You can think of ISO/Bridge as a blackbox that sits between your application and the ISO-8583 host(s). It uses an extremely easy to implement XML-based protocol that simplify the burden of dealing with ISO-8583 messages, bitmaps, channels, packagers, headers, multiplexers and the like.
E>Здесь я с тобой согласен. Но меня вообще интересует, чтоже это за платежная система, которая вместо стандартных (хоть и сложных, и дорогих) решений позволяет использовать собственные key=value.
Проблема в том, что стандартных решений очень мало. Пока нет единого, всеми выполняемого решения(неважно, основано оно на xml или нет) каждый делает так как ему хочется. Иногда неплохо получается, но иногда и фигня выходит. Кстати, я не знаток платежных систем, но вроде бы у нас стандартизовали клиент-банк на основе XML.
), то какой же получится > компилятор? > А как вот этот, по-вашему, можно сделать вменяемым?
<elseif/> не отражает структуру документа. Можно хотя бы как <xsl:choose> сделать.
Ну и разобраться почему в @cond надо ставить javascript... может можно обойти это дело, что нибудь готовое заюзать,
xpath какой-нибудь.
Только не надо меня убеждать что
if(someting)
{
}
чем-то лучше чем
<if test="something">
</if>
При использовании любого вменяемого xml-редактора — разницы никакой (теги сами закрываются, так что </if> писать не
придётся, обязательные аттрибуты сами печатаются, так что "test=" тоже набирать не придётся).
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
>> Экономить всегда полезно. kan>Это называется преждевременной оптимизацией.
Ну, я думаю, товарищи в payment gateway'e уже непреждевременной занимаются
>> Это кстати, косвенное отражение общей тенденции сегодняшних дней — >> "пофиг, что много, мы его задавим объемами сетей/компов/памяти". >> Экономить разучились совсем. kan>Это дорого.
Это верно
>> Читаю наискосок описание. Гы. Как туториал по общению через сокеты читаю >> Пошлите START >> Пошлите информацию >> Пошлите END kan>Не знаю, вот лог миранды: kan>
[skip] >> Как это не надо писать? Даже если его и написали, то это написал кто-то, >> доверия к кому может и не быть. И _в любом_ случае работа с ХМЛ никогда >> не побьет по простоте вот это:
kan>
>> // псевдо код
>> MessageArray = split(message, "::");
>> KeyValueArray = split(MessageArray(1), ";");
>> for(...)
>> {
>> KeyValuePair = split(KeyValueArray[i], '=');
>> }
>>
>> // где split может быть невероятно шустрым
kan>
kan>А вот тоже самое, но для xml в случае DOM:
kan>
kan>payment = message.getRootElement()
kan>
kan>Вот дальше самое интересное, что ты не дописал, допиши если всё ещё считаешь, что будет просто. kan>
kan>А если заюзать какой-нибудь xml-object mapping, то будет вообще красота.
У нас так же возможны ситуации, когда создание лишних объектов в памяти дорого.
kan>В случае SAX (скажем, что одним потоком можно обработать сколь угодно много запросов, которые не влезут в память) будет kan>чуть посложнее, конечно, но в случае поточной обработки твой подход будет гораздо сложнее.
Тут надо смотреть на реальных примерах, но кто ж их даст?
>> В то время, как для ХМЛ придется писать callback функции для SAX, долго >> разбирать структуру для DOM и т.п. Зачем? Если в нашем случае наш же >> собственный велосипед будет приспособлен именно для наших нужд и >> оптимизирован по самое нехочу? kan>Ну-ну.
M>> Экономить всегда полезно. GZ>Вообще-то нормальные девелоперы, для того чтобы уменьшить трафик включают gzip, который собственно именно для этого и предназначен. А через LZW алгоритмы, xml скукоживается на порядки.
Здравствуйте, GlebZ, Вы писали:
E>>Для ISO 8583, например, вот. GZ>Это уже смешно: GZ>http://jpos.org/products GZ>
GZ>ISO/Bridge — ISO-8583 Made Easy
GZ>But if you are not a Java shop, or even if you are, but you just want to focus on your business logic without having to deal with low level ISO-8583 communications details, then ISO/Bridge is probably an alternative you ought to evaluate.
GZ>You can think of ISO/Bridge as a blackbox that sits between your application and the ISO-8583 host(s). It uses an extremely easy to implement XML-based protocol that simplify the burden of dealing with ISO-8583 messages, bitmaps, channels, packagers, headers, multiplexers and the like.
Вообще-то говоря, вполне разумное решение. Получается возможность реализовывать клиентов на любом языке. Хоть на C#, хоть на Ruby, хоть на Perl. Вся работа с двоичными данными сосредоточена в java-вском коде.
Еще один пример: протоколы работы с MMS-ками реализованы на основе SOAP-а. Что позволяет реализовывать MMS-сервисы на чем хочешь -- хоть на C++, хоть на Java, хоть на Tcl. Хотя казалось бы, там overhead значительный должен выходить, ведь бинарные данные (картинки, звук) передаются в base64. И ничего, все замечаетльно пашет.
Это как раз примеры того, как XML используется по теме.
E>>Здесь я с тобой согласен. Но меня вообще интересует, чтоже это за платежная система, которая вместо стандартных (хоть и сложных, и дорогих) решений позволяет использовать собственные key=value.
GZ>Проблема в том, что стандартных решений очень мало. Пока нет единого, всеми выполняемого решения(неважно, основано оно на xml или нет) каждый делает так как ему хочется. Иногда неплохо получается, но иногда и фигня выходит. Кстати, я не знаток платежных систем, но вроде бы у нас стандартизовали клиент-банк на основе XML.
Так вот и я про то, что в данном случае речь идет о какой-то нестандартной платежной системе. В которой разработчики могут творить, что хотят. Но, опять же, не зная подробностей, не хочется утвержать, что они напрасно от XML отказались. Может они платежи с каких-нибудь аппаратов делают, встроенные системы разрабатывают, где ресурсы не позвляют XML парсинг делать.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, kan, Вы писали:
kan>Только не надо меня убеждать что kan>
kan>if(someting)
kan>{
kan>}
kan>
kan>чем-то лучше чем kan>
kan><if test="something">
kan></if>
kan>
kan>При использовании любого вменяемого xml-редактора — разницы никакой (теги сами закрываются, так что </if> писать не kan>придётся, обязательные аттрибуты сами печатаются, так что "test=" тоже набирать не придётся).
А какая альтернатива в XML будет, например, у:
if something && ( something_else || ( first && second && third ) )
...bla-bla-bla...
elsif another || yet_another || or_yet_another
...bla-bla-bla...
else
...trundec...
end
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
>> > Как это не надо писать? Даже если его и написали, то это написал кто-то, >> > доверия к кому может и не быть. И _в любом_ случае работа с ХМЛ никогда >> > не побьет по простоте вот это:
Побило как ребёнка.
> У нас так же возможны ситуации, когда создание лишних объектов в памяти > дорого.
Ну не создавай. Кто ж заставляет?
> kan>В случае SAX (скажем, что одним потоком можно обработать сколь > угодно много запросов, которые не влезут в память) будет > kan>чуть посложнее, конечно, но в случае поточной обработки твой подход > будет гораздо сложнее. > Тут надо смотреть на реальных примерах, но кто ж их даст?
Ты хотя бы прикинь код на твоих любимых split-ах, который будет парсить поток строк <payment/>, что ты приводил, и,
скажем, вызывать checkCard/makePayment и записывать в выходной поток результат вроде
<result clientid="2ni3poicy5b8924v"/>
<result clientid="vqxernty853ty32q" error="1244">Мятые купюры не принимаем</result>
и сравни это с банальным SAX-фильтром.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
eao197 wrote:
> А какая альтернатива в XML будет, например, у: > > if something && ( something_else || ( first && second && third ) ) > ...bla-bla-bla... > elsif another || yet_another || or_yet_another > ...bla-bla-bla... > else > ...trundec... > end
Если что-то типа подхода xslt (для условий используется xpath):
<choose>
<when test="something and (something_else or (first and second and third))">
...bla-bla-bla...
</when>
<when test="another or yet_another or or_yet_another">
...bla-bla-bla...
</when>
<otherwise>
...trundec...
</otherwise>
</choose>
Хотя в условиях и javascript можно использовать. Испольозование xml не запрещает использовать другие языки. Вон, в
html/svg javascript тоже активно юзается, никто не жалуется.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
>>> > Как это не надо писать? Даже если его и написали, то это написал кто-то, >>> > доверия к кому может и не быть. И _в любом_ случае работа с ХМЛ никогда >>> > не побьет по простоте вот это: kan>Побило как ребёнка.
Только при условии создания DOM-объекта
>> У нас так же возможны ситуации, когда создание лишних объектов в памяти >> дорого. kan>Ну не создавай. Кто ж заставляет?
Тогда не получится легкости типа payment = message.getRootElement()
>> kan>В случае SAX (скажем, что одним потоком можно обработать сколь >> угодно много запросов, которые не влезут в память) будет >> kan>чуть посложнее, конечно, но в случае поточной обработки твой подход >> будет гораздо сложнее. >> Тут надо смотреть на реальных примерах, но кто ж их даст? kan>Ты хотя бы прикинь код на твоих любимых split-ах, который будет парсить поток строк <payment/>, что ты приводил, и, kan>скажем, вызывать checkCard/makePayment и записывать в выходной поток результат вроде kan>
kan><result clientid="2ni3poicy5b8924v"/>
kan><result clientid="vqxernty853ty32q" error="1244">Мятые купюры не принимаем</result>
kan>
kan>и сравни это с банальным SAX-фильтром.
Ну, возвращать-то он тоже будет пары key-value, то есть что-то типа response::key=value;;
Правда, оказалось, что я все же был неправ и тот gateway работает по-другому
Здравствуйте, kan, Вы писали:
kan>Если что-то типа подхода xslt (для условий используется xpath): kan>
kan><choose>
kan> <when test="something and (something_else or (first and second and third))">
kan> ...bla-bla-bla...
kan> </when>
kan> <when test="another or yet_another or or_yet_another">
kan> ...bla-bla-bla...
kan> </when>
kan> <otherwise>
kan> ...trundec...
kan> </otherwise>
kan></choose>
kan>
kan>Хотя в условиях и javascript можно использовать. Испольозование xml не запрещает использовать другие языки. Вон, в kan>html/svg javascript тоже активно юзается, никто не жалуется.
А теперь представь, что у тебя 200-ти строк такого кода, в которых ты ищещь баг. Распечатываешь, чтобы прошерстить исходники в спокойной обстановке с карандашом в руках. Тебе будет удобно среди <тегов> суть выискивать?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, ZevS, Вы писали:
TBG>>Хотелось бы послушать про преимущества ХыМыЛа для конечного пользователя продукта.
ZS>Пожалуйста: ZS>
ZS>Регулярный простой синтаксис.
Особенно для тети Тани. Несомненно. ZS>Возможность просматривать данные в любом виде
Теперь следует объяснить пользователю его эту возможность и он возрадуется. Быть может. ZS>Легкость контроля валидности
Ты, как пользователь HTML, часто его на валидность проверяешь? ZS>Относительная легкость интеграции и, возможно, перехода на новую версию продукта
Мне, как пользователю это совершенно фиолетово. ZS>Относительная легкость создания своих средств автоматизации и их простота
Опять же, предыдующий пункт. ZS>Относительная легкость анализа
Для дотошного пользователя, может быть. ZS>
ZS>Можно продолжить.
Не сомневаюсь. Минусы мы опустим. Опять же зависит все от того, кто твой пользователь и что он будет делать. Думаю, при описании шаблона отчета в xml не каждый из пользователей решится это сделать сам. Потому что:
Ну не хочется ему что-то изучать, если только сильно не придется, а если и придется, то лучше придумать какой-нибудь отмаз. Опять же, от ситуации зависит;
Все же ХыМыЛ не даст сделать все легко и удобно и придется что-то писать, но зачем? Лучше сказать, что язык описания непригоден и обосновать это;
Да и вообще, на то он и пользователь конечный, чтобы не знать что такое XML.
Даже конфигурационный файл оказывается проще что-то в стиле KEY=VALUE.
Я не за языки вместо ХМЛ — они тоже проблему не решат. Я за то, чтобы конечный пользователь владел все же мышой или чем-нибудь там и особо не напрягался, так как не любит.
Mamut wrote:
> kan>Побило как ребёнка. > Только при условии создания DOM-объекта
Ну да, что-то я не подумал, ведь MessageArray, KeyValueArray — в паралльельной вселенной создаются и места не занимают.
>> > У нас так же возможны ситуации, когда создание лишних объектов в памяти >> > дорого. > kan>Ну не создавай. Кто ж заставляет? > Тогда не получится легкости типа payment = message.getRootElement()
Используй SAX.
> kan>и сравни это с банальным SAX-фильтром. > Ну, возвращать-то он тоже будет пары key-value, то есть что-то типа > response::key=value;;
Пусть так. Легче не станет.
> Правда, оказалось, что я все же был неправ и тот gateway работает > по-другому <http://rsdn.ru/Forum/Message.aspx?mid=2137550&only=1>
Здравствуйте, Cyberax, Вы писали:
>> Вот теперь следующая идея ждет своего воплощения: встраивать >> Ruby-интерпритатор прямо в приложение, чтобы DSL им парсился и >> информация из DSL непосредственно в приложение поступала. C>А зачем?
Ну у меня в коде используется следующий подход: есть набор классов, объекты которых хранят конфигурационную информацию. Именно эти объекты используются в программе.
Есть так же процедуры, которые занимаются парсингом конфигурационных файлов и созданием вышеуказанных объектов. Как правило эти процедуры используют какую-либо библиотеку классов (для XML или моего формата). В случае использования моего формата, получается еще параллельная система классов-парсеров (в случае XML вместо них набор процедур, обрабатывающих DOM).
К этому еще добавляется набор Ruby-скриптов, которые из компактного DSL-я генерят пространные конфигурационные файлы.
Идея состоит в том, чтобы процедуры парсинга конфигов использовали сразу Ruby интерпритатор. А реализация DSL на Ruby могла формировать мои конфигурационные объекты в программе напрямую. Т.е., убрать промежуточные слои.
Но все это хорошо для случаев, когда приложение не должно сохранять конфигурацию обратно. Хотя, сейчас развитие проекта ParseTree обещает сделать возможным восстановление Ruby-кода.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
>> kan>Побило как ребёнка. >> Только при условии создания DOM-объекта kan>Ну да, что-то я не подумал, ведь MessageArray, KeyValueArray — в паралльельной вселенной создаются и места не занимают.
Нууу... Этааа...
Тут, правда, опять надо смотреть, что дешевле создать — объект или массив. Но это уже флуд на тему "а вот у нас в Forth под Берлином в сорок пятом..."
>>> > У нас так же возможны ситуации, когда создание лишних объектов в памяти >>> > дорого. >> kan>Ну не создавай. Кто ж заставляет? >> Тогда не получится легкости типа payment = message.getRootElement() kan>Используй SAX.
Не хочу Я просто callback функции не люблю Но тоже вариант
>> kan>и сравни это с банальным SAX-фильтром. >> Ну, возвращать-то он тоже будет пары key-value, то есть что-то типа >> response::key=value;; kan>Пусть так. Легче не станет.
>> Правда, оказалось, что я все же был неправ и тот gateway работает >> по-другому <http://rsdn.ru/Forum/Message.aspx?mid=2137550&only=1>
Здравствуйте, ZevS, Вы писали:
TBG>>Для дотошного пользователя, может быть. ZS>>>[/list] ZS>Извините, но это демагогия.
Да тут вся ветка демагогия, так что не обращайте внимания.
TBG>>Даже конфигурационный файл оказывается проще что-то в стиле KEY=VALUE. TBG>>Я не за языки вместо ХМЛ — они тоже проблему не решат. Я за то, чтобы конечный пользователь владел все же мышой или чем-нибудь там и особо не напрягался, так как не любит. ZS>Правда? А если конфигурация — это не пара значений, а сложная иерархическая структура?
Если, если... Вот если, тогда и KEYPARENT.KEYCHILD=VALUE тоже сойдет. Но это смотреть надо будет что проще. А вот для пары значений ХыМыЛ точно ни к чему? Или вы со мной не согласитесь?
eao197 wrote: > Ну у меня в коде используется следующий подход: есть набор классов, > объекты которых хранят конфигурационную информацию. Именно эти объекты > используются в программе.
В Java я для этого использую XMLBeans. По XSD-схеме создается дерево
классов, которые можно загружать и сохранять в XML.
Причем этот XML можно обрабатывать хоть чем, подписывать его и т.п.
Turtle.BAZON.Group wrote:
> ZS>Правда? А если конфигурация — это не пара значений, а сложная > иерархическая структура? > > Если, если... Вот если, тогда и KEYPARENT.KEYCHILD=VALUE тоже сойдет. Но > это смотреть надо будет что проще. А вот для пары значений ХыМыЛ точно > ни к чему? Или вы со мной не согласитесь?
Может быть, в каких-нибудь ситуациях... Но обычно в итоге получается сложнее, чем <br />
XML
Здравствуйте, Mamut, Вы писали:
M>>> Экономить всегда полезно. GZ>>Вообще-то нормальные девелоперы, для того чтобы уменьшить трафик включают gzip, который собственно именно для этого и предназначен. А через LZW алгоритмы, xml скукоживается на порядки.
M>Ну, любой текст скукоживается
"Все люди равны, но некоторые равнее." (с)
Просто архивация как раз эффективно решеает проблему избыточности xml — много повторений, которые хорошо запакуются.
Таким образом если некие развернутые xml и csv соотносятся размером как 2/1, то в сжатом виде они будут уже гораздо-гораздо ближе друг к другу.
M>>И я на самом деле вас ... кхм ... напарил Там инициируется POST запрос к серверу по HTTPS, в котором передаются пары Name/Value. То есть, Authorize.net получает уже готовый разбор значений на халяву.
ie>Довелось работать с 3мя платежками: Verisign, YourPay и Authorize.net. Так вот скажу, что Authorize.net как раз таки самая неудобная из этих 3-х.
А что в Verisign и Yourpay испольщуется? Таки ХМЛ?
Здравствуйте, kan, Вы писали:
kan>При использовании любого вменяемого xml-редактора — разницы никакой (теги сами закрываются, так что </if> писать не kan>придётся, обязательные аттрибуты сами печатаются, так что "test=" тоже набирать не придётся).
[offtop]
А не подскажешь пару-тройку таких вменяемых редакторов? Чем легче, тем лучше.
[/offtop]
kan>>При использовании любого вменяемого xml-редактора — разницы никакой (теги сами закрываются, так что </if> писать не kan>>придётся, обязательные аттрибуты сами печатаются, так что "test=" тоже набирать не придётся).
A>[offtop] A>А не подскажешь пару-тройку таких вменяемых редакторов? Чем легче, тем лучше. A>[/offtop]
A>С Уважением, Andir!
Здравствуйте, Mamut, Вы писали:
M>XML Spy Suite один из, если не наиболее вменяемый
Тяжёлый он больно, как и впрочем Stylus XML Studio.
Мне бы что-нить лёгкое с посветкой и поддержкой XSD ака валидация, автодополнение, автогенерация. Остальные навороты практически не нужны (хотя от некого подобия рефакторинга не отказался бы).
Здравствуйте, Andir, Вы писали:
A>Здравствуйте, c-smile, Вы писали:
CS>>(я использую т.н. JSON+ формат)
A>Это в нём получается отказались от кавычек для имён полей? Дай ссылочку на описание, пожалуйста?
Это обычная нотация полного JavaScript.
Абсолютно ничего не мешает доточить парсер чтобы он принимал не только string здесь:
Здравствуйте, Andir, Вы писали:
A>Здравствуйте, c-smile, Вы писали:
CS>>Это затмение на людей нашло. Не развивается это дело больше никак.
A>Смотрел уже Javascript 1.7 ?
(Интересно а куда делась версия 1.6?)
С JavaScript вообще ситуация странная. JavaScript v.2.0 имплементриован только в .NET.
И похоже больше никто на его имплементацию за пять лет не сподобился. Неуловимый Джо?
А 1.7...
Ну в общем синтаксический сахар от Ruby (yield, generators/continuations) давно напрашивался.
Но все эти фичи и сейчас доступны в JS. (В любом языке имеющем closures можно исполнить continuation "руками".)
Поэтому в общем-то сильно оно не зажигает (лично меня во всяком случае). Будут востребованы эти фичи народом — сделаю их в tiscript.
Добавлять же в ту паукообразную обезьяну (SpiderMonkey) еще чего либо вообще смысла нет. И так не блещет скоростью то.
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, eao197, Вы писали:
E>>Мнение Алана Голуба: Just Say No to XML
К>Замечание несколько очень в сторону, но вот ещё одна альтернатива — CurlyML, очень похожая на JSON, но тоже лишь язык разметки
Тоже вот несколько в сторону:
Это вот фрагмент разметки и ЯП curl ( www.curl.com )
Здравствуйте, c-smile, Вы писали:
CS>(Интересно а куда делась версия 1.6?)
Да там же, Javascript 1.6 — это реализовано в Firefox 1.5, и это там реализована поддержка E4X ака EcmaScript for XML о котором упомянули ранее.
CS>С JavaScript вообще ситуация странная. JavaScript v.2.0 имплементриован только в .NET. CS>И похоже больше никто на его имплементацию за пять лет не сподобился. Неуловимый Джо?
Вроде в репозитории мозиллы лежит какая-то реализация, но я никак не сподоблюсь глянуть на что она похожа
Здравствуйте, kan, Вы писали:
kan>Кстати, в Firefox 1.5 уже можно в Javascript (ECMAScript) <br />
<span class='lineQuote level1'>kan>включать</span>.
А еще это можно делать в следующем языке:
[code]
define function factorial($num as xs:integer) as xs:integer
{
if ($num = 1) return 1
else
return $num * factorial($num — 1)
}
return <factorial>{factorial(10)}</factorial>
[code]
не уверен полностью в синтаксисе, но примерно так. И угадай кто придумал и развивает этот язык?
Здравствуйте, kan, Вы писали:
>> Если, если... Вот если, тогда и KEYPARENT.KEYCHILD=VALUE тоже сойдет. Но >> это смотреть надо будет что проще. А вот для пары значений ХыМыЛ точно >> ни к чему? Или вы со мной не согласитесь? kan>Может быть, в каких-нибудь ситуациях... Но обычно в итоге получается сложнее, чем <br />
<span class='lineQuote level1'>kan>XML</span>
Здравствуйте, Andir, Вы писали:
A>Тяжёлый он больно, как и впрочем Stylus XML Studio. A>Мне бы что-нить лёгкое с посветкой и поддержкой XSD ака валидация, автодополнение, автогенерация. Остальные навороты практически не нужны (хотя от некого подобия рефакторинга не отказался бы).
Один из основных пунктов парадигмы: узкоспециализированный редактор. Притом DSL может вообще не быть plain-text (посмотри хотя-бы microsoft реализацию), главное чтобы его редактировать можно было удобно при помощи редактора.
Пользователю (прикладному программисту) глубоко наплевать в каком формате сохраняется его работа. Главное что бы было удобно и легко без редактора:
1) Хранить
2) Проводить тесты на валидность
3) Проводить batch-компиляцию
4) Была модульность системы
5) Смотреть историю модуля
6+) и в таком духе
Как видно все эти пункты просто решаются с использованием текстовых форматов. А какой формат выберет системный программист — дело вкуса и возможности "системного" языка хранить в нем объекты.
Т.ч. в данном случае XML не упускает своего шанса (C#, Java итд).
Здравствуйте, vvaizh, Вы писали:
V>Алану Голубу бы стоило помолчать
+1
V> переводить код в "удобочитаемый" и "краткий" язык стоит только V> тогда когда устоялась структура..
и тем самым "зацементировать" эту его структуру "навечно",
а потом лепить к ней заплатки и разные приблуды с умными
названиями с тем, чтобы добавить что-то новое.
Здравствуйте, vvaizh, Вы писали:
V>Алану Голубу бы стоило помолчать V>именно его поколение программистов не оставило после себя удобоваримого набора инструментов для написания компиляторов! V>xml по сравнению с каким нибудь yacc — это как манна небесная по сравнению с кактусом!
Особенно интересно смотреть на такие "сравнения" понимая что сравниваются совершенно разнородные сущности.
А какой инструмент для написания _компиляторов_ Вы хотели видеть вместо... мнэээ... yacc? И как он заменит, например, кодогенерацию?:)))
Здравствуйте, netch80, Вы писали:
V>>Алану Голубу бы стоило помолчать V>>именно его поколение программистов не оставило после себя удобоваримого набора инструментов для написания компиляторов! V>>xml по сравнению с каким нибудь yacc — это как манна небесная по сравнению с кактусом!
N>Особенно интересно смотреть на такие "сравнения" понимая что сравниваются совершенно разнородные сущности.
N>А какой инструмент для написания _компиляторов_ Вы хотели видеть вместо... мнэээ... yacc?
ну вообще то пользователи XML как то обходят это место..
большинство используют DOM-модель..
так и тут могли бы использовать доведённые до ума AST (abstract syntax tree)
речь ведь не об оптимальности кода.. а о краткости и наглядности синтаксиса..
Здравствуйте, vvaizh, Вы писали:
V>Здравствуйте, netch80, Вы писали:
V>>>Алану Голубу бы стоило помолчать V>>>именно его поколение программистов не оставило после себя удобоваримого набора инструментов для написания компиляторов! V>>>xml по сравнению с каким нибудь yacc — это как манна небесная по сравнению с кактусом! N>>Особенно интересно смотреть на такие "сравнения" понимая что сравниваются совершенно разнородные сущности. N>>А какой инструмент для написания _компиляторов_ Вы хотели видеть вместо... мнэээ... yacc? V>например pccts (http://www.cs.rhul.ac.uk/research/languages/links.html) V>избавлен от многих детских болезней yacc-а
И каким образом это объясняет Ваши тезисы? Да, pccts появился позднее. Но:
— не так страшен yacc, как его малюют:) GCC, например, сидит на yacc (в виде bison). Perl — на yacc. Видимо, он их удовлетворяет?
— чтобы понять, как делать лучше, надо было наработать опыт использования. Как этот опыт можно было получить без такого средства как yacc?
— и снова: при чём тут XML? Его средства заменят полноценный синтаксический разбор? Причём уровня как минимум pccts (иначе бы не нужно было это писать)? Просто потребовать баланса тегов разных уровней и соответствия заранее заданной иерархии — это даже не уровень yacc, это ниже. yacc хоть даёт возможность иногда пробиваться через нарушенный синтаксис.
N>>И как он заменит, например, кодогенерацию?:))) V>ну вообще то пользователи XML как то обходят это место.. V>большинство используют DOM-модель.. V>так и тут могли бы использовать доведённые до ума AST (abstract syntax tree) V>речь ведь не об оптимальности кода.. а о краткости и наглядности синтаксиса..
Я не думаю, что <expr><sum><item>1</item><item>2</item></sum></expr> нагляднее, чем 1+2. Попробуйте переубедить:)
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, vvaizh, Вы писали:
V>>>>Алану Голубу бы стоило помолчать V>>>>именно его поколение программистов не оставило после себя удобоваримого набора инструментов для написания компиляторов! V>>>>xml по сравнению с каким нибудь yacc — это как манна небесная по сравнению с кактусом! N>>>Особенно интересно смотреть на такие "сравнения" понимая что сравниваются совершенно разнородные сущности. N>>>А какой инструмент для написания _компиляторов_ Вы хотели видеть вместо... мнэээ... yacc? V>>например pccts (http://www.cs.rhul.ac.uk/research/languages/links.html) V>>избавлен от многих детских болезней yacc-а
N>И каким образом это объясняет Ваши тезисы? Да, pccts появился позднее. Но: N>- не так страшен yacc, как его малюют GCC, например, сидит на yacc (в виде bison). Perl — на yacc. Видимо, он их удовлетворяет?
не удовлетворяет
я говорю то что знаю
работал в разработке продукта, также на yacc..
знаю этот гемор изнутри и то что о нём думают разработчики
N>- чтобы понять, как делать лучше, надо было наработать опыт использования. Как этот опыт можно было получить без такого средства как yacc?
мне не интересно как этот опыт можно было получить
мне более интересно что ко времени массовой потребности хорошего механизма не появилось.
N>- и снова: при чём тут XML? Его средства заменят полноценный синтаксический разбор? Причём уровня как минимум pccts (иначе бы не нужно было это писать)? Просто потребовать баланса тегов разных уровней и соответствия заранее заданной иерархии — это даже не уровень yacc, это ниже. yacc хоть даёт возможность иногда пробиваться через нарушенный синтаксис.
средства XML позволяют гибко, просто и без геморроя менять язык
этого оказалось достаточно
N>>>И как он заменит, например, кодогенерацию? V>>ну вообще то пользователи XML как то обходят это место.. V>>большинство используют DOM-модель.. V>>так и тут могли бы использовать доведённые до ума AST (abstract syntax tree) V>>речь ведь не об оптимальности кода.. а о краткости и наглядности синтаксиса..
N>Я не думаю, что <expr><sum><item>1</item><item>2</item></sum></expr> нагляднее, чем 1+2. Попробуйте переубедить
видите ли, в большинстве критикуемых применений XML (nant, wix и т.п.)
такие выражения практически не используются, а там где используются используется обычный синтаксис, не XML
так что мимо кассы
с вашим примером вам нужно критиковать какой нибудь MathML да и то попробуйте в ваш синтаксис (1+2) ввести интегралы кванторы и прочую мат-обыденность и вам сразу поплохеет и захочется полноценного XML-я
Здравствуйте, vvaizh, Вы писали:
N>>И каким образом это объясняет Ваши тезисы? Да, pccts появился позднее. Но: N>>- не так страшен yacc, как его малюют:) GCC, например, сидит на yacc (в виде bison). Perl — на yacc. Видимо, он их удовлетворяет? V>не удовлетворяет V>я говорю то что знаю
Ага — значит, Вы знаете что думает народ пишущий GCC и Perl? Тогда почему они используют yacc?
V>работал в разработке продукта, также на yacc.. V>знаю этот гемор изнутри и то что о нём думают разработчики
Разработчики бывают разные. Думать они могут о разном. Например, о бабах:) Вы хотите сказать, что yacc прост и прямолинеен настолько, что примитивен? Я согласен. Что он "гемор"? Не вижу оснований. У него есть своя ниша — разбор конфигов и простых языков — и он её отлично закрывает. Причём в отличие от многих XML'евых парсеров (контекст не потеряли?) у него валидатор синтаксиса встроенный, а не стоящий где-то сбоку припёка отдельным средством.
Или в чём ещё проблема yacc?
N>>- чтобы понять, как делать лучше, надо было наработать опыт использования. Как этот опыт можно было получить без такого средства как yacc? V>мне не интересно как этот опыт можно было получить V>мне более интересно что ко времени массовой потребности хорошего механизма не появилось.
Ну так сформулируйте конкретно и детально (а то я тут из Вас каждое слово клещами тяну) что именно Вы вкладываете в понятие "хорошего" механизма, тогда можно будет рассмотреть, почему такого не было (уточняя: в публичном доступе).
N>>- и снова: при чём тут XML? Его средства заменят полноценный синтаксический разбор? Причём уровня как минимум pccts (иначе бы не нужно было это писать)? Просто потребовать баланса тегов разных уровней и соответствия заранее заданной иерархии — это даже не уровень yacc, это ниже. yacc хоть даёт возможность иногда пробиваться через нарушенный синтаксис. V>средства XML позволяют гибко, просто и без геморроя менять язык V>этого оказалось достаточно
Средство "последовательность байт" позволяют гибко, просто и без геморроя менять язык. При этом их возможности значительно шире чем у XML — можно применять и бинарные форматы, и другие варианты форматов с самотерминацией лексем (что резко упрощает парсеры), и при этом оно в разы экономнее XML. Давайте его использовать, зачем нам эти костыли?
N>>Я не думаю, что <expr><sum><item>1</item><item>2</item></sum></expr> нагляднее, чем 1+2. Попробуйте переубедить:) V>видите ли, в большинстве критикуемых применений XML (nant, wix и т.п.) V>такие выражения практически не используются, а там где используются используется обычный синтаксис, не XML V>так что мимо кассы
Не "мимо кассы", а Вы хотите и крестик оставить, и трусы снять:) Вы ж наехали на "поколение Голуба" за недостаток средств, а взамен в качестве альтернативы предложили XML. Их (того поколения) средства справляются с синтаксисом вида 1+2 беспроблемно и не требуется XML'ное обрамление. А у Вас будет двуслойность — и одни средства, и другие? И что это даст тем применениям, где обычно используется тот же yacc?
V>с вашим примером вам нужно критиковать какой нибудь MathML да и то попробуйте в ваш синтаксис (1+2) ввести интегралы кванторы и прочую мат-обыденность и вам сразу поплохеет и захочется полноценного XML-я
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, vvaizh, Вы писали:
N>>>И каким образом это объясняет Ваши тезисы? Да, pccts появился позднее. Но: N>>>- не так страшен yacc, как его малюют GCC, например, сидит на yacc (в виде bison). Perl — на yacc. Видимо, он их удовлетворяет? V>>не удовлетворяет V>>я говорю то что знаю
N>Ага — значит, Вы знаете что думает народ пишущий GCC и Perl? Тогда почему они используют yacc?
они думают "ну и угрёбище", но переписывать кучу существующего кода тяжело.. хотя и пытаются
тот же pccts — я не зря упомянул, именно он рассматривался как замена
V>>работал в разработке продукта, также на yacc.. V>>знаю этот гемор изнутри и то что о нём думают разработчики
N>Разработчики бывают разные.
это была мысль CTO и более того на работу по переходу на pccts было затрачено при мне не менее человеко/месяца
N>Думать они могут о разном. Например, о бабах Вы хотите сказать, что yacc прост и прямолинеен настолько, что примитивен? Я согласен. Что он "гемор"? Не вижу оснований. У него есть своя ниша — разбор конфигов и простых языков — и он её отлично закрывает. Причём в отличие от многих XML'евых парсеров (контекст не потеряли?) у него валидатор синтаксиса встроенный, а не стоящий где-то сбоку припёка отдельным средством.
в отличие от того же XML, ошибку в синтаксисе которого показывает банально любой броузер а новые языковые конструкции не вводят предыдущие версии в ступор (не нужен никакой препроцессор чтобы пропускать новые конструкции)
yacc не позволяет выдавать нормальные сообщения об ошибках
и на больших грамматиках добавлять чего то и отслеживать
непротиворечивость (а там постоянон растёт количество варнингов)
очень тяжело
N>Или в чём ещё проблема yacc?
отсутствие модульности, объектности, нормальных сообщений об ошибках, да куча всего, почитайте про pccts, там многое перечислено
N>>>- чтобы понять, как делать лучше, надо было наработать опыт использования. Как этот опыт можно было получить без такого средства как yacc? V>>мне не интересно как этот опыт можно было получить V>>мне более интересно что ко времени массовой потребности хорошего механизма не появилось.
N>Ну так сформулируйте конкретно и детально (а то я тут из Вас каждое слово клещами тяну) что именно Вы вкладываете в понятие "хорошего" механизма, тогда можно будет рассмотреть, почему такого не было (уточняя: в публичном доступе).
а зачем?
разработчики уже сделали свой выбор
обосновывать его не вижу смысла
таково сложившееся положение вещей
N>>>- и снова: при чём тут XML? Его средства заменят полноценный синтаксический разбор? Причём уровня как минимум pccts (иначе бы не нужно было это писать)? Просто потребовать баланса тегов разных уровней и соответствия заранее заданной иерархии — это даже не уровень yacc, это ниже. yacc хоть даёт возможность иногда пробиваться через нарушенный синтаксис. V>>средства XML позволяют гибко, просто и без геморроя менять язык V>>этого оказалось достаточно
N>Средство "последовательность байт" позволяют гибко, просто и без геморроя менять язык. При этом их возможности значительно шире чем у XML — можно применять и бинарные форматы, и другие варианты форматов с самотерминацией лексем (что резко упрощает парсеры), и при этом оно в разы экономнее XML. Давайте его использовать, зачем нам эти костыли?
угу..
вот только при этом изменении языка старые данные читаться не будут
N>>>Я не думаю, что <expr><sum><item>1</item><item>2</item></sum></expr> нагляднее, чем 1+2. Попробуйте переубедить V>>видите ли, в большинстве критикуемых применений XML (nant, wix и т.п.) V>>такие выражения практически не используются, а там где используются используется обычный синтаксис, не XML V>>так что мимо кассы
N>Не "мимо кассы", а Вы хотите и крестик оставить, и трусы снять Вы ж наехали на "поколение Голуба" за недостаток средств, а взамен в качестве альтернативы предложили XML. Их (того поколения) средства справляются с синтаксисом вида 1+2 беспроблемно и не требуется XML'ное обрамление. А у Вас будет двуслойность — и одни средства, и другие? И что это даст тем применениям, где обычно используется тот же yacc?
простите, но выражения 1+2 легко парсятся первокурсником в качестве лабораторной работы без всякого yacc
если вы ссчитаете результатом поколения голуба то что первокурсник делает за один-два дня, то мне не чего вам возразить
V>>с вашим примером вам нужно критиковать какой нибудь MathML да и то попробуйте в ваш синтаксис (1+2) ввести интегралы кванторы и прочую мат-обыденность и вам сразу поплохеет и захочется полноценного XML-я
N>Я там лучше TeX'овский стиль синтаксиса применю.
который никто кроме теха не поймёт
так что даже чтобы примитивный конвертор написать придётся попотеть
Здравствуйте, vvaizh, Вы писали:
N>>Ага — значит, Вы знаете что думает народ пишущий GCC и Perl? Тогда почему они используют yacc? V>они думают "ну и угрёбище", но переписывать кучу существующего кода тяжело.. хотя и пытаются
Интересный вывод:)
V>в отличие от того же XML, ошибку в синтаксисе которого показывает банально любой броузер а новые языковые конструкции не вводят предыдущие версии в ступор (не нужен никакой препроцессор чтобы пропускать новые конструкции)
Так называемый "синтаксис" XML, который способен показывать браузер, для других средств (не-XML'ных) аналогичен уровню деления битового потока на байты. И даже баланс тегов — это не синтаксис. Синтаксис — это то, что не может быть например быть while внутри выражения (expression). Это Вам покажет "любой браузер"? Это уже весьма высокий уровень полёта, и далеко не любой браузер способен на такое.
V>yacc не позволяет выдавать нормальные сообщения об ошибках
Нормальные чему?
V>и на больших грамматиках добавлять чего то и отслеживать V>непротиворечивость (а там постоянон растёт количество варнингов)
shift/reduce? Несерьёзно, они по жизни конфликтуют:)
V>очень тяжело
Очень конкретно:))
N>>Ну так сформулируйте конкретно и детально (а то я тут из Вас каждое слово клещами тяну) что именно Вы вкладываете в понятие "хорошего" механизма, тогда можно будет рассмотреть, почему такого не было (уточняя: в публичном доступе). V>а зачем? V>разработчики уже сделали свой выбор V>обосновывать его не вижу смысла V>таково сложившееся положение вещей
Другим объясните, чтобы по тем же граблям не ходить.
N>>Средство "последовательность байт" позволяют гибко, просто и без геморроя менять язык. При этом их возможности значительно шире чем у XML — можно применять и бинарные форматы, и другие варианты форматов с самотерминацией лексем (что резко упрощает парсеры), и при этом оно в разы экономнее XML. Давайте его использовать, зачем нам эти костыли? V>угу.. V>вот только при этом изменении языка старые данные читаться не будут
Ойвэй, так таки и не будут. Годами программисты нарабатывали методы, как читать не только "старые данные" но и старые форматы, как их различать и по явным указаниям, и эмпирически (если где-то не получилось пометить явно). А тут вдруг раз — и не будут.
А в случае XML Вы готовы принимать данные во всех старых форматах, какие были при развитии некоторой большой и сложной программы например до 20-й версии? Или только два последних формата, а проблемы остальных оставили индейцам?
N>>Не "мимо кассы", а Вы хотите и крестик оставить, и трусы снять:) Вы ж наехали на "поколение Голуба" за недостаток средств, а взамен в качестве альтернативы предложили XML. Их (того поколения) средства справляются с синтаксисом вида 1+2 беспроблемно и не требуется XML'ное обрамление. А у Вас будет двуслойность — и одни средства, и другие? И что это даст тем применениям, где обычно используется тот же yacc? V>простите, но выражения 1+2 легко парсятся первокурсником в качестве лабораторной работы без всякого yacc V>если вы ссчитаете результатом поколения голуба то что первокурсник делает за один-два дня, то мне не чего вам возразить
Это Ваши домыслы. Я бы на Вас посмотрел что бы Вы сделали на машине слабее PC XT и стоимостью как "Мерседес" и отдали бы при этом в open source (которое тогда только-только начиналось).
N>>Я там лучше TeX'овский стиль синтаксиса применю. V>который никто кроме теха не поймёт V>так что даже чтобы примитивный конвертор написать придётся попотеть
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, vvaizh, Вы писали:
N>>>Ага — значит, Вы знаете что думает народ пишущий GCC и Perl? Тогда почему они используют yacc? V>>они думают "ну и угрёбище", но переписывать кучу существующего кода тяжело.. хотя и пытаются N>Интересный вывод
какой есть
и главное из жизни очень успешной и известной компании
V>>в отличие от того же XML, ошибку в синтаксисе которого показывает банально любой броузер а новые языковые конструкции не вводят предыдущие версии в ступор (не нужен никакой препроцессор чтобы пропускать новые конструкции)
N>Так называемый "синтаксис" XML, который способен показывать браузер, для других средств (не-XML'ных) аналогичен уровню деления битового потока на байты. И даже баланс тегов — это не синтаксис. Синтаксис — это то, что не может быть например быть while внутри выражения (expression). Это Вам покажет "любой браузер"? Это уже весьма высокий уровень полёта, и далеко не любой браузер способен на такое.
да главное что парсеры не сломаются об такие ошибки
V>>yacc не позволяет выдавать нормальные сообщения об ошибках N>Нормальные чему?
нормальные не чему а что ошибки нормальные
которые указывали бы не только место где произошла ошибка но и конкретно что это за ошибка
большинство программ использующих yacc выдают сообщения типа
"нарушение синтаксиса в строке такой то, позиции такой то"
V>>и на больших грамматиках добавлять чего то и отслеживать V>>непротиворечивость (а там постоянон растёт количество варнингов) N>shift/reduce? Несерьёзно, они по жизни конфликтуют
серъёзно, нет нормальных средств борьбы с ними
V>>очень тяжело N>Очень конкретно
а я конкретники и не обещал, я обещал практический опыт
N>>>Ну так сформулируйте конкретно и детально (а то я тут из Вас каждое слово клещами тяну) что именно Вы вкладываете в понятие "хорошего" механизма, тогда можно будет рассмотреть, почему такого не было (уточняя: в публичном доступе). V>>а зачем? V>>разработчики уже сделали свой выбор V>>обосновывать его не вижу смысла V>>таково сложившееся положение вещей N>Другим объясните, чтобы по тем же граблям не ходить.
дык уже и не ходят, юзают XML где только можно
N>>>Средство "последовательность байт" позволяют гибко, просто и без геморроя менять язык. При этом их возможности значительно шире чем у XML — можно применять и бинарные форматы, и другие варианты форматов с самотерминацией лексем (что резко упрощает парсеры), и при этом оно в разы экономнее XML. Давайте его использовать, зачем нам эти костыли? V>>угу.. V>>вот только при этом изменении языка старые данные читаться не будут N>Ойвэй, так таки и не будут. Годами программисты нарабатывали методы, как читать не только "старые данные" но и старые форматы, как их различать и по явным указаниям, и эмпирически (если где-то не получилось пометить явно). А тут вдруг раз — и не будут.
угу.. годами.. и лучшее средство которое придемули — XML
где раскрученное средство весовой категории yacc/XML которое бы для yacc-а обеспечивало это?
N>А в случае XML Вы готовы принимать данные во всех старых форматах, какие были при развитии некоторой большой и сложной программы например до 20-й версии? Или только два последних формата, а проблемы остальных оставили индейцам?
в случае XML у меня есть путь который обеспечивает способ работы со старыми форматами без переписывания или усложнения парсера
N>>>Не "мимо кассы", а Вы хотите и крестик оставить, и трусы снять Вы ж наехали на "поколение Голуба" за недостаток средств, а взамен в качестве альтернативы предложили XML. Их (того поколения) средства справляются с синтаксисом вида 1+2 беспроблемно и не требуется XML'ное обрамление. А у Вас будет двуслойность — и одни средства, и другие? И что это даст тем применениям, где обычно используется тот же yacc? V>>простите, но выражения 1+2 легко парсятся первокурсником в качестве лабораторной работы без всякого yacc V>>если вы ссчитаете результатом поколения голуба то что первокурсник делает за один-два дня, то мне не чего вам возразить N>Это Ваши домыслы. Я бы на Вас посмотрел что бы Вы сделали на машине слабее PC XT и стоимостью как "Мерседес" и отдали бы при этом в open source (которое тогда только-только начиналось).
простите, но XML/HTML/SGML именно тогда и зародился
так что это не домыслы. это — жизнь
кстати эту лабораторную (парсер арифметических выражений со скобками и функциями)
я именно па XT-шках и писал..
Здравствуйте, vvaizh, Вы писали:
N>>Интересный вывод:) V>какой есть V>и главное из жизни очень успешной и известной компании
При этом сказано 0 целых фиг десятых про то, что этой компании было нужно и что она требовала.
N>>Так называемый "синтаксис" XML, который способен показывать браузер, для других средств (не-XML'ных) аналогичен уровню деления битового потока на байты. И даже баланс тегов — это не синтаксис. Синтаксис — это то, что не может быть например быть while внутри выражения (expression). Это Вам покажет "любой браузер"? Это уже весьма высокий уровень полёта, и далеко не любой браузер способен на такое. V>да главное что парсеры не сломаются об такие ошибки
А лучше бы сломались, раз это ошибки.
V>>>yacc не позволяет выдавать нормальные сообщения об ошибках N>>Нормальные чему? V>нормальные не чему а что ошибки нормальные
:) V>>>очень тяжело N>>Очень конкретно:)) V>а я конкретники и не обещал, я обещал практический опыт
Это не объяснение опыта разработки. Это объяснение уровня "мы тут вкурили и меня плющило". Опыт разработки должен быть выражен детально, иначе это не опыт.
N>>Другим объясните, чтобы по тем же граблям не ходить. V>дык уже и не ходят, юзают XML где только можно
Что-то я не вижу переписки синтаксиса Си на XML.:)))
N>>Ойвэй, так таки и не будут. Годами программисты нарабатывали методы, как читать не только "старые данные" но и старые форматы, как их различать и по явным указаниям, и эмпирически (если где-то не получилось пометить явно). А тут вдруг раз — и не будут. V>угу.. годами.. и лучшее средство которое придемули — XML V>где раскрученное средство весовой категории yacc/XML которое бы для yacc-а обеспечивало это?
Что именно обеспечивало бы? Определить в начале потока какой-то признак формата и дальше выполнить "условный switch"? ЛЮБОЕ средство такое может. Тот же yacc, только надо в грамматику это вставить.
N>>А в случае XML Вы готовы принимать данные во всех старых форматах, какие были при развитии некоторой большой и сложной программы например до 20-й версии? Или только два последних формата, а проблемы остальных оставили индейцам? V>в случае XML у меня есть путь который обеспечивает способ работы со старыми форматами без переписывания или усложнения парсера
А его нету без XML? М-да... Ваши заявления всё интереснее и интереснее.
V>>>простите, но выражения 1+2 легко парсятся первокурсником в качестве лабораторной работы без всякого yacc V>>>если вы ссчитаете результатом поколения голуба то что первокурсник делает за один-два дня, то мне не чего вам возразить N>>Это Ваши домыслы. Я бы на Вас посмотрел что бы Вы сделали на машине слабее PC XT и стоимостью как "Мерседес" и отдали бы при этом в open source (которое тогда только-только начиналось). V>простите, но XML/HTML/SGML именно тогда и зародился V>так что это не домыслы. это — жизнь
Когда это они зародились? В конце 70-х? М-да... смените траву:) В конце 70-х был roff. Кстати — отличный язык разметки, не хуже SGML. И не такой многословный.
Здравствуйте, netch80, Вы писали:
N>>>Интересный вывод V>>какой есть V>>и главное из жизни очень успешной и известной компании N>При этом сказано 0 целых фиг десятых про то, что этой компании было нужно и что она требовала.
сказано было больше другое дело что ничего из сказанного не было услышано, а вернее было прослушано, высокомерно заявлено что это не проблемы и стёрто из слуховой памяти
N>>>Так называемый "синтаксис" XML, который способен показывать браузер, для других средств (не-XML'ных) аналогичен уровню деления битового потока на байты. И даже баланс тегов — это не синтаксис. Синтаксис — это то, что не может быть например быть while внутри выражения (expression). Это Вам покажет "любой браузер"? Это уже весьма высокий уровень полёта, и далеко не любой браузер способен на такое. V>>да главное что парсеры не сломаются об такие ошибки N>А лучше бы сломались, раз это ошибки.
это не просто ошибки, это "такие" ошибки..
о которых ломаться не должно
V>>>>очень тяжело N>>>Очень конкретно V>>а я конкретники и не обещал, я обещал практический опыт N>Это не объяснение опыта разработки. Это объяснение уровня "мы тут вкурили и меня плющило". Опыт разработки должен быть выражен детально, иначе это не опыт.
опыт вообще не обязан выражаться или объясняться, он либо есть либо нет, как данность!
его можно либо игнорировать и учиться на своих ошибках либо САМОМУ слушателю пытаться вкурить для себя
N>>>Другим объясните, чтобы по тем же граблям не ходить. V>>дык уже и не ходят, юзают XML где только можно N>Что-то я не вижу переписки синтаксиса Си на XML.
что то я не вижу там больших изменений в синтаксисе за последние кавырнадцать лет для того чтобы его переводить на XML
кроме того C-подобные языки которые в качестве синтаксиса используют XML я уже видел
N>>>Ойвэй, так таки и не будут. Годами программисты нарабатывали методы, как читать не только "старые данные" но и старые форматы, как их различать и по явным указаниям, и эмпирически (если где-то не получилось пометить явно). А тут вдруг раз — и не будут. V>>угу.. годами.. и лучшее средство которое придемули — XML V>>где раскрученное средство весовой категории yacc/XML которое бы для yacc-а обеспечивало это? N>Что именно обеспечивало бы? Определить в начале потока какой-то признак формата и дальше выполнить "условный switch"? ЛЮБОЕ средство такое может. Тот же yacc, только надо в грамматику это вставить.
а зачем я должен поддерживать несколько веток для switch-а?
это bad smell вообще то!
а зачем я должен заставлять пользователя прописывать версию и следить за её актуальностью?
N>>>А в случае XML Вы готовы принимать данные во всех старых форматах, какие были при развитии некоторой большой и сложной программы например до 20-й версии? Или только два последних формата, а проблемы остальных оставили индейцам? V>>в случае XML у меня есть путь который обеспечивает способ работы со старыми форматами без переписывания или усложнения парсера N>А его нету без XML? М-да... Ваши заявления всё интереснее и интереснее.
его нету в виде промышленного решения и парадигмы
это не мои заявления повторяю, это опыт всей отрасли
а автор статьи (Голуб) вместе с вами маргинально пытается отрасли умозрительно чего то объяснить
даже не собираюсь вступать в дебаты
просто подумайте о том, что раз отрасль отказывается от классических синтаксисов на средствах типа yacc
то этому могут быть разные объяснения
не только что "вся отрасль — дураки"
но и "наверно классические средства для создания парсеров имеют какие то изъяны"
V>>>>простите, но выражения 1+2 легко парсятся первокурсником в качестве лабораторной работы без всякого yacc V>>>>если вы ссчитаете результатом поколения голуба то что первокурсник делает за один-два дня, то мне не чего вам возразить N>>>Это Ваши домыслы. Я бы на Вас посмотрел что бы Вы сделали на машине слабее PC XT и стоимостью как "Мерседес" и отдали бы при этом в open source (которое тогда только-только начиналось). V>>простите, но XML/HTML/SGML именно тогда и зародился V>>так что это не домыслы. это — жизнь
N>Когда это они зародились? В конце 70-х? М-да... смените траву В конце 70-х был roff. Кстати — отличный язык разметки, не хуже SGML. И не такой многословный.
Standard Generalized Markup Language (SGML) это некий метаязык, на котором можно определять язык разметки для документов. SGML — наследник разработанного в 1960 году в IBM языка GML (Generalized Markup Language)
и далее:
SGML это стандарт ISO «ISO 8879:1986 Information processing—Text and office systems—Standard Generalized Markup Language (SGML)»
итого зарождение — между 60м и 86м, как раз ваши 70-е
Здравствуйте, vvaizh, Вы писали:
N>>>>Интересный вывод:) V>>>какой есть V>>>и главное из жизни очень успешной и известной компании N>>При этом сказано 0 целых фиг десятых про то, что этой компании было нужно и что она требовала. V>сказано было больше другое дело что ничего из сказанного не было услышано, а вернее было прослушано, высокомерно заявлено что это не проблемы и стёрто из слуховой памяти
А, так это и было то что "успешная и известная компания" накопала? OK, принято.
V>>>да главное что парсеры не сломаются об такие ошибки N>>А лучше бы сломались, раз это ошибки. V>это не просто ошибки, это "такие" ошибки.. V>о которых ломаться не должно
Так это ошибки или нет?
V>>>а я конкретники и не обещал, я обещал практический опыт N>>Это не объяснение опыта разработки. Это объяснение уровня "мы тут вкурили и меня плющило". Опыт разработки должен быть выражен детально, иначе это не опыт. V>:) V>опыт вообще не обязан выражаться или объясняться, он либо есть либо нет, как данность! V>его можно либо игнорировать и учиться на своих ошибках либо САМОМУ слушателю пытаться вкурить для себя
Вот именно что "вкурить". Это уже дзэн какой-то получается, а не опыт.
N>>>>Другим объясните, чтобы по тем же граблям не ходить. V>>>дык уже и не ходят, юзают XML где только можно N>>Что-то я не вижу переписки синтаксиса Си на XML.:))) V>что то я не вижу там больших изменений в синтаксисе за последние кавырнадцать лет для того чтобы его переводить на XML
О.
N>>>>Ойвэй, так таки и не будут. Годами программисты нарабатывали методы, как читать не только "старые данные" но и старые форматы, как их различать и по явным указаниям, и эмпирически (если где-то не получилось пометить явно). А тут вдруг раз — и не будут. V>>>угу.. годами.. и лучшее средство которое придемули — XML V>>>где раскрученное средство весовой категории yacc/XML которое бы для yacc-а обеспечивало это? N>>Что именно обеспечивало бы? Определить в начале потока какой-то признак формата и дальше выполнить "условный switch"? ЛЮБОЕ средство такое может. Тот же yacc, только надо в грамматику это вставить. V>а зачем я должен поддерживать несколько веток для switch-а? V>это bad smell вообще то! V>а зачем я должен заставлять пользователя прописывать версию и следить за её актуальностью?
Пользователь как раз ничего не прописывает. Вы о чём?
N>>>>А в случае XML Вы готовы принимать данные во всех старых форматах, какие были при развитии некоторой большой и сложной программы например до 20-й версии? Или только два последних формата, а проблемы остальных оставили индейцам? V>>>в случае XML у меня есть путь который обеспечивает способ работы со старыми форматами без переписывания или усложнения парсера N>>А его нету без XML? М-да... Ваши заявления всё интереснее и интереснее. V>его нету в виде промышленного решения и парадигмы V>это не мои заявления повторяю, это опыт всей отрасли V>а автор статьи (Голуб) вместе с вами маргинально пытается отрасли умозрительно чего то объяснить V>даже не собираюсь вступать в дебаты V>просто подумайте о том, что раз отрасль отказывается от классических синтаксисов на средствах типа yacc V>то этому могут быть разные объяснения
Опять — я про то, зачем XML, а Вы — про yacc. Это и есть передовой опыт отрасли — перевод разговора на иное?
(Это я уж не вспоминаю в каких случаях вводился XML. А вводился он, как правило, вместо того, что в разы кривее,
и для описания данных, а не для программирования)
V>не только что "вся отрасль — дураки"
Этот вывод откуда? Это не мой вывод.
V>>>простите, но XML/HTML/SGML именно тогда и зародился V>>>так что это не домыслы. это — жизнь N>>Когда это они зародились? В конце 70-х? М-да... смените траву:) В конце 70-х был roff. Кстати — отличный язык разметки, не хуже SGML. И не такой многословный. V>я не знаю кто тут курит траву, но википедия показывает (http://ru.wikipedia.org/wiki/SGML): V>
V>Standard Generalized Markup Language (SGML) это некий метаязык, на котором можно определять язык разметки для документов. SGML — наследник разработанного в 1960 году в IBM языка GML (Generalized Markup Language)
V>и далее: V>
V>SGML это стандарт ISO «ISO 8879:1986 Information processing—Text and office systems—Standard Generalized Markup Language (SGML)»
V>итого зарождение — между 60м и 86м, как раз ваши 70-е
Здравствуйте, netch80, Вы писали:
V>>>>да главное что парсеры не сломаются об такие ошибки N>>>А лучше бы сломались, раз это ошибки. V>>это не просто ошибки, это "такие" ошибки.. V>>о которых ломаться не должно N>Так это ошибки или нет?
в традиционных парсерах — это ошибки времени парсинга
в xml — это в худшем случае семантические ошибки, а в лучшем программа даже не заметит ничего и отработает "как надо", пропустив непонятные опции/данные
N>Вот именно что "вкурить". Это уже дзэн какой-то получается, а не опыт.
называйте как хотите, я описываю реальность данную мне в ощущениях, какая бы она не была и как бы она не противоречила вашему мировоззрению
вы описываете — сон своего разума
N>>>>>Ойвэй, так таки и не будут. Годами программисты нарабатывали методы, как читать не только "старые данные" но и старые форматы, как их различать и по явным указаниям, и эмпирически (если где-то не получилось пометить явно). А тут вдруг раз — и не будут. V>>>>угу.. годами.. и лучшее средство которое придемули — XML V>>>>где раскрученное средство весовой категории yacc/XML которое бы для yacc-а обеспечивало это? N>>>Что именно обеспечивало бы? Определить в начале потока какой-то признак формата и дальше выполнить "условный switch"? ЛЮБОЕ средство такое может. Тот же yacc, только надо в грамматику это вставить. V>>а зачем я должен поддерживать несколько веток для switch-а? V>>это bad smell вообще то! V>>а зачем я должен заставлять пользователя прописывать версию и следить за её актуальностью? N>Пользователь как раз ничего не прописывает. Вы о чём?
разве? а как же "в начале потока какой-то признак формата"?
а ведь ещё хуже бывают варианты..
когда даже не в начале потока а почти в каждой строке приходится формат писать..
типа такого:
#ifdef MSVC
...
#endif
или такого:
CREATE /*!32302 TEMPORARY */ TABLE t (a INT);
N>Опять — я про то, зачем XML, а Вы — про yacc. Это и есть передовой опыт отрасли — перевод разговора на иное? N>(Это я уж не вспоминаю в каких случаях вводился XML. А вводился он, как правило, вместо того, что в разы кривее, N>и для описания данных, а не для программирования)
скажите а вы оригинальную статью Голуба читали? в начале топика?
он именно жалуется на то что XML используется не только для данных
N>Думаете, он 13 лет зарождался?
а вы думаете он приснился во сне как таблица Менделеева?
Здравствуйте, kan, Вы писали:
kan>eao197 wrote:
>> А какая альтернатива в XML будет, например, у: >> >> if something && ( something_else || ( first && second && third ) ) >> ...bla-bla-bla... >> elsif another || yet_another || or_yet_another >> ...bla-bla-bla... >> else >> ...trundec... >> end
kan>Если что-то типа подхода xslt (для условий используется xpath):
kan>
kan><choose>
kan> <when test="something and (something_else or (first and second and third))">
kan> ...bla-bla-bla...
kan> </when>
kan> <when test="another or yet_another or or_yet_another">
kan> ...bla-bla-bla...
kan> </when>
kan> <otherwise>
kan> ...trundec...
kan> </otherwise>
kan></choose>
kan>
kan>Хотя в условиях и javascript можно использовать. Испольозование xml не запрещает использовать другие языки. Вон, в kan>html/svg javascript тоже активно юзается, никто не жалуется.
Хм. А почему совершен переход в условиях на свой синтаксис? Потому что так удобней? Значит, ещё чуть-чуть добавить к нашему парсеру, и получится без лишнего синтаксического оверхеда.
А если мы не хотим писать свой парсер, то тогда придётся писать, при условии простой вложенности конструкций что-то вроде
_Winnie wrote:
> kan>Хотя в условиях и javascript можно использовать. Испольозование xml > не запрещает использовать другие языки. Вон, в > kan>html/svg javascript тоже активно юзается, никто не жалуется. > Хм. А почему совершен переход в условиях на свой синтаксис? Потому что > так удобней? Значит, ещё чуть-чуть добавить к нашему парсеру, и
Потому что требование удобства написания программ превышает сложность написания своего парсера.
> получится без лишнего синтаксического оверхеда. > А если мы не хотим писать свой парсер, то тогда придётся писать, при > условии простой вложенности конструкций что-то вроде
В каких-то условиях и такие вещи могут оказаться лучше.
Что-то ты некрофилией увлёкся.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, eao197, Вы писали:
E>Еще пару капелек масла в огонь священной войны против XML На этот раз в качестве информации к размышлению о производительности. Разработчики распределенной системы контроля версий Bazaar в новой версии 0.15 отказались от использования XML в качестве формата для хранения описаний в рабочей копии. За счет чего получили серьезный прирост производительности на некоторых операциях (по ссылке рассказывается об ускорении операции status на дереве исходников ядра Linux-а от 2.2 до 13.9 раз(!)). До этого разработчики Subversion так же отказались от использования XML в описателях рабочей копии (см. 1.4 release notes, раздел Working copy performance improvements).
E>Т.е. имеет смысл задумываться о выборе XML в качестве хранилища данных. Далеко не все ладно в Датском-то королевстве
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, eao197, Вы писали:
E>>Еще пару капелек масла в огонь священной войны против XML На этот раз в качестве информации к размышлению о производительности. Разработчики распределенной системы контроля версий Bazaar в новой версии 0.15 отказались от использования XML в качестве формата для хранения описаний в рабочей копии. За счет чего получили серьезный прирост производительности на некоторых операциях (по ссылке рассказывается об ускорении операции status на дереве исходников ядра Linux-а от 2.2 до 13.9 раз(!)). До этого разработчики Subversion так же отказались от использования XML в описателях рабочей копии (см. 1.4 release notes, раздел Working copy performance improvements).
E>>Т.е. имеет смысл задумываться о выборе XML в качестве хранилища данных. Далеко не все ладно в Датском-то королевстве
К>В свете этого я не совсем понимаю смысл XML DB
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, Курилка, Вы писали:
К>>В свете этого я не совсем понимаю смысл XML DB
L>А XML DB не использует XML в качестве формата для хранения.
Имхо — это только гиперболизация проблем xml.
Давайте вместо уровня абстракции введём ещё один уровень сложности.
Придумаем думателя.
Для шаблонных задач — это решение.
Для остальных — дополнительный геморрой.
Здравствуйте, eao197, Вы писали:
E>XML, вероятно, худший из когда-либо появлявшихся языков программирования. Я не говорю об XML как о языке описания данных, которым он был в своем первоначальном дизайне.
XML — это язык разметки (markup), то есть берется текст и его смысловые части размечаются:
Мама мыла раму, причем голубую
-->
<washing><who>Мама</who> мыла <what>раму</what>, причем голубую</washing>
Для описания данных предназначен, например, yaml (он так расшифровывается YAML Ain't Markup Language). Yf
washing:
who:Мама
what:Раму
Просто XML получил широкую поддержку и многие считают что проще использовать его, чем городить что-то свое или использовать что-то нераспространенное, хотя и заплатим некоторую цену читабельности.
_>я жалуюсь. при всей моей любви к этой игрушке трафик, при большОй стимости за оный, достаточно велик и точно проигрывает icq-шному.
Особенно на мобильнике J2ME+GPRS
Вот тут бы что-то типа EBML было бы сильно лучше.
Впрочем там и протокол надо пересматривать — например не грузить ростер целиком при запуске, а только изменения от последней загрузки.
GZ>Вообще-то нормальные девелоперы, для того чтобы уменьшить трафик включают gzip, который собственно именно для этого и предназначен. А через LZW алгоритмы, xml скукоживается на порядки.
jabber/gzip уменьшает трафик до 20-33%
При это zlib на J2ME работает не очень и память кушает дай боже — не каждый телефон справляется.
На вскидку, если из XMPP убрать повторения и избыточность и вместо XML сделать двоичный формат — сожмётся сильнее и при этом гораздо легче будет и для клиента-мобильника и для сервера, которому не придется для каждого соединения отдельный словарь LZW хранить
Здравствуйте, Andrei N.Sobchuck, Вы писали:
C>>XML — это язык конфигурирования и программирования данных. Я НЕ хочу C>>разбираться с кучей яызков для описания ДАННЫХ — я хочу один формат, ANS>А прийдётся разбираться Google открыл протокол обмена данными Protocol Buffers:
Собственно, я о нём аннонс в форум по C++ писал
Protobuf — это как раз ПРАВИЛЬНОЕ применение для кастомного языка. Так как он используется для не-human-readable данных, для которых критична скорость и занимаемый объём.
Там место для XML — это разве что описание самих протоколов. Но формат а-ля-idl для них уже просто стал стандартом.