Достаточно в этой схеме появиться ещё одному атрибуту, к примеру, hint path или имени нюгет-фида, как "наглядный" код превращается в кучу отступов и скобочек.
Xml от этой проблемы по понятным причинам не страдает.
UPD: с галёрки подсказывают, что 99% сторонников yaml-а сами yaml не кушали. Одно требование "никаких табов" уже ставит на нём крест, как на языке для человеков.
Нравится зависеть от невидимых символов — велкам в whitespace, в рабочий проект такой изврат тащить точно не стоит.
TOML тож немногим лучше — один таб == один пробел, насколько помню. Может поменялось, давно смотрел.
Здравствуйте, Sinix, Вы писали:
S>TOML тож немногим лучше — один таб == один пробел, насколько помню. Может поменялось, давно смотрел.
TOML:Indentation (tabs and/or spaces) is allowed but not required
Т.е. используется только для визуальной "красоты":
[servers]
# Indentation (tabs and/or spaces) is allowed but not required
[servers.alpha]
ip = "10.0.0.1"
dc = "eqdc10"
[servers.beta]
ip = "10.0.0.2"
dc = "eqdc10"
HgLab: Mercurial Server and Repository Management for Windows
Здравствуйте, Нахлобуч, Вы писали:
Н>Т.е. используется только для визуальной "красоты":
Ага, фигню написал, спасибо за поправку!
Toml тогда точно смотрится лучше, чем прочие замены xml-ю.
Хотя не, с галёрки снова подсказывают, что в длинных вложенных таблицах нельзя просто так взять и переименовать узел. В общем куда не глянь — везде какой-то косяк
Здравствуйте, Sinix, Вы писали:
BDA>>А если пользователь сломан? Тоже «возьми нормальный»? Я не фантазирую, а просто вспоминаю, как группа приплюсников просила избавиться от разделения на аттрибуты и ноды. И S>Ну по-хорошему да. В смысле, не пользователя менять, а подход. Или просить заказчика предоставить xsd-схему (это заодно решает 1000 других вопросов), или не притворяться, что у вас валидный xml.
Ну, дадут схему, а там одни аттрибуты. Или все в ноды свалено. И что? Если техническая проблема имеет место, схема ее не закроет.
Кроме того, не могу удержаться от вопроса: мы что, кодеры? Или, все-таки, зарабатыватели денег? Просить заказчика об xsd-схеме, когда он сам в ней не заинтересован, это, зачастую, итальянская забастовка. На свободном рынке обструкционизм несовместим с заработками. Может, еще функциональную спецификацию просить?
BDA>>Как что? Информацию о том, когда объект применяется, записать в сам объект. То есть, описывая конфигурацию в описании указывать — применимо для того-сего. Инженерно не очень, зато в главной струе. S>Ну так косяк это. Для любого графа характерны конструкции вида узел с кучей атрибутов + подузлы. На xml такие конструкции ложатся как родные. В json зачастую приходится городить отдельные контейнеры для атрибутов и для подузлов, чтоб не смешивались.
Я, собственно, перечислил все «зато»:
1. Зато такой XML, в свою очередь, плохо ложится на SQL;
2. Зато правильно писать такой XML труднее;
3. Зато (были?) проблемы с парсингом.
Разумеется, (1) мало кто будет класть в SQL *proj и как-нибудь в MS осилят теорию (2) и практику (3). (Это к вопросу о контексте). Я про более общую постановку вопроса, а именно: да, нельзя без потерь информации отконвертировать произвольный XML в json, т.е. XML универсальнее. Но с учетом практики применения XML, это не так уж важно.
Более того, если не грузиться специально, что condition — метаданные, в файле 1.json это в глаза не бросается, а в остальном он гораздо человекочитаемее.
S>
BDA>>А, это просто издержки фирменного стиля Майкрософт при лысом и индусе. S>Не-не-не, давайте не смешивать аналогии, неверные предположения и реальное положение дел.
Любая метафора имеет свои ограничения. Для меня важно, что Майкрософт в погоне за новыми рынками забивает на текущую клиентуру. Что мы тут и видим в прямом эфире через призму технологий и хипстерства. Мне показалось, что вы при этом неявно высказываетесь в пользу того, что гнаться за новым не надо (мол, клиенты голосуют за XML, вот и надо залипнуть на нем), а я утверждаю, что гнаться надо, но по-другому. Если показалось неправильно, значит, показалось неправильно.
BDA>>Была у них такая система — Windows Mobile. S>Вот тут 100% менеджмент-фейл, с технической стороны винфон на сегодня — одна из самых изящных платформ. С продвижением ёк, ну так вообще удивительно, что оно вообще продаётся, с таким-то творческим подходом.
Вы так говорите, как будто возражаете мне. Между тем, я об этом и пишу: да, это фейл менеджмента, и в чем он, собственно, состоит? А в том, что нельзя резко вводить технические улучшения (которые делают всю изящность) туда, где клиенты всем довольны. Рано или поздно они сами дозреют, но без мыслей скипнуть к черту.
BDA>>Понимаете, к чему я веду? Реальные клиенты их давно линяют по другим платформам. S>А вот тут — фига с два. Просто большинство клиентов плавно переползают с самосбора на решения "допилить напильником". Ну, т.е. в нишу конструкторов сайтов, пхп и 1с
Опять же, на что вы возражаете? Линяют же?
BDA>>Эволюция идет с неизбежностью ледника. Переходи они на json или не переходи, рано или поздно кранты ихнему ASP. S>И снова нет — куда ж они денутся? Отток возможен только для прослойки "что в дизайн-студии предложили, то и взяли". Это товарищи постоянные, как флюгер, каждые два года фаворит меняется. Легко пришло — легко ушло короче.
А вот увидите. Лет через 10 вспомните мои слова. Прямо сейчас есть альтернативы в виде Symfony и Java для новых проектов, за ними стоят люди, которые не как флюгер, каждые несколько лет не переделывают все заново. И не клоуны, которые айфон хоронят (ведь, позорище же). И не идиоты, которые бесят лояльную клиентуру (в прямом эфире). Кто сейчас в здравом уме будет с ними связываться? Все они висят только на одной сопле — наследии Гейтса. Вот вы тут аспшничаете почему? Не потому ли, что пятнадцать лет назад встали на эти лыжи? Ну а я их снял. По асфальту не едут
А будущее, все-таки, за Node.JS и json.
BDA>>И они это понимают. Студия 2015, ИМХО, интересна только потому, что Node.JS поддерживает из коробки, вместе с редактором клиентских скриптов. S>Ну блин, снова вы на следствия смотрите, а не на первопричины. Второй год на конференциях прямым текстом рассказывают что и почему. Они не только ноду поддерживают, они практически всё к себе под крыло сгребают. Вон недавно про .net-стек расписывал
Здравствуйте, 0BD11A0D, Вы писали:
S>>Ну по-хорошему да. В смысле, не пользователя менять, а подход. Или просить заказчика предоставить xsd-схему (это заодно решает 1000 других вопросов), или не притворяться, что у вас валидный xml. BDA>Ну, дадут схему, а там одни аттрибуты. Или все в ноды свалено. И что? Если техническая проблема имеет место, схема ее не закроет.
Ну и ок. Раз заказчик формат выбрал — так и выгружаем. Другой заказчик попросит смесь из атрибутов/контента, третий ещё что-то придумает, в любом из вариантов у нас будет валидный xml. С json всё печальней, там даже схем толком нет.
BDA>Просить заказчика об xsd-схеме, когда он сам в ней не заинтересован, это, зачастую, итальянская забастовка. На свободном рынке обструкционизм несовместим с заработками. Может, еще функциональную спецификацию просить?
Ну давай от темы не уклоняться, м? Проблема у вас по факту была не в "нужны только атрибуты / контент", а в том, что вы пытались обмениваться xml без схемы. В общем, вы узнали, зачем нужны xsd сложным способом.
BDA>1. Зато такой XML, в свою очередь, плохо ложится на SQL;
Все нормальные базы наотлично умеют в xml. В том числе и разбирать xml на отдельные записи.
BDA>2. Зато правильно писать такой XML труднее;
Все нормальные редакторы умеют проверку xml-я на базе xsd-шек. Снова "просто используй нормальные инструменты".
BDA>3. Зато (были?) проблемы с парсингом.
Ну как бы обсуждали уже. Проблема оказалась не с парсингом. Проблема в том, что вы выдавали xml, не подходящий под формат заказчика. Снова нутыпонял
BDA>Любая метафора имеет свои ограничения. Для меня важно, что Майкрософт в погоне за новыми рынками забивает на текущую клиентуру.
А, ну тогда мы об одном и том же говорим. И я не сказал бы, что это что-то новое (перевод). Смотрим на дату поста
BDA>А будущее, все-таки, за Node.JS и json.
Воот очень с большим скепсисом. Не, в первые два-три раза можно повестись. А вот когда подобных "наше всё" перевидал с десяток и все как одна в итоге сдулись в свою родную нишу, на очередные решения-для-всего всерьёз смотреть не получается.
S>>Ну блин, снова вы на следствия смотрите, а не на первопричины. BDA>Евангелизм меня мало интересует и их самопиар тоже.
Чой то вас снова занесло. Вам расписывают как оно на самом деле обстоит, а вы про евангелизм начинаете. Фу-фу-фу так делать.
S>Все нормальные редакторы умеют проверку xml-я на базе xsd-шек. Снова "просто используй нормальные инструменты".
Хм, хорошее предложение, если бы не одно «но»: иногда нет доступа к «нормальным инструментам». Из практики, приезжаешь на объект, надо быстренько поправить конфиг, небольшой такой, 20000 строчек всего, а на машине кроме нотпада ничего нет, голый MS Server.
PS И не надо мне тут рассказывать, что «нормальные инструменты» надо с собой возить, нету возможности запустить «нормальные инструменты».
Здравствуйте, Dym On, Вы писали:
DO>Хм, хорошее предложение, если бы не одно «но»: иногда нет доступа к «нормальным инструментам». Из практики, приезжаешь на объект, надо быстренько поправить конфиг, небольшой такой, 20000 строчек всего, а на машине кроме нотпада ничего нет, голый MS Server.
Внезапно инструменты надо не только ставить, но и использовать
В "голом" сервере есть ie, который наотлично показывает xml-ки, уж найти-то нужное место с помощью него несложно.
Если стоит ms sql, то SSMS умеет XML, начиная с 2005го.
DO>PS И не надо мне тут рассказывать, что «нормальные инструменты» надо с собой возить, нету возможности запустить «нормальные инструменты».
В смысле? Ни vs online, ни файл на свой ноут перекинуть, ни флешку воткнуть?
Ну молодцы конечно. Но как это относится к 99% более реалистичных сценариев?
UPD А, ну и с интересом заслушал бы, как нам тут поможет json. Он как правило раза в полтора длиннее по строчкам, если что. Про "сбалансировать скобки после редактирования" не будем. Незачем троллить
S>Внезапно инструменты надо не только ставить, но и использовать S>В "голом" сервере есть ie, который наотлично показывает xml-ки, уж найти-то нужное место с помощью него несложно.
IE это не нормальный инструмент. Внезапно, его приходится использовать, но редактировать все равно в нотпаде . Ну нашел ты нужную запись в 7654 строке, надо значение поправить и как это сделать с помощью ie? Особенно зачетно, бывает если кто-то до тебя лишний пробел между атрибутами поставил.
S>Если стоит ms sql
не стоит
S>В смысле? Ни vs online, ни файл на свой ноут перекинуть, ни флешку воткнуть?
Именно так.
S>Ну молодцы конечно. Но как это относится к 99% более реалистичных сценариев?
В моем случае это 100% сценариев.
S>UPD А, ну и с интересом заслушал бы, как нам тут поможет json. Он как правило раза в полтора длиннее по строчкам, если что. Про "сбалансировать скобки после редактирования" не будем. Незачем троллить
Совершенно верно. Поэтому, когда я еще занимался непосредственно программированием, я с какого-то момента конфиги делал в стиле unix, т.е. ключ=значение, все легко правиться в нотпаде.
Здравствуйте, Mystic, Вы писали:
vsb>>Это называется мода.
M>Я бы не сказал, что это мода. Это типичная ситуация, когда некоторые программисты, как я понимаю, вроде тебя, потратили N человеко-месяцев на изучение многих возможностей XML, и научились его готовить. А другая часть, вроде меня, пожалели на это время. Ну и когда распространился JSON, который можно выучить за пару часов, и который покрывает 99% их потребностей, начали его использовать.
Какие пару часов? Синтаксис XML очевиден за пару минут, что там изучать пару часов, если не влезать в подводные камни. Как и JSON, конечно. А на то, что я потратил N человеко-месяцев, у JSON-а нормальных инструментов в принципе нет. Поэтому если они не нужны — разницы между XML и JSON нет почти никакой, оба варианта просты и интуитивно понятны. Разве что XML имеет стандартное API и библиотеки под практически любой ЯП, так что достаточно выучить его один раз и можно использовать в любом ЯП, в то время как JSON под каждый язык имеет свои библиотеки со своим интерфейсом.
Единственное значимое отличие XML от JSON это то, что в JSON отдельно выделена структура "array", "dictionary", а в XML более простая структура и её отображение на "array", "dictionary" приходится делать несколько сложней.
Здравствуйте, vsb, Вы писали:
vsb>Какие пару часов? Синтаксис XML очевиден за пару минут, что там изучать пару часов, если не влезать в подводные камни.
Кому очевиден ? Люди без продакшн опыта спотыкаются в XML годами, а JSON воспринимают даже не задумываясь.
>А на то, что я потратил N человеко-месяцев, у JSON-а нормальных инструментов в принципе нет. Поэтому если они не нужны — разницы между XML и JSON нет почти никакой, оба варианта просты и интуитивно понятны.
Интуитивно-понятно это мягко говоря преувеличение. JSON понятен любому, кто хотя бы кое что пробовал на JS, а это студенты начиная с колледжей. XML по факту приходится учить в явной форме
1 синтаксис — что бы не путали слеши, правильно ставили угловые скобки и тд и тд.
2 схемы всякие
3 инструментам
4 АПИ
vsb>Единственное значимое отличие XML от JSON это то, что в JSON отдельно выделена структура "array", "dictionary", а в XML более простая структура и её отображение на "array", "dictionary" приходится делать несколько сложней.
Вот-вот. В XML тип определяется схемой. В JSON — синтаксисом.
Здравствуйте, Young, Вы писали:
Y>При том что именно читать YAML удобней чем все другие форматы.
1. JSON — подмножество YAML.
2. Мне лично YAML'овские конструкции читать тяжелее, чем XML и JSON. Местами они неожиданные (типа влияния отступов или когда можно строку не квотить).
Здравствуйте, netch80, Вы писали:
I>>Кому очевиден ? Люди без продакшн опыта спотыкаются в XML годами, а JSON воспринимают даже не задумываясь. N>Если их воспринимать на одинаковом уровне — без схемы — разницы нет.
Оно и видно — за новичками в xml надо вагоны ошибок исправлять,а c JSON как то сами справляются.
Здравствуйте, Pzz, Вы писали:
Pzz>Я не понимаю, почему нельзя в JSON добавить комментарии в синтаксисе C/C++/JavaScript.
Потому что всех прочих проблем json оно никак не решит. Ну не годится этот формат ни для чего, кроме как для перекидывания данных веб-страничкам. Да и там не без фейлов типа работы с датами.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, sambl4, Вы писали:
S>>Стандартный ответ json-фагов — можно добавить свойство "Comment"
Pzz>Я не понимаю, почему нельзя в JSON добавить комментарии в синтаксисе C/C++/JavaScript.
Здравствуйте, netch80, Вы писали:
Pzz>>Я не понимаю, почему нельзя в JSON добавить комментарии в синтаксисе C/C++/JavaScript.
N>Обратная совместимость?
Да, если этот JSON предполагается давать на вход ранее написанным программам. Но если речь идет о конфиге новой программы?...
Здравствуйте, Ikemefula, Вы писали:
vsb>>Какие пару часов? Синтаксис XML очевиден за пару минут, что там изучать пару часов, если не влезать в подводные камни.
I>Кому очевиден ? Люди без продакшн опыта спотыкаются в XML годами, а JSON воспринимают даже не задумываясь.
>>А на то, что я потратил N человеко-месяцев, у JSON-а нормальных инструментов в принципе нет. Поэтому если они не нужны — разницы между XML и JSON нет почти никакой, оба варианта просты и интуитивно понятны.
I>Интуитивно-понятно это мягко говоря преувеличение. JSON понятен любому, кто хотя бы кое что пробовал на JS, а это студенты начиная с колледжей.
Ваши студенты знают JS, но не видели HTML?
I>XML по факту приходится учить в явной форме I>1 синтаксис — что бы не путали слеши, правильно ставили угловые скобки и тд и тд.
И сколько этому надо "учить"? Собственно это и есть аналог JSON.
I>2 схемы всякие I>3 инструментам I>4 АПИ
А этого у JSON нет, поэтому и учить нечего.
vsb>>Единственное значимое отличие XML от JSON это то, что в JSON отдельно выделена структура "array", "dictionary", а в XML более простая структура и её отображение на "array", "dictionary" приходится делать несколько сложней.
I>Вот-вот. В XML тип определяется схемой. В JSON — синтаксисом.
В JSON тип вообще никак не определяется, нет стандартных инструментов, есть разного рода попытки.
