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

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

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

F>XSLT — у json такого нет (ошибаюсь?), но можно на любом скриптовом языке накатать.
F>XSD — у json нет подобной валидации.
json не настолько каша, чтобы для работы требовались какие то специфические инструменты

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

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

vsb>> А когда окунаешься в реальный мир и видишь там
vsb>>то хочется немного старого доброго XML-я с закрывающими тегами.

S>А казалось бы, всего лишь навсего нужно открыть в редакторе с подсветкой блоков. Так нет же, ведро жидкого же вылить надо.

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

Здравствуйте, Нахлобуч, Вы писали:

Н>Вот что это за непотребство такое?

Это называется треньдь. Потрендят и перестанут.

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

Н>>Вот что это за непотребство такое?

VD>Это называется треньдь. Потрендят и перестанут.

Правильно. Вот с XML потрендили и прекратили безобразие.

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

vsb>Кучу инструментов для него придумали: простой декларативный DTD, мощнейшая XML Schema, какие-то Schematron-ы, XSLT и многое другое.

Это хорошо.

vsb>А когда окунаешься в реальный мир и видишь там
vsb>

vsb>                      }
vsb>                    }
vsb>                  }
vsb>                ]
vsb>              }
vsb>            }
vsb>          ]
vsb>        }
vsb>

vsb>то хочется немного старого доброго XML-я с закрывающими тегами.

А чем это лучше?

                           </a>
                         </a>
                       </a>
                     </b>
                   </a>
                 </a>
               </a>
             </b>
           </a>

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

S>>А казалось бы, всего лишь навсего нужно открыть в редакторе с подсветкой блоков. Так нет же, ведро жидкого же вылить надо.
Ф>Это если все блоки у тебя на экран влазят (ну хотя-бы на два), то поможет. А если нет?
Чтото я не понял, к чему тут размер экрана о0

Здравствуйте, Нахлобуч, Вы писали:

а я согласен, более того мне и жсон не нравится, я у себя перешел на еще более простую версию, не нужны все эти массивы и запятые

Frame = "Test"
{ 
    width=800 height=ch material="1 1 1" clipping=true 

    Frame {width=50 height=p.ih*0.5 material="1 0 0" }
    Frame {width=p.fw    height=490 material="0 1 0" }
    Frame {iwidth=cw height=400 margin=10 padding=10 border=10 material="0 0 1" clipping=true 

        Frame = "C-c" {width=200 height=p.ih*0.3 material="0 0.3 1" clipping=true }
        Frame = "C-c"
        {
            width=200 height=p.ih material="0 0.5 1" clipping=true 
//            Frame = "C-c-0" { width=f.width*0.5 height=100 border=5 material="1 1 0"  }
//            Frame = "C-c-1" { width=100 height=110 border=5 material="1 1 0"  } 
//            Frame = "C-c-2" { width=f.width*0.5 height=120 border=5 material="1 1 0"  } 
        }
    }
}

любой элемент емеет свой2 значение и дочерние элементы, все они однородны
но по соглашению нижний регистр в названии это атрибуты, верхний — дочерние элементы
также по соглашению атрибуты можно писать в одну строчку

и можете минусовать я не вернусь!!!!!!

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

MTD>А чем это лучше?

Тем, что мы сидим в середине документа и видим контекст. Видим, в каком месте мы находимся и после какого тега надо начинать писать следующий.

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

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

MTD>>А чем это лучше?

vsb>Тем, что мы сидим в середине документа и видим контекст. Видим, в каком месте мы находимся и после какого тега надо начинать писать следующий.
И я вижу
]

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

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

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

Здравствуйте, Нахлобуч, Вы писали:

Н>Вот что это за непотребство такое?
Н>Какие такие инвалиды интеллектуального труда решили взять и заменить XML-конфигурацию на JSON?

Действительно ведь. YAML не осилили

Н>Какие такие инвалиды интеллектуального труда решили взять и заменить XML-конфигурацию на JSON?

JSON — это вообще странный зверек. Тут ща будет много неструктурированного текста.

Во-первых. JSON — это JavaScript Object Notation. Это его первое, главное, единственное, определяющее ключевое свойство. Из этого проистекают все его плюсы и минусы.

Во-вторых. Проистекающее из во-первых. JSON был создан в первую и определяющую очередь для веба. Для всех этих SPA (single page applications), которые громко вошли в этот мир под названием Web 2.0 (помните этот термин? )

Вспомните, что было практически единственным более-менее стандартным способом передачи данных между клиентов и сервером на момент появления JSON'а? Подсказка: термин AJAX расшифровывается как Asynchronous Javascript and XML.

С точки зрения веб-приложений JSON был спасением. В условиях достаточно маленьких скоростей середины двухтысячных использование JSON'а позволяло легко экономить ~30% на объемах передаваемых данных (или около ~10% если трафик gzip'ался). И вообще, до сих пор практически нет форматов сериализации, которые могли потягаться с JSON'ом в вебе.

У JSON'е есть еще одно свойство, которое у него образовалось совершенно случайно. Он легко читается людьми в объемах примерно около страницы экранного текста. Ну то есть обычно в тех пределах, что как раз передаются между сервером и веб-страницами. Это — sweet spot JSON'а, в котором он кроет большинство других форматов, как бык овцу: бинарные форматы вообще нечитаемы людьми, XML на таких объемах мешает количеством лишней информации, а прочие форматы типа YAML в разы сложнее JSON'а и могут иметь весьма нетривиальные ловушки на ровном месте (спецификация YAML'а — легко подходит под пару сотен страниц).

Промежуточный итог. JSON:
— нативен для веба
— легко читается и понимается людьми на маленьких объемах
— сроки в нем строки, целые числа — целые числа, массивы — массивы, объекты — объекты
— вся спецификация JSON'а умещается в одну страницу
— для него тривиально написать парсер и сериализатор на любом языке

Но

JSON — это кровь от крови JavaScript'а и плоть от плоти веба. Соответсвенно, использование его где-либо в других местах будет вызывать неизбежный impedance mismatch.

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

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


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

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

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

Что-то еще хотел написать, но уже не помню, что Если вспомню, допишу.

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

Name, Age
Vasya, 20
Kolya, 30

JSON:

[{"Name":"Vasya","Age":20},{"Name":"Kolya","Age":30}]

XML:

<persons>
    <person>
        <name>Vasya</name>
        <age>20</age>
    </person>
    <person>
        <name>Kolya</name>
        <age>30</age>
    </person>
</persons>

Данные везде одинаковые, представления — разные!

Более того, даже в одном формате, возьмём XML для примера, одни и те же данные можно представлять по-разному.

1. <persons><person><name>Vasya</name><age>20</age></person><person><name>Kolya</name><age>30</age></person></persons>

   
   Читабельно? Не думаю...
   
   

2. <persons>
   <person>
   <name>Vasya</name>
   <age>20</age>
   </person>
   <person>
   <name>Kolya</name>
   <age>30</age>
   </person>
   </persons>

   
   Расположили каждый тэг на новой строке. Чуточку лучше, но всё равно неудобно.
   
   

3. <persons>
       <person>
           <name>Vasya</name>
           <age>20</age>
       </person>
       <person>
           <name>Kolya</name>
           <age>30</age>
       </person>
   </persons>

   
   Форматированный xml с отступами. Гораздо лучше!
   
   
4. 
   
   
   А теперь финальный штрих: xml не только с отступами, но и с подсветкой синтаксиса! В таком варианте и атрибуты хорошо отличимы от тэгов.
   Вставил картинкой, т. к. кывт не может в подсветку xml.
   Полагаю, никто не будет возражать, что последний вариант самый читабельный? Между тем, во всех четырёх вариантах данные одни и те же, изменилось лишь их представление.

Суть в чём: любой специализированный xml-редактор позволяет нажатием одной кнопки отформатировать документ из первого варианта в четвёртый. То есть компактные данные будут представлены в удобном для восприятия виде. И сохранять специализированный xml-редактор может (должен) без отступов (чтобы лишнее место не занимать).
То есть читабельность для человека должен обеспечивать софт, а не сам формат данных!

Я уже давно пришёл к выводу, что данные должны храниться в компактном (чтобы занимать мало место и быстро читаться/записываться/пересылаться по сети) и удобном для парсинга (чтобы быстро читаться/записываться/индексироваться в случае необходимости) формате.
Для того же xml есть бинарные форматы. Реализация Microsoft.

Увы, с этим одна глобальная проблема: нет такого единого стандартизированного формата.

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

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

Оказывается, в SQLite тоже прикрутили JSON не так давно.

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

F>Оказывается, в SQLite тоже прикрутили JSON не так давно.

Его и к MSSQL уже прикрутили

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

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

K>JSON:
K>

[{"Name":"Vasya","Age":20},{"Name":"Kolya","Age":30}]

У JSON тоже разные представления могут быть:

[
  {
    "Name" : "Vasya",
    "Age" : 20
  },
  {
    "Name" : "Kolya",
    "Age" : 30
  }
]

Более читаемо но уже не так компактно.


Умеет подсветку XML:

<?xml version="1.0" encoding="utf-8"?>
<persons>
    <person>
        <name>Vasya</name>
        <age>20</age>
    </person>
    <person>
        <name>Kolya</name>
        <age>30</age>
    </person>
</persons>

Здравствуйте, Нахлобуч, Вы писали:

Н>Какие такие инвалиды интеллектуального труда решили взять и заменить XML-конфигурацию на JSON?

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

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

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

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

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

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