Здравствуйте, koodeer, Вы писали:

K>Во всех этих разговорах о, якобы, простоте и читабельности текстовых форматов, наподобие xml и json, всегда забывают об одной важной теме: данные должны быть отделены от представления! Это, по сути, аксиома современного проектирования.
K>XML:
Не, раз мы боремся за синтаксический оверхед, то сравнивать надо с

<persons>
  <person name='Vasya' age='20'/>
  <person name='Kolya' age='20'/>
</persons>

Смотрим на json выше, что-то оно нифига не читабельней


K>То есть читабельность для человека должен обеспечивать софт, а не сам формат данных!
Кэп: именно эта логика закопала эдак с дюжину форматов. Для самых актуальных сценариев бинарные форматы сливают практически во всём, от стоимости поддержки и до расширяемости. Про мелочи типа сравнения файлов, обработку в веб-фронтэнде и эффективность сжатия потока в "экономном" бинарном формате я и говорить не буду.

K>Я уже давно пришёл к выводу, что данные должны храниться в компактном (чтобы занимать мало место и быстро читаться/записываться/пересылаться по сети) и удобном для парсинга (чтобы быстро читаться/записываться/индексироваться в случае необходимости) формате.
Великолепная идея. Осталось придумать способ запихнуть в этот формат поддержку произвольных кодировок, схем данных, версионность ("старый" формат должен гарантированно читаться и спустя n лет), комментарии, универсальный формат дат и больших чисел и ещё с десяток нюансов. Ну и обосновать, чем получившийся монстр будет лучше старого-доброго xml. В общем как только — так сразу приходите

K>Многие скажут, что невозможность воспользоваться обычным текстовым редактором типа Notepad ставит крест на идее двоичного формата. Но, положа руку на сердце, часто вы им пользуетесь?

Я пользуюсь тем, что есть под рукой — от vi на удаленном сервере до IntelliJ IDEA. И да. Был случай, когда пришлось глазами просматривать примерно 3-мегабайтный XML-файл vim'ом.

K>Или всё же предпочтёте что-то получше, хотя бы типа Notepad++. Во многих базах данных есть тип данных xml — понятно, что хранится он в распарсенном виде, то есть в нечитаемом для человека. Является ли это препятствием для его использования? Полезете ли вы текстовым редактором в файл(ы) БД?

XML-редактором тоже в базу не лезут. Что ты хочешь сказать-то?

K>Итог: нужен единый стандартизированный компактный двоичный формат и специализированный редактор для работы с ним на каждой платформе.
K>(Тут картинка xkcd про стандарты).

1. Именно.
2. ASN.1, например, есть. Но им пользуется полтора человека.

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, RonWilson, Вы писали:

RW>>может, им тупо неохота развивать богомерзкий msxml.dll (как-то читал в msdn про одну из нужных мне фич, что де используйте System.Xml или как его из .net, а msxml — идет в задницу).
S>Неа, и сборка и старых и новых проектов — managed-код.

старых понятно, но про новые не понял)

Здравствуйте, α, Вы писали:

α>Здравствуйте, RonWilson, Вы писали:

RW>>может, им тупо неохота развивать богомерзкий msxml.dll (как-то читал в msdn про одну из нужных мне фич, что де используйте System.Xml или как его из .net, а msxml — идет в задницу).

α>Там кроме производительности развивать было нечего, да и по производительности он в сравнении с конкурентами весьма крепкий середнячок. Кроме отсутствия XSLT 2.0 в MSXML 6.0 всё идеально

ну тут наверное да, если бы не COM.. а так даже и сравнивать не с чем, особенно после убойных багов, которые до сих пор в tinyxml и поделии tinyxpath, что вообще эпичное творение

Здравствуйте, RonWilson, Вы писали:

S>>Неа, и сборка и старых и новых проектов — managed-код.
RW>старых понятно, но про новые не понял)

Ну откуда в портируемых dnx projects системе проектов возьмётся завязка на unmanaged код?
Не забываем, что одна из возможностей dnx host — горячая компиляция, с поддержкой обновления исходников в рантайме.

Здравствуйте, RonWilson, Вы писали:


RW>ну тут наверное да, если бы не COM..

А что не так с COM? Мне он никогда не мешал, наоборот...

Здравствуйте, aloch, Вы писали:

A>Здравствуйте, RonWilson, Вы писали:


RW>>ну тут наверное да, если бы не COM..

A>А что не так с COM? Мне он никогда не мешал, наоборот...

да тут без предрассудков, в целом, просто зачем это делать было в рамках COM, если только бы одно не вспомнилось, что даже excel использует его же объекты для stylesheets призагрузке xml, к примеру.

S>Да чего там их реализовывать? Вот например libraryes[/b]/config/model]моя

Этапяць!

Здравствуйте, Sheridan, Вы писали:

S>Здравствуйте, flаt, Вы писали:

F>>Ещё у xml есть XPath, к json тоже можно подобное прикрутить (даже готовые реализации есть).
S>Да чего там их реализовывать? Вот например моя
S>Использую кактотак
S>

S>config->folder("network")->folder("listen")->file("port")->get(252 /*default*/);
S>

и как в это запихать условную выборку, или месье любит аля select * from tbl where id=252?

Здравствуйте, RonWilson, Вы писали:

S>>

S>>config->folder("network")->folder("listen")->file("port")->get(252 /*default*/);
S>>

RW>и как в это запихать условную выборку, или месье любит аля select * from tbl where id=252?
В смысле подставить в sql запрос данные из конфига? Как всегда, забиндить. Конретный вариант зависит от движка, но в общем случае кактотак:

 db->query("select * from tbl where id=?", config->folder("network")->folder("listen")->file("port")->get(252 /*default*/));

Здравствуйте, dr. Acula, Вы писали:


S>>Да чего там их реализовывать? Вот например libraryes[/b]/config/model]моя
DA>Этапяць!
Да только в печку не запихивай

Здравствуйте, koodeer, Вы писали:

K>Во всех этих разговорах о, якобы, простоте и читабельности текстовых форматов, наподобие xml и json, всегда забывают об одной важной теме: данные должны быть отделены от представления! Это, по сути, аксиома современного проектирования.

Я не понял почему вы форматирование называете представлением. Особенно в контексте проектирования.

Здравствуйте, Kernan, Вы писали:

K>Здравствуйте, Michael7, Вы писали:

M>>А я думал, что SGML, чьим подмножеством он является (являлся поначалу), да и html тоже. Который появился раньше. Еще ASN.1 можно вспомнить.
K>В отличии от ваших джейсонов и хмл-ей, ASN.1 спокойно живёт и ещё переживёт всех.

Мне эта жизнь ASN.1 сильно напоминает нынешнюю ситуацию с хвойными и как Еськов писал про неё:

Покрытосеменные возникли в начале мелового периода, первоначально как ценофобы — растения, не входящие в закономерные, сложившиеся в длительной коэволюции сукцессионные ряды. Они росли в качестве "сорной" растительности по свободным от других растений участкам (на речных отмелях, береговых оползнях, гарях), которые соседствовали с гораздо более обширными участками, занятыми зрелыми сообществами мезофитной растительности. Основой стремительной среднемеловой экспансии цветковых стало то, что им удалось закрепиться в качестве нормальной пионерной растительности — для чего решающими факторами стали их исходная энтомофильность и наличие среди них травянистых форм (что во много раз убыстряет зарастание поврежденных участков). Покрытосеменные не пытались потеснить всю мезофитную растительность, что было абсолютно нереально; они "всего-навсего" конкурентно вытеснили прежних пионеров — и тем самым блокировали все последующие стадии мезофитной экогенетической сукцессии. Разрушение существовавших в то время закономерных сукцессионных рядов (попросту говоря — мезофитная растительность продолжала существовать там, где она существует, но потеряла способность восстанавливаться после экзогенных нарушений), вызвало полный развал мезозойских наземных экосистем и массовое вымирание входивших в них животных; наиболее интенсивно эта деструкция шла в альбе (захватывая конец апта и начало сеномана).

В старых применениях оно может жить ещё хоть вечно, за компанию к упоминавшемуся тут, не к ночи будь сказано, X12, но если ты мне покажешь хоть один пример новой технологии (а не расширения/дополнения существующих), где применён ASN.1, за последние 15 лет, я буду удивлён. По-моему, последним героическим движением в эту сторону было H.323.

Здравствуйте, Mamut, Вы писали:

M>Типы. Типы в JSON'е — это типы JavaScript'а. Как ни странно, это вызывает проблемы в большом количестве языков — от вопросов, как представлять объекты, которые на самом деле списки «ключ-значение», до проблем за конвертацией float'ов.

Ну вообще-то списки ключ-значение — это основа _любой_ структурированной форматной схемы. ASN.1, XML, JSON, даже ini файлы (хотя в последнем случае нет принципиально неограниченной вложенности). А иначе и не будет в задаче сериализовать что угодно в поток октетов, независимо от того, ограничены мы текстовыми представлениями или нет, и чтобы это хоть как-то было структурно сгруппировано. Конечно, везде введут свои грабельки — в ASN.1 это будет не name-value, а type-length-value, с косвенным кодированием name в виде порядка полей и context-specific type, в XML не будет бинарных данных (base64, cdata и т.п. это хаки), во внутренних сериализациях Python, Erlang и прочих будут только свои типы и укладка на них...
Вот если бы там делали передачу, например, прототипов объектов JS — были бы тяжёлые гайки. А так — просто ещё один вариант натягивания совы на глобус с выбором компромисса между целевыми характеристиками.

А вот с конкретными представлениями данных уже проблемно, согласен. Начиная с float, которое не float (NaN, INF запрещены), далее строками, которые только юникод (для передачи произвольной бинарки нам пришлось выбирать между укладкой в base64 и конверсией iso-8859-1 -> utf-8). Любые данные так можно прохачить передачей текста, но именно хаком это и будет.

M>Да и сами типы очень ограничены. Это — строка, числа, ключ-значение и массив. Всё. В качестве квеста предлагаю поискать, как стандартным образом сериализовать в JSON дату, например. Это не прописано в спеке, а про ISO 8601, как оказалось, знают полтора человека в интернете. .NET, например, генерит что-то типа "\/Date(1320825600000-0800)\/"

Я правильно понял, что это unixtime в миллисекундах плюс пояс?
В XML тоже жёсткого ограничения нет, но, насколько я понял XSD, там ISO8601.

M>Инструментирование. В частности — валидация. Если для того же XML есть XSD, в котором можно задать правила построения типов (практически) любой сложности, для JSON'а это отсутсвует. Есть на самом деле достаточно неплохой черновик стандарта JSON Schema, но на практике ей пользуется полтора человека и есть примерно ноль инструментов, с ней работающих (на правах рекламы очень рекомендую https://github.com/klarna/jesse. К сожалению, тулзу для создания и генерации схем Кларна так и не опенсорснула )

M>Это выливается в невозможность внятно обрабатывать большие объемы JSON'а. Практически максимум, что из себя могут выдавить тулзы — это «expected comma in line 2900 column 4» при том, что ошибка может быть на двести строчек выше.

Да, тут проблема. Но при отсутствии парности тегов вообще локальное обнаружение ошибки становится крайне сложным, проблема типа незакрытой кавычки может тянуться до конца входного потока.

M>Так как JSON — это формат сериализации, использование его для чего-либо другого (например, для конфигов), моментально приводит к разннобразного уровня проблемам: от нечитаемости до impendance mismatch с языками, которые должны его читать, до невозможности писать комментарии, до... до...

То, что комментарии можно писать в XML, среди данного класса средств является исключением

DO>Видимо их задолбал xml. Все-таки xml читать и править руками неудобно, он больше для автоматической обработки. Не, конечно есть всякие тулзы, типа XMLnotepad, но и они задалбывают. Если нужно что-то быстро добавить, удобнее файлик открыть в far'e.
а в чём проблема редактирвоания XML в FARе?

DO>Остальные форматы не лучше. В общем нет в жизни счастья .
как уже сказали, АСН.1 — наше всё.

Здравствуйте, sambl4, Вы писали:

Н>>Как по мне, так язык разметки, в котором нет поддержки комментариев, даже не должен и рассматриваться в качестве кандидатуры на использование в конфигурационных файлах приложения.
S>Стандартный ответ json-фагов — можно добавить свойство "Comment"

Это если комментарии надо сохранить при чтении и последующей записи. А иначе лучше дублировать ключи, в первом комментарий, во втором данные:

{
    "foo": "comment",
    "foo": "data"
}

Здравствуйте, Философ, Вы писали:

Ф>Это если все блоки у тебя на экран влазят (ну хотя-бы на два), то поможет. А если нет?

А фолдинг на что в редакторах?

Здравствуйте, anonymous, Вы писали:

S>>Стандартный ответ json-фагов — можно добавить свойство "Comment"

A>Это если комментарии надо сохранить при чтении и последующей записи. А иначе лучше дублировать ключи, в первом комментарий, во втором данные:

Вот в этом вся прелесть json-а: даже сами авторы не умеют в стандарты.
RFC7159:

The names within an object SHOULD be unique

Явовская реализация от автора json тоже не поддерживает дубликаты имён.

Но: параллельно с rfc прекрасно себе существует "более официальный" ECMA-404. И в нём про ограничение на уникальность упомянуть забыли.

Честное слово, иногда мне кажется, что ecma committee вдохновлялись старой шуткой про Страуструпа и рынок труда: нет ни одних граблей, на которые ещё не успели наступить и с вдохновением оттоптаться.

Больше матчасти:
http://stackoverflow.com/questions/21832701/does-json-syntax-allow-duplicate-keys-in-an-object/23195243#23195243
http://stackoverflow.com/a/18018493/318263 (см комментарии)

P.S. Комментарий автора про сабж. Ещё есть сомнения, что шутка несколько затянулась?

Здравствуйте, Sinix, Вы писали:

A>>Это если комментарии надо сохранить при чтении и последующей записи. А иначе лучше дублировать ключи, в первом комментарий, во втором данные:
S>Вот в этом вся прелесть json-а: даже сами авторы не умеют в стандарты. RFC7159:

The names within an object SHOULD be unique

SHOULD не MUST. См. RFC 2119.

S>Явовская реализация от автора json тоже не поддерживает дубликаты имён.

Это всего лишь проблема реализации. Не один из стандартов не запрещает явно дублировать ключи.

Здравствуйте, anonymous, Вы писали:


A>SHOULD не MUST. См. RFC 2119.
Я-то в курсе. А вот авторы, к сожалению, нет. О чём и писал.

A>Это всего лишь проблема реализации.
Перевожу с маркетингового на человеческий: "валидный" json может:

— Прочитаться нормально
— Не прочитаться вообще
— Прочитаться, но с комментариями вместо значений.

Ну и смысл играть в продакшне в русскую рулетку?