Здравствуйте, eao197, Вы писали:
E>Здравствуйте, trophim, Вы писали:
T>>Заметьте, кто поставил минус на основной пост... А я что? Так, просто...
E>Видимо, я перевод некачественный сделал
Здравствуйте, 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++.
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 символа на значение, что при больших объемах влетает в копеечку
Ну и, во-вторых, парсер ХМЛ уже сложнее. Ненамного, а оно нам нужно?
Здравствуйте, ZevS, Вы писали:
ZS>Я как раз про то, что удобно должно быть конечному пользователю продукта. Кроме того надеюсь ни кто не будет спорить что XML имеет множество приемуществ.
Хотелось бы послушать про преимущества ХыМыЛа для конечного пользователя продукта.
Здравствуйте, eao197, Вы писали:
E>Так почему же XML используется таким неподходящим образом? Насколько я могу судить, это потому, что многие так называемые программисты просто не знают, как сделать компилятор...
Именно. Это вечный "наш" аргумент в борьбе с использованием XML направо и налево. Хорошо, что авторитеты начали озвучивать это же мнение.
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
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Turtle.BAZON.Group, Вы писали:
TBG>Здравствуйте, ZevS, Вы писали:
ZS>>Я как раз про то, что удобно должно быть конечному пользователю продукта. Кроме того надеюсь ни кто не будет спорить что XML имеет множество приемуществ.
TBG>Хотелось бы послушать про преимущества ХыМыЛа для конечного пользователя продукта.
Пожалуйста:
Регулярный простой синтаксис.
Возможность просматривать данные в любом виде
Легкость контроля валидности
Относительная легкость интеграции и, возможно, перехода на новую версию продукта
Относительная легкость создания своих средств автоматизации и их простота
Относительная легкость анализа
Можно продолжить.
К реальным минусам можно отнести:
Громоздкость + избыточность
Сложность описания очень сложных читай не деревянных данных
Кривость описания данных с устоявшимся синтаксисом (мат. формулы и т.п.)
При большом количестве элементов желательность спец. редакторов, но от этого не избавляют и свои языки
Здравствуйте, vdimas, Вы писали:
E>>Так почему же XML используется таким неподходящим образом? Насколько я могу судить, это потому, что многие так называемые программисты просто не знают, как сделать компилятор...
V>Именно. Это вечный "наш" аргумент в борьбе с использованием XML направо и налево. Хорошо, что авторитеты начали озвучивать это же мнение.
Угу, только знаешь какая аналогия напрашивается? Вот Вирт давно говорит, что язык программирования должен быть минималистическим и простым (показывая это на примерах своих творений). Только правят бал перегруженные монстры, вроде C++ или Java.
Вот так же и про XML авторитеты могут говорить и даже показывать личным примером, как от этого отказаться. Но командовать парадом будет засыпанный с головы до ног синтаксическим сахаром мейнстрим. Ведь дело дошло даже до того, что, например, в Scala XML может включаться непосредственно в текст программы.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
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 вполне эффективен.
Я не буду судить о корректности принятого там решения, посколько совершенно не в теме. На первый взгляд кажется, что 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 и т.п. Зачем? Если в нашем случае наш же собственный велосипед будет приспособлен именно для наших нужд и оптимизирован по самое нехочу?
Здравствуйте, eao197, Вы писали:
E>Вопрос в том, почему в данном случае не был использован какой-либо из стандартных протоколов?
Стандартных? А xml у нас нестандартный получается? А теперь найди хотя бы одно бесплатное разборщик для одного из твоих протоколов(ну кроме Visa-3D, который сам по себе XML). И чтобы там легко можно было получить данные(типа DOM+XPath+XQuery), и чтобы уследить за структурированностью данных(типа XSD). E>Если это какая-то наколенная система, и сами разработчики устанавливают в ней правила, то они вполне могли обойтись и без XML, чтобы не плодить лишних сложностей.
Сложности возникают только когда начинают делать свои велосипеды из-за нереальной мысли что будет лучше. Как нибудь попробуй прочитать спецификацию XML(даже без остальных технологий). Он только кажется простым. И там учтено много подводных камней.
Здравствуйте, 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, Вы писали:
M> Экономить всегда полезно.
Вообще-то нормальные девелоперы, для того чтобы уменьшить трафик включают gzip, который собственно именно для этого и предназначен. А через LZW алгоритмы, xml скукоживается на порядки.
Если клиентуры много и надо обрабатывать очень большое количество платежей, то тупой парсинг 
