Pull to refresh

Comments 28

Есть у кого-нибудь мысли почему использование этой возможности осталась в стороне среди разработчиков и архитекторов?
Наверное потому что бессмысленная вещь. Я не могу представить ситуацию, где Binary XML будет лучше чем просто XML или просто binary.
Ну что ж вы братцы так о нем плохо. А представьте себе ситуацию (из реальной жизни): нужно произвести импорт данных, к ним прикреплены фотографии… клиент не знает что такое FTP. Вы его будите учить читать спеки или сделаете для него импорт такой вот удобный? Мы в нашей студии пришли именно к этому решению )
base64?
Если слишком много места занимает, то можно сжать.
UFO just landed and posted this here
Честно говоря, мне бы никогда в голову не пришло использовать binXML для того чтобы прикреплять бинарные данные к текстовым. В случае с XML всегда хватало base64/CDATA. Да и научить клиент читать картинки по URL не намного сложнее чем научить читать их из binXML. Но если вы решили выбрать binXML и у вас все прекрасно работает — значит и ваше решение имеет право на существование :)
Я думаю его использование весьма специфично. Для общения клиент-сервер меня вполне устраивает «обычный» xml, а использовать binary XML в качестве хранилища данных какое-то извращение)

Хотя… если клиент, например флэшовый и флэш имеет какой-нибудь встроенный парсер, то возможно имеет смысл… Про флэш ничего не знаю, поэтому это просто мое предположение =)
У флеша есть встроенный бинарный формат AMF, так что и ему это мало чем пригодно. :)
Ещё лет 10 назад впервые столкнулся с binary XML в нефтяной отрасли. Ребята вполне серьёзно генерят и работают с XML'ками размером по несколько гигов, помещая туда данные для обсчёта сейсмики.
В нефтянке и не такие шедевры можно встретить. Контроллер телеметрии, тянущий данные в LPT-порта, куда комп периодически автоматом «печатает» отчет — одна из первых странностей, которую пришлось встретить. Понял что тут знают толк в извращениях, будет чему поучиться.
А вот я данном случае — почему не мобильная база какая-нибудь? Хотя если софт буржуйский — это будет преподноситься как чудаковатая традиция и еще лет через 10, потому как менять они почему-то подобные разработки не любят. В результате прибор уже пережил две революции, а вот софт так и остался в стиле win-3.1.
А вот вы бы написали о том, что это вообще такое, какие у него приемущества по сравнению с обычным xml, base64 и gzip.
думаю, 76% проголосовавших это могло бы быть интересно :)
Да, напишите! Что это такое? Как использовать? В каких случаях? Хотя бы на примере вашей фотографии опишите :)
Можно даже отдельной статьей, о!
Перевожу фильмы домашней коллекции в mkv (для танкистов — формат на базе binary XML). Мало того, что экономия получается, так и просто удобнее хранить многодорожечные, многосекционные фильмы со всякой метой унутре.
Так вот почему матрёшку так долго плееры открывают :)
И падают достаточно часто, если взять тот же LA. Каждый раз открываю свое любимое порево в mkv и вечно проблемы, не посмотришь нормально (
Нормальные плееры открывают и перематывают mkv гораздо быстрее, чем avi и т.п. Это происходит (о чудо) как раз потому, что mkv для этого и разрабатывался. И нечего тут пенять на bXML, от базового XML там остались только буквы в аббревиатуре.
There is no such thing as binary XML. Есть зоопарк более или менее малоизвестных стандартиков, самые известные из которых порядков на шесть менее распространены, чем XML. Вот если бы W3C или ещё кто-нибудь смог бы придумать стандарт и заставить остальных ему следовать, был бы разговор.
Сугубо ИМХО, но если binary, то уже не xml. Википедия говорит «Binary XML, or Binary Extensible Markup Language, refers to any specification which defines the compact representation of XML in a binary format», то есть бинарный хмл — это название ЛЮБОЙ спецификации, которая преобразует xml в бинарный вид. Так что, в принципе, tar cjf data.bxml data.xml вполне себе бинарный хмл.

Для меня же лично самый главный бенефит и признак хмл в том, что я могу открыть его хоть перочиным ножиком и глазами смотреть и руками изменять. Ну, это помимо классического и всеобъемлющего www.w3.org/TR/REC-xml/
UPD: елки-палки! вэ-три-це уже успели в августе перетереть тему бинарного хмл (http://www.w3.org/2003/08/binary-interchange-workshop/Report.html) и родить кое-что осязаемое (http://www.w3.org/XML/Binary/)!
В августе 2003-го, конечно же =)
Ну вообще если бы на разных концах клиент и сервер работали бы с xml _только_ по путям xml (т.е. для xml'ки вида путь xml.getNode(«a»).getNode(«b»).getParam(«p1»)), а передачей, составлением и разюором xml занималась бы какая-нибудь абстрагированная от этого библиотека, то в случае, если мы сообщили библиотеке формат конкретной xml (например, «в корне документа может быть только node „a“, в node „a“ может быть только node „b“, а он может иметь только параметр „p1“ и т.д.), то она в принципе могла бы передавать и принимать только значащую инфу. Если я правильно понимаю, это и есть binary xml.

И вот в этом случае у нас нет накладных расходов на преобразование текста xml в бинарные данные и обратно и на парсинг xml, + к этому „вес“ xml очень сильно меньше.

Такой вариант выглядит для меня _очень_ сладко. Я бы делал все новые протоколы для сложных проектов только с использованием такой штуки.

Никто не кинется ссылками на реализации подобного?

P.S.: прошу прощения за сумбурность, первый час всё-таки.
Хабр опять схавал теги.
> (т.е. для xml'ки вида
<a><b p1=«1»></a>
почитайте о XML Schema, DTD.
Сложно представить где бы *мне* эта штука могла бы пригодиться. Для передачи/хранения данных лучше google protobuffer ничего нет.
Очень интересно, спасибо. Напомнило часть разработки FlexT (более монументально) от Алексея Хмельнова (автор DCU32INT).
Sign up to leave a comment.

Articles

Change theme settings