JSON против XML и немного рефакторинга

[intr13]

А мобильные устройства (браузеры в мобильных устройствах) поддерживают сжатие трафика? Если да, то тогда возникает вопрос: сколько это съедает процессорного времени. А в мобильных устройствах железо не очень мощное:)

[golodnyj]

Собственно по этому от сжимания нам пришлось отказаться (
Точнее, этим менеджер проекта мотивировал зарезание такой фичи.
На сколько он был прав, сложно сказать…

[aps]

Авторы отталкиваются от проблем RIA приложений. Как будет выполняться на PDA «богатое» приложение, если PDA не может переварить большой поток данных gzip?

Впрочем, если взять какой-нибудь ExtJS и сравнить его размеры с данными, которые он крутит в среднестатистических реальных приложениях, то проблема мне кажется немного надуманной.

[dicos]

Вы собираетесь заставить пользователей читать вместо подготовленного документа данные в формате JSON? Мое мнение JSON и XML это формат обмена данными между программами (или модулями программы). Читаемость примерно везде одинакова, выбор формата передачи данных зависит только от предпочтений программиста и имеющихся готовых модулей.

[golodnyj]

Да при некотором понимании формата +) читаемость одинаковая, ну или сопоставимая.
Выбор зависит не только от мнения программиста (
к сожалению, или к счастью,
есть еще куча заинтересованных сторон,
которые накладывают свои ограничения.

Хотя я с вами согласен.
Готовность модулей, библиотек и опыт — главные факторы.

[aps]

>А еще, JSON куда более читабильнее и полезная информация воспринимается куда проще
При чем здесь читабельность???
GIF, JPG и PNG вообще нечитабельны. Но оченьудобны для передачи картинок. Хотя конечно можно передать их в виде json(xml) и отрисовать попиксельно.

[chiaroscuro]

XML это вообще-то EXtensible Markup Language. Язык разметки, а не «универсальный способ записи древовидных структур». Прозреваю заговор маркетологов и интырпрайз-программистов.

И почему бы не использовать S-выражения? Они проще для разбора компьютером и проще для чтения человеком, чем XML.

Ваш пример можно записать так:

(ru.golodnyj.lection.json.Client [(userName «name») (verified true) (userId 5)])

Главное — не запутаться в скобочках. ;)

[mt_]

Практически нечитаемо без спец. подготовки.

[chiaroscuro]

Strawman argument.

А вот это более читаемо? Без спец. подготовки (принятия поллитры :)).

name
true
5

А если перевести в одну строку, то вообще ужас будет.

[chiaroscuro]

Опа. Парсер съел. Но пример был на XML.

[maxp]

Целиком и полностью присоединяюсь к точке зрения, что использовать какую-нибудь технологию следует только понимая для чего она предназначена.

JSON интересная мысль, рекомендую послушать рассказ автора про то, как «я стал стандартом» :)
Ссылка была где-то на yahoo developers. И вообще, Даг очень импозантный и грамотный пипл.

Кстати, по поводу JSON'а в народу ходят мысли, что неплохо было бы его сделать в формате multiple documents in file, т.е. по сути вычитывать тривиальный список JSON объектов (одна строка — один документ), но с возможностью зкомментить (!) какой-либо из них.

Если не описаться сильно на Javascript, то в этой ситуации неплохо выглядит YAML, он даже покомпактнее будет.

Если говорить о бинарных сериализаторах, то можно взглянуть на Hessian.
А когда действительно нужна максимальная скорость, то видимо google protobuf тут вне конкуренции.

[maxp]

«Если не описаться» => «Если не опираться»

Старина Фрейд видимо уже переворачивается в гробу :)

[linux2000]

Сравнивать «JSON против XML» бессмысленно.

Попробуйте через JSON передать информацию с переносом строки… JSON предназначен только для обмена небольшими данными. Если данных много и они разного формата, безусловно XML лучше.

[linux2000]

Попробуйте передать через JSON например статью, где есть множество переносов строк.

[Timmmm]

У json'a нет аналога cdata тега в xml!

[AterCattus]

Но это не мешает передавать многострочные данные:
RFC4627, пункт 2 приводит примеры записи "%x..", которой можно передавать коды символов. А в 2.1 примеры строк в таком формате (для очень специфичных случаев): "%x66.61.6c.73.65".

Так что всё возможно.

[AterCattus]

Забыл сразу написать, извиняюсь. Еще же и unicode-вариант записи символов: \u005C к примеру.

[Timmmm]

ужас изврат какой О_о

[AterCattus]

Заменить один символ \n на его символьный код, имхо удобнее и проще, чем городить огород с <![CDATA[… ]]>.

Сейчас не идет речь про передачу исключительно бинарных данных.

[Timmmm]

нет CDATA же как раз нужна для передачи информации не предназначеной для парсинга. Например передать другой xml внутри. Мне как то нужно было передать сгенеренный HTML, к сожалению json'ом его непредать.

[AterCattus]

{
data: "ссылка"
}

в чём трудности?

[AterCattus]

эх, удалились теги… напишу так:

{
data: "[a href=\«google.com/\»]ссылка[/a]"
}

[Timmmm]

а проблема в том что «сгенеренный HTML» генерил не я. Трудности были в том чтоб передать строку вида:

{
data: "<а href=«google.com»>ссылка</а>"
}
боюсь соврать (достаточно давно это было), это строка ведь не является валидной с точки зрения json.

[AterCattus]

Является, если её передавать, как у меня с экранированием символов.

Пример:
"<name>O"Connor</name>"
Получиться должно:
"{«name»:«O\\"Connor»}"

[chiaroscuro]

Опять же в S-выражениях элементарно получается:

(my-doc (quote (another-doc (foo bar))))

Или для тех, кому в лом писать quote:

(my-doc '(another-doc (foo bar)))

[AterCattus]

Про LISP (а это он в принципе и есть) ничего плохого и не скажу, удобная в своей сфере вещь. Но сейчас же речь, как понимаю, о передаче многострочных текстовых данных.

[chiaroscuro]

Timmm назвал проблему: вложить документ в документ. В лиспе это делается просто, что я и показал.

Понятное дело, что парсить придется в любом случае: JSON/XML/S-exprs. Нагрузки тоже разные. Но тем не менее, S-exprs являются достойной альтернативой в ряде случаев.

[AterCattus]

В контексте вложенных документов, что JSON, что S-expr — в общем-то без разницы. И тот и другой варианты не имеют спец. конструкции для массового экранирования символов. В JSON это решается просто. В S-expr, как я понимаю Ваши посты, тоже. Холивар не будем разводить :)

[chiaroscuro]

Так вот именно же, что в случае S-выражение экранирование не нужно, потому что есть quote и backtick!

Вот такой вот холивар.

[Timmmm]

Несогласен. Я разрабатывал мини протокол обмена сообщениями. Ответ на запрос, xml данные. Если произошла ошибка отображаем ее особым образом. Или если ошибки не произошло отобразить результат запроса (сгенеренный html). По моему не очень на костыль похоже?

[stn]

Вы не видете костыля, потому что сама архитектура на нем стоит. Надо передавать или одни данные, или один html. А html в json это костыль.

[Timmmm]

А если на клиенте только получив ответ можно узнать результат запроса? Как вы отдельно передадите данные и html? В два запроса?

[Timmmm]

Т.е. у всего интернета проблемы? ;)

[inoise]

у каждого формата есть свои плюсы и как говорили выше — да здравствует компрессия! (которую, кстати, можно отключать для некоторых браузером через htaccess используя подмену файлов)

так же если вы затрудняетесь в выборе «это сюда, а то туда» — сделайте 2 адаптера JSON и XML и используйте где надо ;)

[ilich]

может кто знает, а Safari в яблофоне поддерживает сжатие?

[Kaluchi]

>XStream фреймворк

Зачем вы обозвали эту замечательную библиотеку таким плохим словом?

[zed_0xff]

а еще есть YAML, который еще более читаемый, чем json

[Angelina_Joulie]

Я соглашусь с вами, если вы предоставите стандартизированый способ превратить ваше:

json 96:
{«ru.golodnyj.lection.json.Client»: {
«userName»: «name»,
«verified»: true,
«userId»: 5
}}

скажем в:
{«ru.golodnyj.lection.json.Client»: {
«ClientName»: {«Isverified»: true, «userId»: 5}
}}

или скажем в:
ClientName
Name
…

И имея массив из Client находить всех валидных.
В отличии от JSON, XML это позволяет.

[AterCattus]

Не вижу ничего сложного.
1) eval и получили объект
2) использовали поля объекта как нужно ( к примеру var obj2 = { ClientName : { Isverified : obj->verified, ... } }; )
3) а по массиву бежим через for ( var obj in obj_list ) к примеру

[centur]

Забавно читать такой набор передергиваний.

И тут возникает первое сомнение: а вот если взять небольшое дерево, узлов на двести и сохранить в виде XML, так ли будет просто его прочитать. Человеку без специального редактора с подстветкой уже практически нереально читать такие файлы (особенно, если они записаны в одну строчку без переносов и табуляций). С этим утверждением сложно не согласиться.

Таким образом, следует откинуть человекочитаемость формата как преимущество и рассматривать XML прежде всего как средство коммуникаций между сервисими, программами или платформами, этакое платформонезависимое средство общения систем.

Т.е. 200 записей в JSON записаных в одну строчку читаются лучше?

или вот тут

Последний из камней сомнений, самый легкий и, в тоже время, фундаментально непоправимый, связан с объемом передаваемых данных, то есть объемом генерируемого трафика

Ого, фундаментально непоправимый — какое громкое утверждение, вы такой гуру что разбираетесь в фундаментальной поправимости… круто круто, жаль что первым же комментарием вам показали как очень легко поправить вашу фундаментальную непоправимость.

Слишком много пафоса.
И выводы тоже —

Можно сделать вывод, что сложность использования XML превышает сложность тех проблем, которые эта технология решает

Можно сделать и обратный вывод. Если смотреть с такой мелочной колокольни то да, действительно для вас слишком сложно использовать для решения мелких проблем. И конечно же вам XML непригоден

Жаль, что вы не упомянули ни одной проблемы которая действительно достойна — например сложное иерархическое дерево объектов, которое на вашем jsone перегрузит javascript движок своей вложенностью, а навигация по такой структуре с for в каждой вложенности — легко превысит ресурсоемкость Xpath выражения.
Ну а красота преобразования структуры на jsone в другую — вообще вызовет каталепсию у любого, кто попытается прочитать этот код. Более того я уверен что определенные сложные преобразования на яваскрипте вообще невозможно будет реализовать (по крайней мере в разумные сроки и вменяемыми алгоритмами)
А XSLT преобразования того же самого займут 10-15 строк, ну максимум 2 страницы чистого и легкочитабельного xslt

В общем учите инструменты и их предназначение, а не рассказывайте о найденных вами «фундаментальных недостатках» в технологиях, о которых вы имеете довольно-таки странное представление.

Все вышесказанное — ИМХО. Не буду писать «не хотел обидеть» потому что это неправда. Хотел показать как бессмысленна логика автора и какие удивительные выводы способен сделать человек в погоне за кармой.

[golodnyj]

О, если забавно читать такой набор передергиваний то цель свою статья достигла, легкое утреннее чтиво для тех кто умеет читать между строк. Что касается читаемости JSON, то я вроде нигде не говорил о легкости чтения этого формата +) При прочих равных, громкое утверждение является верным, а что касается комментария, вам следует читать ветку целиком.

Теперь перейдем к разбору содержательной части вашего комментария:
Достойная проблема с передачей сложного иерархического дерева в RIA (надеюсь, введение то вы прочитали), на мой взгляд, является проблемой дизайна. Другими словами, если вы знаете о том что поле заминировано — нефиг по нему голышом шастать.

Относительно преобразования JSON структуры в другую JSON структуру, хочу заметить: следует подумать, а с какой целью необходимо выполнение такого странного действа!? Данные, когда приходят на сторону их потребителя должны быть чистыми, вы же не едите вкусный шоколад с совершенно невкусной упаковкой и вам наверняка не прийдет в голову развернуть упаковку с целью переложить шоколад в другую упаковку.

Ваше ИМХО было услышано.

П.С. Что качается кармы:

— Я не понимаю, как вы, швейцарцы, можете сражаться за деньги. Вот мы, французы, сражаемся только ради чести и славы.
— Просто каждый воюет за то, чего ему не хватает.

Это к тому, что каждый судит по себе +)