Здравствуйте, Сан Саныч, Вы писали:
СС>Здравствуйте, vladserge, Вы писали:
V>>Здравствуйте, Сан Саныч, Вы писали:
V>>>>XML как "крутого" средства обмена данными. V>>>>хранения данных .DBF
СС>>>XML удобен когда у тебя существует один клиент и несколько источников(зачастую разработынных третьеми производителями), поставляющие данные в различных форматах...
V>>XML — на безптичьи ж.. соловей. Вот и не поняно почему нельзя было сделать и предложить нечто более продуманое. V>>Почему цифры нельзя было представлять в бинарном виде? Почему?
V>>Ведь строковое 2 147 483 647 можно передать с помощью 4 byte вместо 10.
V>>С уважением Сергей Чикирев
V>>А про повторяющиеся по всему файлу теги( порой совершенно кигантской длинны) ....... молчу.
СС>Ты прав... но единого стандарта передачи бинарной информации нет и в ближайшие годы непредвидится...... писать для каждого нового источника данных провыйдер позволяющий преобразовать информации к понимаемой твоим клиентом форме?
СС>И потом зачем обязательно гонять по сети XML... получай бинарную информацию и преобразуй ей в XML уже на стороне клиента...
.....а я про Ерёму. Ведь откуда взялась эта тема XML парсеров, их быстродействия именно из-за сложности разобрать XML данные быстро и сделать это эффективно ( в контексте затраченных рессурсов). А если проследить куда потом эти данные ложаться то чаще всего они преобразуются в бинарный вид и в этом виде хранятся в виде полей классов и значений в массиве. В БИНАРНОМ ВИДЕ ЗАМЕТЬТЕ
прикольная была бы програмуля у которой у классов все поля текстовые даже salary и age
[]
Oxy>Дык я же не собираюсь их руками править. Для этого создаются спец. механизмы. Ты где то видел что бы в серьезных продуктах пользователь руками правил данные?
При чем здесь руки?
Я тебе сказал о концепциях, которые заложены в XML. А в твою концепцию бинарного формата заложена лишь собственная неопытность и недальновидность.
XML — логическое развитие SQML, которому лет 15 минимум. Неужели ты думаешь, что за это время люди не могли придти к верному решению?
Если тебе нужна производительность — используй SOAP/DIME или Remoting с binary форматером.
V>.....а я про Ерёму. Ведь откуда взялась эта тема XML парсеров, их быстродействия именно из-за сложности разобрать XML данные быстро и сделать это эффективно ( в контексте затраченных рессурсов). А если проследить куда потом эти данные ложаться то чаще всего они преобразуются в бинарный вид и в этом виде хранятся в виде полей классов и значений в массиве. В БИНАРНОМ ВИДЕ ЗАМЕТЬТЕ
V>прикольная была бы програмуля у которой у классов все поля текстовые даже salary и age
Действительно прикольная программа получится... но тут мне видится проблема не в XML а в кривых руках рахработчиков.
Здравствуйте, Сан Саныч, Вы писали:
H>>Хм... Что тогда принципиально отличается от XML? СС>то что не является расширяемым языком разметки.
Как тогда договариваемся о формате бинарных данных?
Здравствуйте, Alexey Shirshov, Вы писали:
AS>Здравствуйте, Oxy, Вы писали:
AS>[]
Oxy>>Дык я же не собираюсь их руками править. Для этого создаются спец. механизмы. Ты где то видел что бы в серьезных продуктах пользователь руками правил данные?
AS>При чем здесь руки? AS>Я тебе сказал о концепциях, которые заложены в XML. А в твою концепцию бинарного формата заложена лишь собственная неопытность и недальновидность. AS>XML — логическое развитие SQML, которому лет 15 минимум. Неужели ты думаешь, что за это время люди не могли придти к верному решению?
AS>Если тебе нужна производительность — используй SOAP/DIME или Remoting с binary форматером.
....не понял простити в чём расширяемость? Если посмотрим на реляционные (и не только) базы данных то обнаружим в среднем десяток наиболее употребимых типов данных которые разве отличаются только названиями.
А ВОТ ВСЕ ПРИЛОЖЕНИЯ которые написаны с использованием этих базовых типов и есть расширения под конкретные цели. Что нетак ?
Здравствуйте, heathcliff, Вы писали:
H>Здравствуйте, vladserge, Вы писали:
V>>Жаль что нет общепринятого бинарного формата обмена. H>Почему же? Есть, например, ASN.1. Детально описывает структуру бинарных данных. Только вот парсеры для него все платные.
Оказывается это целая война миров !!!!
Очень рекомендую прочитать всем !!!!
Здравствуйте, vladserge, Вы писали:
V>А ВОТ ВСЕ ПРИЛОЖЕНИЯ которые написаны с использованием этих базовых типов и есть расширения под конкретные цели. Что нетак ?
Почему же тогда для обозначения полей в таблицах и самих таблиц используются названия, а не бинарные коды? Почему не сохранил своих позиций формат EDI?
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, vladserge, Вы писали:
V>>А ВОТ ВСЕ ПРИЛОЖЕНИЯ которые написаны с использованием этих базовых типов и есть расширения под конкретные цели. Что нетак ?
А>Почему же тогда для обозначения полей в таблицах и самих таблиц используются названия, а не бинарные коды? Почему не сохранил своих позиций формат EDI?
Всё большое спасибо ВСЕМ кто поучавствовал. Меня натыкали в стандарт ASN1
The military makes extensive use of binary formatted messages for efficient wireless communications and processing
by automated systems. These message standards are typically crafted to express field content and structure using
the fewest bits possible. Design approaches vary but normally the binary physical encoding of the structure and
fields are captured by rules unique to each specification.
........
Use of wireless XML poses problems due to the explosion in the number of
bytes required to represent the same data and the limits of radio spectrum availability. Additionally, processing of
XML is relatively more expensive in terms of CPU and memory which may be a limiting factor for embedded
processors.
The XML community generally regards loss of format efficiency as necessary to achieve the benefits they espouse.
List discussions on the topic divide into two camps, the XML purists who wish to defend attacks on the technology
and outsiders who are grappling with the disruptions that this technology engenders. Purist argue that XML can
be compressed if space/bandwidth is an issue while outsiders argue that alternate encodings are needed to provide
efficient data exchange and consumption by applications which are concerned only with the data content, not the
presentation.
This study investigates the costs of converting one binary message format into XML and the application of
several XML compression and encoding methods to reduce the resulting XML message sizes. Our goal is to run
concrete tests in order to produce comparative metrics for analysis and draw conclusions as warranted.
С Уважением Сергей Чикирев
PS Задумайтесь сегодня не то Ваше XML based application заставит вас задуматься завтра .... как раз в тот момент когда Вы к этому не расположены
Никакой разницы. Какая разница, если всё равно используется интерфейс для доступа к данным?
AS>Вся идея заключается в наглядности, самодокументируемости и расширяемости.
"Самодокументируемость" — очень вредное слово. Не бывает таковой, в принципе.
AS>Как ты себе представляешь бинарный расширяемый формат?
Точно так же, как текстовый расширяемый. Абсолютно.
----------
Если говорить вообще, то в IT любой текст — маздай кроме специальных тексто-ориентированных приложений.
Не удивляет же, что GetLastError() отдаёт число, и уже потом по нему можно получить локализованное описание ошибки?
Кстати.. Вот и <name>Alexey Shirshov</name> совсем не то же, что <имя>Alexey Shirshov</имя>, верно? Если уж говорим про "самодокументируемость"???
Здравствуйте, vladserge, Вы писали:
V>С удивлением наблюдаю ажиотаж вокруг XML как "крутого" средства обмена данными. Мож я чего недопонимаю.... просветите.
[skip]
Здравствуйте, vladserge, Вы писали:
V>Привет всем!
V>С удивлением наблюдаю ажиотаж вокруг XML как "крутого" средства обмена данными. Мож я чего недопонимаю.... просветите.
Что-то я не понял, что за проблемы у тебя? Мне вот, например, для решения моих задач совсем не подходит ассемблер — это ведь не значит что я должен на всех углах кричать, что ассемблер это хрень не нужная и не оптимальная ?
Если кто-то использует XML, значит XML подходит для решения его задач...
Конкретно к твоей проблеме на сколько я понимаю ты не был знаком с предметной областью( или вернее сказать с задачами такого рода), поэтому не знал что тебе использовать хорошо, а что плохо, поэтому не правильно выбрал вначале XML. Вот и все дела. Глупо из-за одного "прокола" отказываться от XML ообще...
Всякое оружие хорошо для своих целей. Почему-то в армии до сих пор выдают штык-ножи, несмотря на танковые клинья и тактическое ядерное оружие. Обвинять XML в том, что он плохо подходит для передачи больших объемов реляционных данных — глупо. Он просто не для этого разработан. Я лично считаю, что по сравнению с .ini конфигами XML конфиги рулят однозначно. А бинарные форматы фиксированной структуры плохи для сериализации сильно разветвленных древовидных данных. В общем, по задаче и инструмент.
... << RSDN@Home 1.1 alpha 1 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vladserge, Вы писали:
V>PS Задумайтесь сегодня не то Ваше XML based application заставит вас задуматься завтра .... как раз в тот момент когда Вы к этому не расположены
Ты слышал про такую вещь как Web Services? Эту технологию развивают очень серьезные компании и только из-за
нее XML не умрет (как и Floppy 10 лет душат), а ведь это всего 1 пример
К тому же пропускные способности каналов постоянно растут, да, ты же не играешь в UGH! когда у тебя Р4 только
из-за того что он бегает быстрее чем Doom3
Здравствуйте, Dmitry123, Вы писали:
D>Здравствуйте, vladserge, Вы писали:
V>>PS Задумайтесь сегодня не то Ваше XML based application заставит вас задуматься завтра .... как раз в тот момент когда Вы к этому не расположены
D>Ты слышал про такую вещь как Web Services? Эту технологию развивают очень серьезные компании и только из-за D>нее XML не умрет (как и Floppy 10 лет душат), а ведь это всего 1 пример
Логика, СУПЕР !!! А ещё, в догонку, мильён мух не могут ошибаться .....
D>К тому же пропускные способности каналов постоянно растут, да, ты же не играешь в UGH! когда у тебя Р4 только D>из-за того что он бегает быстрее чем Doom3 ;
Всё правильно, просто мне показалось что здесь достаточно много людей которые стремятся выпускать конкурентноспособные продукты.
А рессурсы, ЛЮБЫЕ (!!!!) как и денеги НИГОГДА не бывают лишними.
Здравствуйте, vladserge, Вы писали:
V>Логика, СУПЕР !!! А ещё, в догонку, мильён мух не могут ошибаться .....
Ну это ты все-таки зря
Решил MS продвигать .NET и никуда он не денется, многие кричат что он плохой,
но если понадобится то будут учить, ничего не поделаешь.
Это я к тому, что не важно сколько корпораций стоит за XML, важно какие,
и им невыгодно его пока менять
V>Всё правильно, просто мне показалось что здесь достаточно много людей которые стремятся выпускать конкурентноспособные продукты. V>А рессурсы, ЛЮБЫЕ (!!!!) как и денеги НИГОГДА не бывают лишними.
Здравствуйте, vladserge, Вы писали: V>Читайте subj месье.
А почему вы думаете, что запрос к MS SQL должен возвращать непременно тысячи строк? Каноническое клиент-серверное приложение никогда так не делает. Возвращается сравнительно небольшой набор данных, при которых накладные расходы при передаче по TDS могут быть сравнимы с потерями в XML. Зато последний имеет преимущество в том, что его можно напрямую скормить XSL-трансформатору для выкидывания в веб-страницу.
Естественно, попытки использовать его для select * from EarthPopulation неразумны.
... << RSDN@Home 1.1 alpha 1 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vladserge, Вы писали:
V>Здравствуйте, Аноним, Вы писали:
А>>Здравствуйте, vladserge, Вы писали:
V>>>А ВОТ ВСЕ ПРИЛОЖЕНИЯ которые написаны с использованием этих базовых типов и есть расширения под конкретные цели. Что нетак ?
А>>Почему же тогда для обозначения полей в таблицах и самих таблиц используются названия, а не бинарные коды? Почему не сохранил своих позиций формат EDI?
V>Всё большое спасибо ВСЕМ кто поучавствовал. Меня натыкали в стандарт ASN1
V>Настоятельно рекомендую прочитать http://asn1.elibel.tm.fr/en/biblio/cokus-xml-sizing.pdf
Этому стандарту очень много лет, гораздо меньше чем XML. Не настораживает почему он распрастранился гораздо меньше?
Если смотреть реально, то такие вещи как "читабельность" и "простота" играют важную роль.
Агрумент: есть специализтрованные средства — срабатывает далеко не всегда (хотя и часто ).
В свое время я расматривал возможность сделать собственный парсер для ASN.1 (как часть дипломной работы ).
После небольших размышлений, пришел к выводу: если начну его делать — не видать мне диплома. (все делалось по-русски: на грани deadline)
Хотел бы еще добавить, что насколько я помню, ASN.1 обязательно требует описание данных, иначе парсеры не смогут его обработать.
XML здесь более гибок. Нужна схема — делай, не нужна — не делай.
Второй момент — расширяемость. Создается очущение, что каждый понимает этот термин по своему, может это и правильно.
А понимаю его так: я могу добавить в XML файл нужный мне атрибут или элемент (в любое место), а старые программы попрежнему будут с ним работать без проблем.
В случае бинарных форматов пришлось бы обновлять схему данных и вероятность, что старые программы попрежнему будут работать на этих данных посему уменьшается.
Действительно прикольная программа получится... но тут мне видится проблема не в XML а в кривых руках рахработчиков. 
Мы уже победили, просто это еще не так заметно...
? 
