С удивлением наблюдаю ажиотаж вокруг XML как "крутого" средства обмена данными. Мож я чего недопонимаю.... просветите.
Давным-давно появился на свет такой формат хранения данных .DBF и одним из его преимуществ было то, что смотреть, а иногда даже и править данные в нём можно было с помощью обыкновенного DOS редактора. Числа там, в частности, как и в XML, хранились в виде строки. Со временем стало очевидным сомнительность данного достоинства. И появились базы данных с нормальным, бинарным хранением информации. Например, Access. Конечно, просматривать, а уж тем более редактировать mdb – шник имеет смысл только с помощью специализированных библиотек DAO. Эту эволюцию я понимаю с информацией хранимой в бинарном виде, и работать проще и быстрее и хранить места меньше надо. А что с XML? Крайне не эффективный формат хранения, тем более передачи, информации! 60%(!) процентов мусора. Если, к примеру, сделать некоторую выборку из базы данных и сохранить её в бинарном формате то, та же информация, сохраненная в формате XML, будет занимать минимум в два раза больше места в среднем в 3.5 раза больше. Значит на её передачу уйдет больше времени. Да, перед передачей XML можно сжать, он очень хорошо сжимается (слишком много в нем ненужного). Но это означает что после передачи перед процессом парсирования, он должен быть разжат в памяти клиента (отожрать ресурс) в том объеме, в котором он был до сжатия. Я столкнулся с этой проблемой, когда занялся написанием клиент-серверного комплекса. Проблема в частности в том, что клиентская JAVA-программа должна быть в высшей степени жизнеспособной при минимально доступных ресурсах у пользователей. Пришлось разработать свой протокол обмена и хранения информации, что оказалось совсем не сложным делом. Бинарное представление + сжатие перед передачей и Всё просто летает! Так вот, если единственным плюсом XML осталась универсальность, унифицированность и межплатформенность так неужели нельзя было договориться о некотором бинарном формате обмена? Кто нибудь использует XML формат ответов в MS SQL? Вам это не очевидно?
Serge
14.07.03 21:06: Перенесено модератором из 'Базы данных' — M
Здравствуйте, vladserge, Вы писали:
V>Привет всем!
V>XML как "крутого" средства обмена данными. V>хранения данных .DBF
XML удобен когда у тебя существует один клиент и несколько источников(зачастую разработынных третьеми производителями), поставляющие данные в различных форматах...
Здравствуйте, vladserge, Вы писали:
V>Привет всем!
V>сжатие перед передачей и Всё просто летает! Так вот, если единственным плюсом XML осталась универсальность, унифицированность и межплатформенность так неужели нельзя было договориться о некотором бинарном формате обмена? Кто нибудь использует XML формат ответов в MS SQL? Вам это не очевидно?
Пользуем XML для передачи данных между платформами Win — Linux, по протоколу HTTP, в следствии чего поиспользовать бинарный формат не получается, но сжатие все равно используем, только немного для другого... gzip. Исходники есть и под Win и под Linux и в Mac — gzip — GNU Project.
А по поводу официального формата сжатия для XML.. года три назад, на конференции Microsoft, как раз посвященной XML, задавали этот вопрос представителям, но они только пожали плечами... мол дело хорошее но у них в планах этого нет.
Здравствуйте, Alexey Shirshov, Вы писали:
AS>Здравствуйте, vladserge, Вы писали:
V>>Привет всем!
V>>Бинарное представление + сжатие перед передачей и Всё просто летает!
AS>ну есть DIME.
Direct Internet Message Encapsulation (DIME)
нет это не то, под бинарным форматом я имел ввиду byte=1 byte, short=2 byte, int=4 byte, long=8 byte ......
V>>Так вот, если единственным плюсом XML осталась универсальность, унифицированность и межплатформенность ...
AS>не так уж и мало.
V>>...так неужели нельзя было договориться о некотором бинарном формате обмена?
AS>Попробуй, договорись.
V>>Кто нибудь использует XML формат ответов в MS SQL?
AS>Я.
локальная сеть? я знаю один проект который в реале по интернету использовал web service, SOAP это оффлайновый клиент чтения RSDN форумов.Народ задавался вопросом отчего такой гигантский трафик ..... а вот, технология такая
V>>XML как "крутого" средства обмена данными. V>>хранения данных .DBF
СС>XML удобен когда у тебя существует один клиент и несколько источников(зачастую разработынных третьеми производителями), поставляющие данные в различных форматах...
XML — на безптичьи ж.. соловей. Вот и не поняно почему нельзя было сделать и предложить нечто более продуманое.
Почему цифры нельзя было представлять в бинарном виде? Почему?
Ведь строковое 2 147 483 647 можно передать с помощью 4 byte вместо 10.
С уважением Сергей Чикирев
А про повторяющиеся по всему файлу теги( порой совершенно кигантской длинны) ....... молчу.
Здравствуйте, kly, Вы писали:
kly>Здравствуйте, vladserge, Вы писали:
V>>Привет всем!
kly>А теперь представь, что некто должен написать приладу к твоей клиент-серверной системе! Он начинает читать написанную тобой доку, смотреть примеры исходного кода, а тут еще оказалось, что твой комплекс работает в LittleEndian, а прилада — BigEndian. Он начинает вертеть у себя инты и т.д. Но все это естественно, мелочи, все обходится и прилада, таки начинает работать. Опять велосипеды, вникать в что-то чужое и т.д. Стандартным пользоваться удобнее! Парсеры, написаны, отлажены и т.д. А излишний объем — плата за унифицированность! Кроме того, XML — верхушка айзберга, над ним лежат такие чудные вещи, как xpath, xquery, xslt ! А схемы xml, для selfmade-протокола — selfmade validator, надоело. Беда в том, что многие люди начинают относиться к xml, как к панацее, а это в корне неверно, всякая технология имеет свои границы применимости. kly>Интерестно, а когда появился SQL, такие вопросы в конфах тоже плавали? И вообще этот вопрос — скорее в категорию "Общие вопросы >> О жизни "
Вот я и говорю порпробовав XML плюнул и начал изобретать велосипед, перед этим внимательно изучив чужие.
Заметил что многие системы эволюционируют так же как и наша. Сначала сделали на XML (потому что повелись на рекламу) и все было хорошо пока инф.система раскачивалась и наполнялась. Сотня записей на запрос загружалась быстро. В системе начала прибывать информация и тот самый запрос на который раньше возвращалось 100 записей стало загружаться 500 записей, 1000. И вот тут начались кранты ... Сжатие потока решило проблему передачи но проблему хилых клиентов с малой памятью не решило... ВСЁ пришлось переделать. Просто хочу предостеречь от своих ошибок. Вся проблемма оказалась в протоколе. Жаль что нет общепринятого бинарного формата обмена.
Тут народ уже привел несколько доводов в защиту XML.
Вот еще довод, когда XML нужен. Очень удобно XML-данные преобразовывать в разные форматы с помощью XSLT.
Была такая контора ВТрэйд, у них например, пользовательский интерфейс лежал в XML, а его представление для различных устройствах с разными форматами (телефоны разных типов, мобильные ПК, записные книжки, да и просто разные браузеры) генерилось с помощью специфичных для этих устройств XSLT-преобразований. Круто и таких примеров использования можно привести много.
Но я согласен, некоторые товарищи слишком уж зацикливаются на XML, типа модно и все тут, делаем все на XML.
XML-следует использовать тогда, когда это действительно нужно.
Здравствуйте, Vitaton, Вы писали:
V>Здравствуйте, vladserge, Вы писали:
V>Тут народ уже привел несколько доводов в защиту XML. V>Вот еще довод, когда XML нужен. Очень удобно XML-данные преобразовывать в разные форматы с помощью XSLT.
V>Была такая контора ВТрэйд, у них например, пользовательский интерфейс лежал в XML, а его представление для различных устройствах с разными форматами (телефоны разных типов, мобильные ПК, записные книжки, да и просто разные браузеры) генерилось с помощью специфичных для этих устройств XSLT-преобразований. Круто и таких примеров использования можно привести много.
не, хотя я больше акцентировал внимание на передачу данных даже для хранения и обработки XML НЕ ЭФФЕКТИВЕН
ну зачем ? для чего ? теги именно такие типа <tr /tr> <td /td> хотя можно было условится заменить их неким байт кодом иного обяснения кроме как возможность править HTML с помощью текстового редактора не вижу.
на заре HTML это было логично, но сейчас когда "космические корабли которые бороздили космическое пространство ... давно сданы в утиль" а практически 99.9999% информации в HTML формате либо генерится в автомате либо созданно человеком в специализированных редакторах. HTML — атавизм а XML — назад в будущее
V>Но я согласен, некоторые товарищи слишком уж зацикливаются на XML, типа модно и все тут, делаем все на XML. V>XML-следует использовать тогда, когда это действительно нужно.
Согласен много полезного уже сделано на основе XML но если бы этот формат был бы ещё и бинарным то ценность его возросла значительно
Здравствуйте, vladserge, Вы писали:
V>Здравствуйте, Сан Саныч, Вы писали:
V>>>XML как "крутого" средства обмена данными. V>>>хранения данных .DBF
СС>>XML удобен когда у тебя существует один клиент и несколько источников(зачастую разработынных третьеми производителями), поставляющие данные в различных форматах...
V>XML — на безптичьи ж.. соловей. Вот и не поняно почему нельзя было сделать и предложить нечто более продуманое. V>Почему цифры нельзя было представлять в бинарном виде? Почему?
V>Ведь строковое 2 147 483 647 можно передать с помощью 4 byte вместо 10.
V>С уважением Сергей Чикирев
V>А про повторяющиеся по всему файлу теги( порой совершенно кигантской длинны) ....... молчу.
Ты прав... но единого стандарта передачи бинарной информации нет и в ближайшие годы непредвидится...... писать для каждого нового источника данных провыйдер позволяющий преобразовать информации к понимаемой твоим клиентом форме?
И потом зачем обязательно гонять по сети XML... получай бинарную информацию и преобразуй ей в XML уже на стороне клиента...
Здравствуйте, vladserge, Вы писали:
V>Здравствуйте, Vitaton, Вы писали:
V>>Здравствуйте, vladserge, Вы писали:
V>>Тут народ уже привел несколько доводов в защиту XML. V>>Вот еще довод, когда XML нужен. Очень удобно XML-данные преобразовывать в разные форматы с помощью XSLT.
V>>Была такая контора ВТрэйд, у них например, пользовательский интерфейс лежал в XML, а его представление для различных устройствах с разными форматами (телефоны разных типов, мобильные ПК, записные книжки, да и просто разные браузеры) генерилось с помощью специфичных для этих устройств XSLT-преобразований. Круто и таких примеров использования можно привести много.
V>не, хотя я больше акцентировал внимание на передачу данных даже для хранения и обработки XML НЕ ЭФФЕКТИВЕН V>ну зачем ? для чего ? теги именно такие типа <tr /tr> <td /td> хотя можно было условится заменить их неким байт кодом иного обяснения кроме как возможность править HTML с помощью текстового редактора не вижу. V>на заре HTML это было логично, но сейчас когда "космические корабли которые бороздили космическое пространство ... давно сданы в утиль" а практически 99.9999% информации в HTML формате либо генерится в автомате либо созданно человеком в специализированных редакторах. HTML — атавизм а XML — назад в будущее
Понятие эффективности — очень расплвчатое, эффективность можно оценивать по разным критериям.
Вот еще пример. У Вас есть два бинарных файла с данными с разными спецификациями, и Вам нужно один преобразовать в другой программно. Или есть два XML файла с данными (с разными XML-схемами) с той же задачей преобразовать один в другой. Так вот во втором случае Вы спарвитесь с задачей преобразования файла из одного в другой в несколько раз быстрее просто набросав XSLT-преобразование.Т.е. конверторы разрабюатываюся значительно быстрее и проще и с меньшим количеством ошибок.
В Вашем случае, я конечно не знаю деталей, но я не уверен следовало ли вообще использовать XML, может было проще и быстрее ,skj разработаnь свой формат передачи данных, если не требовалось решать тех задач, которые позволяет решать XML.
V>>Но я согласен, некоторые товарищи слишком уж зацикливаются на XML, типа модно и все тут, делаем все на XML. V>>XML-следует использовать тогда, когда это действительно нужно.
V>Согласен много полезного уже сделано на основе XML но если бы этот формат был бы ещё и бинарным то ценность его возросла значительно
Так сложно договориться насчет бинарного стандарта и пока как-то не получается. А насчет XML уже кое-какие шига вперед сделаны.
Полностю согласен со всеми аргументами vladserge. Это совсем ненужный формат. Вернее унификация, которую он предлагает нужна, но решение этой задачи совсем кривое. Текст занимает огромные объемы и скорость его обработки крайне мала.
V>Так сложно договориться насчет бинарного стандарта и пока как-то не получается. А насчет XML уже кое-какие шига вперед сделаны.
Ну вот не понимаю иногда этих разработчиков. Разработать текстовой формат и договориться они кое как сумели, а потратить это время на разработку универсального бинарного формата и договориться о его использовании не смогли...
Но, возможно, здесь есть скрытые подводные камни. Если разрабатывать бинарный формат, то дело в конце концов наткнулось бы на чьи то интересы. Ведь уже много лет различные производители выдумывают свои форматы храниеия данных (Oracle, MS и др.) Они разработали эффективные бинарные структуры хранения данных и новый универсальный формат неизбежно в какой то мере должен был бы использовать часть этих идей. И кому то это бы не понравилось. Начались бы всякие судебные тяжбы и все такое...
Здравствуйте, vladserge, Вы писали:
V>Жаль что нет общепринятого бинарного формата обмена.
Почему же? Есть, например, ASN.1. Детально описывает структуру бинарных данных. Только вот парсеры для него все платные.
Здравствуйте, heathcliff, Вы писали:
H>Здравствуйте, vladserge, Вы писали:
V>>Жаль что нет общепринятого бинарного формата обмена. H>Почему же? Есть, например, ASN.1. Детально описывает структуру бинарных данных. Только вот парсеры для него все платные.
Дык я же не собираюсь их руками править. Для этого создаются спец. механизмы. Ты где то видел что бы в серьезных продуктах пользователь руками правил данные?
Здравствуйте, heathcliff, Вы писали:
H>Здравствуйте, Сан Саныч, Вы писали:
СС>>ASN.1 принципиально ничем не отличается от XML H>Хм... Что тогда принципиально отличается от XML?
V>>Жаль что нет общепринятого бинарного формата обмена. H>Почему же? Есть, например, ASN.1. Детально описывает структуру бинарных данных. Только вот парсеры для него все платные.
А вместо того что бы разрабатывать бесплатные парсеры для XML слабо было разработать бессплатные же парсеры для ASN?