Отличие true от «true» — это очень важно. Также как и отличия «0042» от 0042.
1. отсутствие тега — это undefined, null — это явное указание. И да, это вполне может использоваться. Маркать элемент атрибутом о том, что он null — это костыль на мой взгляд.
2. тем, что это соглашение для строки.
3. Один элемент — это массив из одного элемента или просто строка? Отсутствие элементов — это null или пустой массив? Или будем заворачивать в ещё один элемент? Тогда как называть внутренности?
4. Тут в JSON примерно так же
5. А я считаю, что вполне могут быть
Зависимость от форматирования — как раз проблема XML, в JSON её нет, в зависимости от парсера, он может сохранить их или убрать, CDATA в целом ничего не добавляет. Т.е. уже грабли на ровном месте, в зависимости от того, что нам надо, и как нам прислали документ.
Так да, JSON Schema == XSD, если хотите, то можете использовать. Но разница в другом.
Давайте приведу аналогию, вы открываете сайт, и там есть текстовое поле с описанием «Я прочитал лицензионное соглашение». Вы догадаетесь что там надо ввести? Конечно, если вы не угадаете, то будет ошибка: «Необходимо ввести в это поле значение True/False» и станет понятно. Но в приличном обществе используют чекбоксы.
Вот и с XML та же подстава, отсутствует всякая типизация. А проверяется только строка на соответствие шаблону. И какой шаблон будет в конкретном случае — известно только разработчику данного формата. Может он сделает True/False, а может true/false или yes/no, 1/0, или вообще зафигачить всё в атрибут. Как вариант, сделать вложенный элемент <True/>. Есть множество способов, какие-то более распространённные, какие-то редкие. Но чтобы выяснить, что используется в конкретном случае, надо читать схему или пробовать методом научного тыка.
Если серьёзно, то с XML я достаточно давно работаю, ещё с тех пор, как это было прорывом и кровавый энтерпрайз радостно залез на него. Я и читал многостраничные талмуды по форматам и сам писал, и делал сложные схемы, использовал xsd и xpath.
Но… каждый раз это всегда боль, одни и те же задачи все решают по-разному, реальные документы не бьются с документацией, схемы валятся (и у тебя выбор — это переписка на неделю с объяснением, что ты не верблюд, или подсовывание костыля).
XML это очень сложно, у него безумное количество фич, при этом он совершенно беспомощный в базовых вещах. Проблемы решаются валидацией по схеме, но не здравым смыслом. То, что на JSON очевидно — в XML должно быть специально описано, и в каждом, блин, случае обязательно будет по-разному.
Я имел в виду начальные и конечные пробелы, типа " слово ". Но ваше уточнение ещё интереснее, т.е. если в тексте попадается 2 пробела, его надо заворачивать в CDATA. Это, блин, реально уже страшный формат получается. Т.е. такие нюансы надо иметь в виду, чтобы случайно не сесть в лужу.
А какие стандартные соглашения для XML существуют:
1. null
2. true/false
3. массивы
4. даты
5. отличия строк от чисел
А то в лоб я могу придумать кучу способов, но какие правильные?
Ну и бонусом вопрос, в XML правильно игнорировать или ведущие пробелы или нет?
Конфиг файл с необходимостью корректного поддерживания отступов — это мегавин и отличный способ отстрелить себе ноги. Конфиги могут правится левой пяткой на сервере, могут генериться кодом или скриптами, мёржиться, открываться в виндовом блокноте (у которого только недавно починили \n), и когда лишний пробел ломает конфигурацию (причём обычно так, что настройка просто не читается, но сразу всё не падает) — это дарит замечательные часы отладки.
В общем, на мой взгляд один из самых ужасных форматов конфигурации, который почему-то всюду засовывают.
Обновление прошивок — это отличный совет, особенно в связи с тем, что обычно выносится всё содержимое диска (или хотя бы не гарантируется его сохранность). А иногда ещё не работает, если диск основной. Т.е. покупаем второй SSD, грузимся с него, перепрошиваем первый и восстанавливаемся из бекапа. Очень удобно.
Ну так у него весьма древняя технология (34nm) и MLC, а сейчас норовят везде QLC засунуть, у которого запас перезаписей в стиле — чего вы волнуетесь, вам хватит*
(* если вы его не очень часто доставать с полки будете).
Ээх… тоже делал свой архиватор (LZ4, вид сбоку), такая интересная тема. Понял, что гораздо интереснее делать всякие нестандартные вещи (типа сжатие независимых похожих объектов), передача метаинформации в архиве, сжимать ресурсы в программе с простым кодом расжимания. Но понимаешь, что даже ради хобби — достаточно грустное занятие, т.к. ресурсов надо на порядок больше.
Нейронка вам ответит: чайник — полое изделие с носиком для кипячения чая. Вы можете купить их в магазине…
А если серьёзно — нет там никакого смысла, тупой матчинг по количеству слов. Т.е. если вы попадёте в шаблон вопроса, в котором есть нужные слова — вам и ответят нужными ответами.
То чувство, когда в делаешь свою инфраструктуру так, чтобы всегда данные досортировывались по Id (на случай подобного), а потом видишь блог Ростелекома, в котором находят «проблему» и героически её решают.
Предлагаю следующую статью: почему перемешивание с помощью сортировки по Math.random — плохая идея.
Мы как бы современный веб обсуждаем, где сплошные скрипты. :) Анна Каренина без сжатия весит 1Мб, думаете на новостных порталах текстов больше за 2 часа? А картинки — не блокируют загрузку страницы, да и превьюшки там в основном.
В таком варианте — да. Но, многие скрипты и картинки грузятся асинхронно, и не очень влияют на впечатление о сайте.
Просто как абстрактный пример. У нас есть интернет магазин, у которого фактически 2 страницы для пользователя: список товаров и карточка товара. После первого захода может приехать куча скриптов и стилей. Но человек ходит по сайту, смотрит разные товары и по факту он получает только информацию о товаре и его фотографии. Т.е. в случае условного SPA — у него только данные придут, у него всё уже загружено. Вот в данном случае, насколько важно время первой и время последующих?
А я видел, как люди упарывались именно ради первой загрузки. Сайт открывался быстро, но потом всё дёргалось и моргало, т.к. люди обманывали тесты и роботов, чтобы сайт в выдаче был красивый, но на людей было наплевать.
1. отсутствие тега — это undefined, null — это явное указание. И да, это вполне может использоваться. Маркать элемент атрибутом о том, что он null — это костыль на мой взгляд.
2. тем, что это соглашение для строки.
3. Один элемент — это массив из одного элемента или просто строка? Отсутствие элементов — это null или пустой массив? Или будем заворачивать в ещё один элемент? Тогда как называть внутренности?
4. Тут в JSON примерно так же
5. А я считаю, что вполне могут быть
Зависимость от форматирования — как раз проблема XML, в JSON её нет, в зависимости от парсера, он может сохранить их или убрать, CDATA в целом ничего не добавляет. Т.е. уже грабли на ровном месте, в зависимости от того, что нам надо, и как нам прислали документ.
Давайте приведу аналогию, вы открываете сайт, и там есть текстовое поле с описанием «Я прочитал лицензионное соглашение». Вы догадаетесь что там надо ввести? Конечно, если вы не угадаете, то будет ошибка: «Необходимо ввести в это поле значение True/False» и станет понятно. Но в приличном обществе используют чекбоксы.
Вот и с XML та же подстава, отсутствует всякая типизация. А проверяется только строка на соответствие шаблону. И какой шаблон будет в конкретном случае — известно только разработчику данного формата. Может он сделает True/False, а может true/false или yes/no, 1/0, или вообще зафигачить всё в атрибут. Как вариант, сделать вложенный элемент <True/>. Есть множество способов, какие-то более распространённные, какие-то редкие. Но чтобы выяснить, что используется в конкретном случае, надо читать схему или пробовать методом научного тыка.
Если серьёзно, то с XML я достаточно давно работаю, ещё с тех пор, как это было прорывом и кровавый энтерпрайз радостно залез на него. Я и читал многостраничные талмуды по форматам и сам писал, и делал сложные схемы, использовал xsd и xpath.
Но… каждый раз это всегда боль, одни и те же задачи все решают по-разному, реальные документы не бьются с документацией, схемы валятся (и у тебя выбор — это переписка на неделю с объяснением, что ты не верблюд, или подсовывание костыля).
XML это очень сложно, у него безумное количество фич, при этом он совершенно беспомощный в базовых вещах. Проблемы решаются валидацией по схеме, но не здравым смыслом. То, что на JSON очевидно — в XML должно быть специально описано, и в каждом, блин, случае обязательно будет по-разному.
1. null
2. true/false
3. массивы
4. даты
5. отличия строк от чисел
А то в лоб я могу придумать кучу способов, но какие правильные?
Ну и бонусом вопрос, в XML правильно игнорировать или ведущие пробелы или нет?
В общем, на мой взгляд один из самых ужасных форматов конфигурации, который почему-то всюду засовывают.
(* если вы его не очень часто доставать с полки будете).
А если серьёзно — нет там никакого смысла, тупой матчинг по количеству слов. Т.е. если вы попадёте в шаблон вопроса, в котором есть нужные слова — вам и ответят нужными ответами.
Предлагаю следующую статью: почему перемешивание с помощью сортировки по Math.random — плохая идея.
— Я тут подожду
Просто как абстрактный пример. У нас есть интернет магазин, у которого фактически 2 страницы для пользователя: список товаров и карточка товара. После первого захода может приехать куча скриптов и стилей. Но человек ходит по сайту, смотрит разные товары и по факту он получает только информацию о товаре и его фотографии. Т.е. в случае условного SPA — у него только данные придут, у него всё уже загружено. Вот в данном случае, насколько важно время первой и время последующих?
А я видел, как люди упарывались именно ради первой загрузки. Сайт открывался быстро, но потом всё дёргалось и моргало, т.к. люди обманывали тесты и роботов, чтобы сайт в выдаче был красивый, но на людей было наплевать.