How to become an author
Search
Profile
Pull to refresh

Comments 629

Сделайте возможным пробел в качестве первого символа значения, иначе у вас ничего не получится.
Total votes 39: ↑39 and ↓0 +39
Имеете ввиду сделать префикс значения не "=" а "= "?

Изначально так и было. И отступы пробелами можно было делать. И переводы строк хоть юниксовые, хоть виндовые. Но что даёт нам этот разброд и шатание? Только усложнение всех систем, которые должны это всё поддерживать. Вот в XML вообще пишут слитно имя атрибута и значение, и никто не возмущается.

У предлагаемого вами разделителя я вижу следующие проблемы:
1. Не очевидно, что пробел не входит в значение и вообще не очень понятно с первого взгляда в какой момент оно начинается.
2. Легко не заметить, что поставил 2 пробела вместо 1
3. Нужно решать, что делать с ситуацией, когда после символа равенства идёт не пробел.
4. +1 бесполезный (не несущий дополнительной семантики, только оформительский) байт на каждое значение.
Total votes 38: ↑13 and ↓25 -12
> Вот в XML вообще пишут слитно имя атрибута и значение, и никто не возмущается.
Там атрибуты — самый мелкий уровень, важнее отличить их друг от друга, чем имя от значения. Тут ситуация другая.

Большинство проблем надуманные.
1. Можно так же сказать, что неочевидно, входит ли знак равно в значение, или пробел до знака равно в название ключа.
2. С моноширинным шрифтом сложно. А вот легко, например, не заметить проблемы вместо табуляции, однако вас это не смущает.
3. Ничего страшного в отсутствии пробела нет.
4. Без него «человекопонятность» никак не тянет на пятерочку.
Total votes 29: ↑29 and ↓0 +29
Не вижу никакой разницы. Имена и значения в Tree — это практически и есть атрибуты XML.

1. Можно, но куда сложнее.
2. Не сложно, некоторые даже могут начать пытаться выравнивать значения пробелами после символа равенства, как они привыкли делать, например, в JSON. Про пробелы ругнётся либо редактор, когда попытается подсветить синтаксис, либо парсер, когда попытается распарсить.
3. Страшно — когда что-то может быть, а может не быть. Чем чётче синтаксис, тем проще с ним работать.
4. YAML как раз и получился в погоне за «человекопонятностью», а точнее за гламурным отображением. Понятность должна быть не только для человека, но и для машины. При этом машина должна чётко понимать, что имел ввиду человек, а человек должен чётко понимать, как это поймёт машина. Лишний пробел, который кажется вам критически важным, в лучшем случае никак не повлияет на точность понимания ни человеком, ни машиной. А в худшем — внесёт дополнительную неопределённость.
Total votes 38: ↑10 and ↓28 -18
Для меня, как для программиста, ратующего за аккуратность кода, конструкция типа

value =2

просто недопустима. Это выглядит ужасно и неаккуратно. Лучше уж «value=2», чем ЭТО.
Total votes 16: ↑16 and ↓0 +16
А для максимальной аккуратности стоит писать так:
Value is equal 2.

, забросить инженерное дело и заняться дизайном.
Total votes 16: ↑1 and ↓15 -14
Не стоит так бросаться на всех, своё же детище так закопаете. В лучшем случае появятся более успешные форки.
Мне лично тоже правильнее смотрятся:
user
	name=vintage
	age=30

и
user
	name = vintage
	age = 30

Просто потому что приятная симметрия. Второй вариант ещё читается лучше.

Если формат весь из себя такой гибкий, то можно было бы менять поведение парсера через первую строку в файле, а поведение по умолчанию выбрать голосованием.
Total votes 4: ↑4 and ↓0 +4
Чтобы понять, почему именно так, попробуйте представить, что вместо символа "=" используется символ, например, "|". Единственная его функция — не разделять ключ и значение (это хоть и частый, но всего-лишь частный случай), а именно показывать начало потока бинарных данных.

Формат прежде всего простой, потом уже гибкий, а потом уже читабельный и в последнюю очередь компактный. Ни в одной из этих ипостасей он не идеален и при желании (а его я смотрю у хабраюзеров хоть отбавляй) всегда можно найти к чему придраться. Но всё же, на мой взгляд, он представляет из себя неплохой компромис в отличие от остальных упомянутых тут форматов, которые в чём-то хороши, а в чём-то просто отвратительны.
Total votes 10: ↑1 and ↓9 -8
Формат прежде всего простой, потом уже гибкий, а потом уже читабельный и в последнюю очередь компактный
Никого не волнует насколько формат прост в реализации, его пишут 1 раз, обычно вообще есть несколько либ которые все используют, и всем до лампочки насколько формат прост. Формат должен быть в первую очередь читабельным/удобным для редактирования и потом — гибким.
Total votes 2: ↑2 and ↓0 +2
У каждого, работающего с форматом, человека, в голове есть свой маленький криво написанный интерпретатор.
Total votes 1: ↑0 and ↓1 -1
Совершенно верно, но кривизна этого интерпретатора сильно зависит от количества неочевидных моментов в формате. Так вот, в вашем формате такой неочевидный момент в каждом знаке равенства.
Total votes 1: ↑1 and ↓0 +1
От количества правил. Степень очевидности — дело привычки.
Total votes 2: ↑0 and ↓2 -2
Очевидность надо измерять для человека, впервые этот формат увидевшего. А то некоторые и Qr-коды читают, так что, они от этого стали человекопонятными и очевидными?
This comment wasn’t rated yet 0
Эскейп последовательности, конечно, куда очевидней, для впервые их увидевшего, да.
This comment wasn’t rated yet 0
В тех же XML и JSON надо экранировать далеко не каждую строку.
А вот в вашем Tree непонятность с пробелом и знаком равенства — в каждой строке, содержащей узел-значение.
This comment wasn’t rated yet 0
Какая непонятность? После знака равенства и до конца строки — значение.
Total votes 1: ↑0 and ↓1 -1
Очевидность надо измерять для человека, впервые этот формат увидевшего.
This comment wasn’t rated yet 0
А чем пробел и знак равенства проще чем просто знак равенства перед значением?

И как реализовать многострочное значение без \n? Только начиная каждую строку со знака пробела и равенства? Не выход.
This comment wasn’t rated yet 0
Пробел хорошо визуально разделяет узлы и подчёркивает, что знак равенства — это не разделитель ключа и значения, а просто префикс. Другого такого удобного префикса нет (заметьте, что все специальные символы вводятся в любой раскладке нажатием одной клавиши).

Да, именно так. Благодаря префиксам снимаются неоднозначности вида «Обрезать ли ведущий и завершающий переводы строк?», «Обрезать ли отступы?» и «Если обрезать, то на сколько?».
This comment wasn’t rated yet 0
Тогда получается, что XML выигрывает в возможностях многострочного значения.

А как быть с тем, что поддерживаются только UNIX'овые переводы строк?

А вообще язык меня зацепил, жаль что поддержки нет почти.
This comment wasn’t rated yet 0
<article>
    <comment>
        <code>Чем же выигрывает?
В нём, например, приходится писать без отступов, чтобы в строки не попало лишнего мусора.</code>
    </comment>
</article>


А зачем в современной разработке использовать переводы строк отличные от LF? Не в виндовом блокноте же редактируем код :-)

Речь о библиотеках? Либа на любом языке пилится за несколько часов.
This comment wasn’t rated yet 0
Пилится, но для JSON пилить ничего не нужно.

Где-то есть информация на каких языках уже реализовано что бы велосипед не изобретать?

И ещё, ИМХО: JSON можно сказать просто для передачи информации, а XML именно для разметки. Tree же умудряется довольно хорошо совмещать эти две функции.
This comment wasn’t rated yet 0
Когда-то и JSON был в такой же ситуации. Для XML-то ничего пилить не нужно было. ;-)

Есть реализации на D и TS/JS.

Для инлайновой разметки tree не очень подходит, в отличие от маркдауна. А для блочной — вполне.
This comment wasn’t rated yet 0
А как по мне — нормально. Разделение до знака равенства есть? Есть. С точки зрения логики так даже лучше, знак = здесь и правда — маркер начала данных. А ещё так получаются визуально две лексемы вместо трёх, что воспринимается чётче. Я согласен с автором)
This comment wasn’t rated yet 0
Полагаю, вы хотели бы обрезать пробелы по краям строки (trim)? Хм, а если значение — это символ пробела? Неоднозначность получается.
Total votes 1: ↑0 and ↓1 -1
Нет, не хотел. Я хотел разрешить пробел перед значением. Если пробел один — это пробел. Если их два — второй уже значение. Никакой неоднозначности.
Total votes 6: ↑2 and ↓4 -2
Неоднозначность заключается в том, что первый символ после символа равенства иногда включается в значение, а иногда не включается. И вы предлагаете усложнить реализацию исключительно из эстетических, но не практических соображений. Но я всё же, я сторонник принципа KISS.
Total votes 8: ↑2 and ↓6 -4
первый символ после символа равенства иногда включается в значение, а иногда не включается

Первый пробел после равенства никогда не включается в значение. Если первый символ после пробела после равенства — тоже пробел, то он считается, как значение. Элементарно же ж.
Total votes 1: ↑1 and ↓0 +1
А где пример с не экранированными переносами строк?
Удобство редактирования все так же под вопросом — все эти невидимые символы придется делать видимыми в редакторах.
И еще вопрос, что вы думаете о Tree в сравнении с Lisp-деревьями?
Total votes 10: ↑9 and ↓1 +8
Примерно так:

image

О каких невидимых символах идёт речь?

Пример с JSON-AST из статьи — это фактически и есть Lisp-дерево:

[ [ "function",
    "getEl",
    [ "id" ],
    [ "return",
      [ [ "get",
          "document" ],
        [ "call",
          "getElementById",
          [ "get", "id" ]
        ]
      ]
    ]
  ]
]

Они не так наглядны, как Tree.
Total votes 20: ↑16 and ↓4 +12
Ну т.е. скопировать текст все так же не получится из-за "=" (даже хуже, так как экранирование реализовано везде).

Про невидимые символы: вы не слышали о пробелах и табуляции?) А это значит:
1. Сложности с редактированием документа. Т.е. удобство не 5, а 3 примерно.
2. Значения, не ограниченные ничем могут появляться сами собой (о поверьте, это огромная проблема).

Т.е. одно дело мы используем табуляцию/пробелы в языках программирования — там четкое AST и лишние просто игнорируются, но для данных это беда.
Total votes 18: ↑16 and ↓2 +14
Вырезать по одному символу вначале строки куда проще, чем убрать всё многообразие escape-последовательностей.

1. Вы всегда можете настроить свой редактор, чтобы рисовал табуляцию хоть в 10 символов длиной :-)
2. О чём тут идёт речь?

В Tree тоже чёткое AST. Tree — это и есть самый что ни на есть AST.
Total votes 11: ↑6 and ↓5 +1
Вырезать по одному символу вначале строки куда проще, чем убрать всё многообразие escape-последовательностей.

Допустим я копирую текст из PHP в JavaScript и т.д. \n везде будет переводом строки.
Чтобы убрать \n — мне достаточно простой регулярки заменяющей это на перевод строки (любой редактор). Да, у вас придется заменять перевод_строки= на перевод строки, но в чем достоинство?
По поводу пробелов вы уже ответили ниже habrahabr.ru/post/248147/#comment_8229867 и признаете это проблемой.
Т.е. в итоге лучше б все таки иметь гарантированные \s \t, чем незамеченные пробелы в начале/конце значения данных.
Про AST разница в хранении данных и структуре кода в том, что в коде можно проигнорировать кучу символов (пробелы, переносы строк, табуляцию).
var a = 5; Без разницы сколько тут пробелов до var и после точки с запятой. С данными такое не прокатит.
Total votes 6: ↑4 and ↓2 +2
Допустим я копирую текст из PHP в JavaScript и т.д. \n везде будет переводом строки.

А я, допустим, копирую текст из PHP в HTML и \n больше не будет переводом строки.

Чтобы убрать \n — мне достаточно простой регулярки заменяющей это на перевод строки (любой редактор). Да, у вас придется заменять перевод_строки= на перевод строки, но в чем достоинство?

В данном случае нет никакой разницы, да.

Т.е. в итоге лучше б все таки иметь гарантированные \s \t, чем незамеченные пробелы в начале/конце значения данных.

Только в конце. Проблема куда менее значительная, чем проблема редактирования, когда весь текст в одну строку. И проблема эта вполне решаемая. В любом решении можно найти кучу недостатков, вопрос лишь в том, перевешивают ли достоинства эти недостатки.

var a = 5; Без разницы сколько тут пробелов до var и после точки с запятой.

Ну да, а style guid-ы зачем пишут тогда, раз нет никакой разницы? :-)
Total votes 9: ↑5 and ↓4 +1
Только в конце.

А у меня редактор режет все \s в конце строки при сохранении файла. Ни пробелов, ни табуляций там никогда не имеется, так что очень даже проблема.
Total votes 6: ↑6 and ↓0 +6
Помочь вам настроить редактор так, чтобы он не занимался излишней самодеятельностью?
Total votes 12: ↑1 and ↓11 -10
И еще, далеко не всегда визуально удобно видеть перенос строки как перенос строки.
<locale>
    <var name="t1">Прекрасный день\Мы гуляем\nЖизнь боль</var>
    <var name="t2">Прекрасный день\Мы гуляем\nЖизнь боль</var>
    <var name="t3">Прекрасный день\Мы гуляем\nЖизнь боль</var>
</locale>

Здесь удобнее глазом разделять логические составляющие (переменные), чем собственно само значение.
Total votes 4: ↑2 and ↓2 0
А здесь ключи не надо выискивать в середине строки:

image

И, кстати, вы не заметили, как опечатались в экранировании :-)
Total votes 8: ↑7 and ↓1 +6
Это не я, честно, это хабр)

Ну да, а style guid-ы зачем пишут тогда, раз нет никакой разницы? :-)

Ну все же есть разница в ошибке и в лишнем пробеле в стиле кода?

Только в конце. Проблема куда менее значительная, чем проблема редактирования, когда весь текст в одну строку. И проблема эта вполне решаемая. В любом решении можно найти кучу недостатков, вопрос лишь в том, перевешивают ли достоинства эти недостатки.

Не только, опять же habrahabr.ru/post/248147/#comment_8229867

А здесь ключи не надо выискивать в середине строки:

Но при этом на странице видно лишь очень малое количество значений. Для программирования все же важнее работать со структурами, чем с данными — для значений данных другие редакторы.
Total votes 7: ↑5 and ↓2 +3
Подлый хабр портит первое экранирование в строке :-)

Есть, но всё же несоответствие принятому стилю многими программистами воспринимается не менее рьяно, чем синтаксическая ошибка.

Когда как на самом деле. В конце концов, можно прикрутить автофолдинг к редактору.
Total votes 1: ↑1 and ↓0 +1
Есть, но всё же несоответствие принятому стилю многими программистами воспринимается не менее рьяно, чем синтаксическая ошибка.

Соответствие стилю приводится почти любым редактором нажатием одной кнопки. Поэтому разницы нет сколько пробелов там удалится автоматически. Но с данными… Т.е. разница все же есть и большая.
This comment wasn’t rated yet 0
В случае Tree необходимости в нажатии этой кнопки нет, потому как формат практически не допускает вольностей. И это хорошо — не надо всяких бьютификаторов, минификаторов, валидаторов оформления и прочей ерунды.
This comment wasn’t rated yet 0
Ну все правильно, формат допускает только ручное выискивание лишних пробелов и табов — и это вы называете «человекоудобством». Зачем нам стремная автоматизация процесса — даешь перфоленты. Одна ошибка приравнивается к смерти.
Total votes 3: ↑3 and ↓0 +3
Вы слишком гиперболизируете эту проблему. Инструмент, ненавязчиво подсвечивающий концы строк — не такой уж rocket science.
Total votes 3: ↑0 and ↓3 -3
А вы гиперболизируете оценки Tree). Там, где по вашему мнению кавычки, скобки и экранирование мешают восприятию, по моему мнению, способствуют автоматизации и скорости работы. Мы все таки не художественные тексты пишем.

Инструмент, ненавязчиво подсвечивающий концы строк — не такой уж rocket science.

Верно, только тогда все преимущества отсутствия скобок вообще исчезают, так как мы по прежнему видим разделители и должны их мысленно парсить. Так то и кавычки можно сделать ненавязчимыми в JSON.
Total votes 4: ↑4 and ↓0 +4
JSON плох не только и не столько обилием пунктуации, которую приходится куда-то распихивать (запятую в конце не ставь, открывающую скобку ставим в конце строки, закрывающая висит одиноко в начале и тд).
Total votes 3: ↑0 and ↓3 -3
Ну может и стоит решать эти вопросы? habrahabr.ru/post/248147/#comment_8231413
habrahabr.ru/post/248147/#comment_8230645
Ну и я спрашивала про Lisp в начале обсуждения, вы сказали
Они не так наглядны, как Tree.

Теперь, я надеюсь, я донесла свою точку зрения про наглядность)

(запятую в конце не ставь, открывающую скобку ставим в конце строки, закрывающая висит одиноко в начале и тд).

У вас не менее жесткий набор правил, только основан на табах, = и пробелах. Или у вас можно 2 переноса строк, 2 "=" писать? Или = написать потом перенос строки и т.д.
Total votes 2: ↑2 and ↓0 +2
Теперь, я надеюсь, я донесла свою точку зрения про наглядность)
Когда кругозор сужается до точки, человек называет эту точку «точкой зрения».

Или у вас можно 2 переноса строк
Можно

2 "=" писать?
Тоже можно.

Или = написать потом перенос строки и т.д.
И даже так можно.
Total votes 5: ↑0 and ↓5 -5
Когда кругозор сужается до точки, человек называет эту точку «точкой зрения».

Т.е. вы все еще не согласны с моей самой узкой в мире точкой зрения про наглядность? Тогда где аргументы?
Можно

Все три можно никак не повлияют на целостность данных, так?
Total votes 2: ↑2 and ↓0 +2
Я всё ещё не понимаю что вы пытаетесь доказать.

Разумеется.
Total votes 5: ↑0 and ↓5 -5
Скобки, по-моему, помогают читать сильно структурированный текст — при помощи редакторов с подсветкой скобок типа Notepad++ — и несколько затрудняют-замедляют его написание. Так что неплохо бы ещё и, в виде, например, макроса, иметь «конвертер туда-сюда»…
This comment wasn’t rated yet 0
А есть редакторы с подсветкой табов.
This comment wasn’t rated yet 0
Мне в принципе понравилась идея. Поддержу дискуссию, тем, что у товарища наверно консоль на 50 строк вот ему все в одну и надо.

В Поддержку Tree могу сказать только одно, мне кажется или вот на таком конфиге json, tree будет выглядеть лучше?
Много текста
[
    {
        "title":"Карточка торгов",
        "width":6,
        "class":"",
        "form":[
            {
                "type":"textbox",
                "label":"Наименование",
                "required":true,
                "validate":{
                },
                "model":"name",
                "width":12
            },
            {
                "type":"datebox",
                "label":"Дата публикации в печатном издании",
                "required":true,
                "validate":{
                },
                "model":"publish",
                "width":12
            },
            {
                "type":"datebox",
                "label":"Дата публикации",
                "required":true,
                "validate":{
                },
                "model":"publish2",
                "width":12
            },
            {
                "type":"datebox",
                "label":"Дата публикации №2",
                "required":true,
                "validate":{
                },
                "model":"publish3",
                "width":12
            }
        ]
    },
    {
        "title":"Карточка должника",
        "width":6,
        "class":"",
        "form":[
            {
                "type":"selectbox",
                "label":"Тип должника",
                "required":true,
                "validate":{
                },
                "model":"typepay",
                "width":12,
                "collection":{
                    "type":"list",
                    "mappings":{
                        "id":"model.id",
                        "value":"model.value"
                    },
                    "data":{
                        "1":"Физическое лицо",
                        "2":"Юридическое лицо",
                        "3":"Индивидуальный предпрениматель"
                    }
                }
            },
            {
                "type":"textbox",
                "label":"Фамилия",
                "required":true,
                "validate":{
                },
                "padding":"0px 5px 0px 0px",
                "additional":{
                    "visible":{
                        "typepay":{
                            "eq":[1]
                        }
                    }
                },
                "model":"last_name",
                "width":6
            },
            {
                "type":"textbox",
                "label":"Имя",
                "required":true,
                "validate":{
                },
                "padding":"0px 0px 0px 5px",
                "additional":{
                    "visible":{
                        "typepay":{
                            "eq":[1]
                        }
                    }
                },
                "model":"first_name",
                "width":6
            },
            {
                "type":"textbox",
                "label":"Отчество",
                "required":true,
                "validate":{
                },
                "padding":"0px 5px 0px 0px",
                "additional":{
                    "visible":{
                        "typepay":{
                            "eq":[1]
                        }
                    }
                },
                "model":"father_name",
                "width":6
            },
            {
                "type":"textbox",
                "label":"Полное Наименование организации",
                "required":true,
                "validate":{
                },
                "padding":"0px 5px 0px 0px",
                "additional":{
                    "visible":{
                        "typepay":{
                            "eq":[2,3]
                        }
                    }
                },
                "model":"full_name",
                "width":6
            },
            {
                "type":"textbox",
                "label":"Краткое Наименование организации",
                "required":true,
                "validate":{
                },
                "padding":"0px 0px 0px 5px",
                "additional":{
                    "visible":{
                        "typepay":{
                            "eq":[2,3]
                        }
                    }
                },
                "model":"part_name",
                "width":6
            },
            {
                "type":"textbox",
                "label":"ОГРН",
                "required":true,
                "validate":{
                },
                "padding":"0px 5px 0px 0px",
                "additional":{
                    "visible":{
                        "typepay":{
                            "eq":[2]
                        }
                    }
                },
                "model":"ogrn",
                "width":6
            },
            {
                "type":"textbox",
                "label":"ОГРНИП",
                "required":true,
                "validate":{
                },
                "padding":"0px 5px 0px 0px",
                "additional":{
                    "visible":{
                        "typepay":{
                            "eq":[3]
                        }
                    }
                },
                "model":"ogrn",
                "width":6
            },
            {
                "type":"textbox",
                "label":"ИНН",
                "required":true,
                "validate":{
                },
                "padding":"0px 0px 0px 5px",
                "additional":{
                    "visible":{
                        "typepay":{
                            "eq":[1,2,3]
                        }
                    }
                },
                "model":"inn",
                "width":6
            }
        ]
    },
    {
        "seperator":"clear"
    },
    {
        "title":"Карточка Орагизнатора",
        "width":6,
        "class":"",
        "form":[],
        "file":"app/forms/company_cart.json",
        "position":0,
        "modelprefix":"company."
    },
    {
        "title":"Сведения об имуществе",
        "width":6,
        "class":"",
        "form":[
            {
                "type":"textarea",
                "label":"Сведения об имуществе на торгах",
                "required":true,
                "validate":{
                },
                "model":"info_stuff",
                "width":12
            },
            {
                "type":"textarea",
                "label":"Порядок ознакомления с имуществом",
                "required":true,
                "validate":{
                },
                "model":"oznak",
                "width":12
            },
            {
                "type":"textbox",
                "label":"Начальная цена продажи",
                "required":true,
                "validate":{
                },
                "padding":"0px 5px 0px 0px",
                "model":"start_cash",
                "width":6
            },
            {
                "type":"textbox",
                "label":"Шаг торгов",
                "required":true,
                "validate":{
                },
                "padding":"0px 0px 0px 5px",
                "model":"step_cash",
                "width":6
            }
        ]
    },
    {
        "seperator":"clear"
    },
    {
        "title":"Порядок оформления участия в торгах",
        "width":6,
        "class":"",
        "form":[
            {
                "type":"textbox",
                "label":"Порядок предоставления заявок",
                "required":true,
                "validate":{
                },
                "model":"step_add",
                "width":12
            },
            {
                "type":"textbox",
                "label":"Место предоставления заявок",
                "required":true,
                "validate":{
                },
                "model":"place_add",
                "width":12
            },
            {
                "type":"datebox",
                "label":"Начало приема заявок",
                "required":true,
                "validate":{
                },
                "padding":"0px 5px 0px 0px",
                "model":"start_date_add",
                "width":6
            },
            {
                "type":"datebox",
                "label":"Окончание приема заявок",
                "required":true,
                "validate":{
                },
                "padding":"0px 0px 0px 5px",
                "model":"end_date_add",
                "width":6
            },
            {
                "type":"textarea",
                "label":"Порядок оформления участия в торгах",
                "required":true,
                "validate":{
                },
                "model":"poradok_oform",
                "width":12
            },
            {
                "type":"textbox",
                "label":"Размер задатка",
                "required":true,
                "validate":{
                },
                "model":"size_precash",
                "width":12
            },
            {
                "type":"textbox",
                "label":"Информация счета задатка",
                "required":true,
                "validate":{
                },
                "model":"info_schet",
                "width":12
            },
            {
                "type":"filebox",
                "label":"Договор о задатке",
                "required":true,
                "validate":{
                },
                "filebox":{
                    "type_id":"hdogovorzadatok",
                    "multiple":false,
                    "nofile":"Договор не выбран",
                    "type":"type"

                },
                "model":"dogovor_zadatok",
                "width":12
            },
            {
                "type":"datebox",
                "label":"Дата начала аукциона",
                "required":true,
                "validate":{
                },
                "model":"start_date",
                "width":12
            }
        ]
    },
    {
        "title":"Порядки купли-продажи",
        "width":6,
        "class":"",
        "form":[
            {
                "type":"textarea",
                "label":"Порядок и срок заключения договора купли-продажи",
                "required":true,
                "validate":{
                },
                "model":"poradok_i_srok",
                "width":12
            },
            {
                "type":"textarea",
                "label":"Срок платежей, реквезиты",
                "required":true,
                "validate":{
                },
                "model":"srok_pay_req",
                "width":12
            },
            {
                "type":"filebox",
                "label":"Проект договора купли-продажи",
                "required":true,
                "validate":{
                },
                "filebox":{
                    "type_id":"saleresaledogovor",
                    "multiple":false,
                    "nofile":"Договор не выбран",
                    "type":"type"

                },
                "model":"project_dog",
                "width":12
            }
        ]
    },
    {
        "seperator":"clear"
    }
]

This comment wasn’t rated yet 0
UFO just landed and posted this here
Чуток промахнетесь и вырежите на строку ниже/выше, а то и из середины — и привет, то, что было на одном уровне внезапно стало дочерним элементом. А JSON/XML вам сразу ошибку нарисует и правильно — нефиг резать не глядя.

Лучше уж ошибочный документ, чем синтаксически правильный, но с некорректными данными. Ошибка — это не разборщик такой-сякой-плохой-нехорошый, а вам знак — что-то не в порядке!
Total votes 1: ↑1 and ↓0 +1
UFO just landed and posted this here
Может останется, а может и не останется. Смотря какой кусок вырезать. Из любого формата можно вырезать кусок так, чтобы он остался wellformed. Контроль целостности передаваемых данных — это задача транспортного слоя, а не формата описания данных.
Total votes 4: ↑0 and ↓4 -4
Ну да, как-то так:

image

И так далее.
Total votes 4: ↑2 and ↓2 0
Такой конфиг и в XML будет выглядеть лучше
This comment wasn’t rated yet 0
Кстати, я тут допилил плагин к IDEA — теперь он и пробелы в конце строк делает видимыми, и на пробелы в начале оных ругается:

image
Total votes 1: ↑0 and ↓1 -1
По поводу s-expressions (Lisp) скажу — они, на мой взгляд,
бывают (не всегда!) удобнее HTML, XML, JSON и прочего, когда в документе
сравнительно мало текста. Т.е. для, скажем, представления
AST какого-либо языка или для задания layout'а (вёрстки, на которую
ложится CSS, без наполнения) HTML-страницы — очень хорошо.
Скобки — проблема надуманная, при активном
использовании обычно становятся незаметными
недели через две, если, конечно, редактор имеет правильный
autoindent и умеет подсвечивать парные скобки, а при использовании
средств типа paredit скобки неплохо помогают в редактировании.

Проблемы с s-expressions для представления данных / документов
следующие:
  • если документ преимущественно текстовый — получается некрасиво;
  • по сравнению с XML, не хватает namespaces. В случае CL есть
    packages, но их трудно назвать достаточнго гибкой заменой
    пространств имён для файлов данных;
  • tooling — XPath/XQuery/Relax NG/etc. В случае использования s-exprs
    для данных обходимся без этих полезняшек или строим велосипеды.

JSON по сравнению с s-exprs поддерживает унифицированное представление
dicts (objects), вместо которых в символьных выражениях используются
property lists, association lists либо какой-то кастомный синтаксис, специфичный
для языка (например, Clojure) или приложения (reader macros в CL).
По-моему, это не очень большая проблема, т.к. выразить ассоциативный
массив в виде s-exprs таки не сложно.
С другой стороны, JSON нет стандартных широко поддерживаемых
комментариев и это [очень плохо]. _comment-поля, на мой взгляд — извращение.
This comment wasn’t rated yet 0
>> выразить ассоциативный массив в виде s-exprs таки не сложно.
Есть же alists:
(users 
  (name . "Alice")
  (age . 20))
This comment wasn’t rated yet 0
Ну а как же
(users 
  (:name "Alice")
  (:age 20))
This comment wasn’t rated yet 0
А что это? (на руби смахивает, хотя знаю я его поверхностно)
This comment wasn’t rated yet 0
Так я же и написал про association lists выше по тексту. Можно ещё
plists (property lists):

(users (:name "Alice" :age 20))
This comment wasn’t rated yet 0
<занудство>
А разве не так:
(users 
  (user 
    (name . "Alice")
    (age . 20)))

или
(users 
  ((name . "Alice")
    (age . 20)))

?
Там же ещё может быть
(users 
  ((name . "Jane")
    (age . 21))
  ((name . "Alice")
    (age . 20)))

</занудство>
This comment wasn’t rated yet 0
Нужно сначала показывать продукт, а уже потом сравнивать его с чем-то.
Пришлось промотать в самый низ, чтобы увидеть как выглядит это чудо.

>JSON и YAML для создания иерархий предлагают «списки» и «мапки». Не все структуры данных хорошо представимы с их помощью.
>В Tree есть только один тип узлов
Одним типом узлов, конечно проще описать чем двумя /sarcasm.
А если серьезно, то «списки» это вложенные JSON документы. Какая тут может быть проблема с представлением не понятно.

>Как минимум необходима разноцветная подсветка лексем. Очень помогает — автоформатирование, автодополнение и подсветка ошибок
Использовать Tree без всего этого будет не мене неудобно

>Отсутствие необходимости в экранировании и разэкранировании спецсимволов
Только для \n, видимо?

>Почти все текстовые форматы не совместимы с бинарными данными.
Простите? Что вам мешает хранить «бинарные данные» в JSON?

>В Tree нет комментариев
Мило

>Табуляция
Мило

>Универсальноть
Так и не объяснили что это значит.

Кроме того, как я понимаю, в качестве ключа нельзя использовать blob или даже произвольные «строки», например, включающие символ '='?

В остальном, если без всяких «языков на его основе», то выглядит неплохо. По сути просто json без лишних скобок и кавычек, что радует.
Total votes 63: ↑62 and ↓1 +61
Нужно сначала показывать продукт, а уже потом сравнивать его с чем-то.

Если сразу показать, то типичная реакция: «ой, фу, я так не привык, не хочу дальше читать, пойду напишу в коментах, что люблю json» Тут же я хотел сначала обрисовать недостатки известных форматов, подчеркнув, что в предлагаемом решении их нет. Вы же испортили себе всё впечатление :-)

Одним типом узлов, конечно проще описать чем двумя /sarcasm.

Одним универсальным проще, чем двумя ограниченными. Пример с AST весьма показателен.

Использовать Tree без всего этого будет не мене неудобно

На самом деле менее. В нём сложно написать что-то нечитаемое или допустить синтаксическую ошибку.

Только для \n, видимо?

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

Простите? Что вам мешает хранить «бинарные данные» в JSON?

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

Так и не объяснили что это значит.

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

Кроме того, как я понимаю, в качестве ключа нельзя использовать blob или даже произвольные «строки», например, включающие символ '='?

В качестве имени — нельзя. В качестве ключа — можно. Например, аналогом такого JSON:

{
    "a+b=c" : [ 0 , true ],
    "\"foo\"" : [ 1.1 , false ]
}

Будет такой json.tree:

image
Total votes 36: ↑6 and ↓30 -24
Не смотря на заявления о простате синтаксиса, он все равно мне кажется непонятным. Возьмем ваш последний пример. Почему значения в списках представлены в виде имен, а не значений? Зачем явно указывать слово list, разве несколько значений не будут на это прямо указывать?
Total votes 14: ↑11 and ↓3 +8
Можно и в виде значений, только тогда придётся как-то различать типы примитивов. Указание чисел и констант в виде имён позволяет не указывать дополнительно эти типы.

Если не указывать list то в случае одного единственного элемента списка будет невозможно понять список там должен быть из одного элемента или же просто этот самый элемент.
Total votes 10: ↑3 and ↓7 -4
> тогда придётся как-то различать типы примитивов
Но здесь же они тоже не различаются. В синтаксисе нет ничего про типы. А где дополнительно нужно описывать тип? Как-то это не вяжется с парсером в 10 паттернов.
Total votes 11: ↑11 and ↓0 +11
Типы — это сущности другого уровня — языкового. Для разных языков нужны разные типы, так что не место им на уровне формата.

Типы можно указывать по разному. Например, для языка программирования, где набор типов может расширяться, они могут указываться так:

image

Но для JSON с фиксированным набором типов и простым способом их различения — это излишне.

Транслятор json.tree в json вполне может проанализировать узел-имя и понять, что там число или булево значение, или null, а вот узлы-значения воспринимать как строки.
Total votes 6: ↑2 and ↓4 -2
Вам не кажется, что наличие таких уровней ухудшает многие параметры, которые вы оценили на 5. Например, размер в сериализованном виде увеличивается от этих list и map, а человекопонятность и удобство редактирования уменьшается.
Total votes 10: ↑10 and ↓0 +10
Разумеется, JSON модель данных выраженная в Tree формате будет занимать больше места. Точно также Tree модель данных в формате JSON будет будет ещё больше. Это неизбежная цена отображения одного формата на другой.
Total votes 3: ↑0 and ↓3 -3
Только это не JSON модель данных, javascript. И такая модель данных (со строками, числами, логическими константами, массивами и объектами) существует во многих языках. А вот модели данных как в Tree я не встречал.
Total votes 2: ↑2 and ↓0 +2
JS модель данных пошире будет. И вы преувеличиваете универсальность этой модели. Во многих языках в массиве могут быть значения только одного типа. Во многих языках числа и строки представляются множеством разных типов. Во многих языках есть такие структуры как множества, ссылки, матрицы (которые ни разу не массивы массивов). И это я не говорю про многообразие кастомных типов.
This comment wasn’t rated yet 0
Типы можно различать, используя BSON. А он еще и бинарный формат, да, и конвертируется из обычного JSON.
Total votes 2: ↑2 and ↓0 +2
BSON — это всё же чисто бинарный формат. Его и руками в редакторе не поредактируешь и в логах не посмотришь. И вообще с ним работать можно лишь через специальные инструменты.
Total votes 3: ↑3 and ↓0 +3
Ну как это не поредактируешь? Hex-редактор и погнал. Ну а специальные инструменты — это слишком натянуто. Он очень строго типизирован, есть куча готовых реализаций, а своя реализация «на коленке», пишется за пару часов, а то и меньше. С tree тоже придется использовать «специальные инструменты».
UPD: А просматривать можно соответствующий JSON документ.
Total votes 2: ↑1 and ↓1 0
HEX редактор — весьма специальный инструмент.

Для Tree и простейшего текстового редактора хватит в большинстве случаев.

Я не сомневаюсь, что можно извертнуться и хоть на ASM-е писать. Но зачем?
Total votes 6: ↑1 and ↓5 -4
>Если сразу показать
А если не показать, то человеку придется проматывать вниз, чтобы понять о чем вообще речь.
Либо уйти, не читая.

>Тут же я хотел сначала обрисовать недостатки известных форматов, подчеркнув, что в предлагаемом решении их нет. Вы же испортили себе всё впечатление :-)
Нет, не испортил. Таблицу я прочитал до того, как промотал вниз.
Почти в самый конец, потому как в пределах 4 (!!!) экранов не увидел ниодного примера этго чуда,
которое получило оценку 5 почти по всем пунктам

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

>На самом деле менее.
Вовсе нет. Что там пелена, что здесь.

>В нём сложно написать что-то нечитаемое или допустить синтаксическую ошибку.
Видимо из-за проблем с выразительным средствами.
Как же проблема с = перед значением, которую описала sferrka?
А хранение ключей, которую описал я выше?
А пробелы в ключе, про которые говорил PHmaster ниже?

> форматах экранировать приходится гораздо большее число символов.
У вас перенос строки, если верить примеру выше, просто заменяется на '=', что не сильно лучше \n
Поэтому количество символов, которые нужно экранировать у вас вовсе не меньше, если не больше из-за '='

>Я так понимаю вы намекаете на base64, base62
Нет, не намекаю. Строка в JSON является строкой условно, ничто не мешает вам хранить в ней blob
Total votes 16: ↑16 and ↓0 +16
UFO just landed and posted this here
Строка в JSON является строкой условно, ничто не мешает вам хранить в ней blob
Ничего условного в ней нет, в спеке вполне однозначно сказано, что это строка из символов Unicode, причём слеши и кавычки нужно ещё и обязательно экранировать. Так что блоб там хранить можно только предварительно конвертировав его в base64 или что-то подобное.
Total votes 6: ↑6 and ↓0 +6
map — неупорядоченный (ограничение по упорядоченности) ассоциативный (ограничение по уникальности ключей) массив.
list — упорядоченный индексированный (ограничение на индексы — строго последовательно, начиная с 0) массив.

Напомню, что в JSON нужно экранировать:
* перевод строки
* кавычки
* обратный слеш
* пачку управляющих символов

В Tree спецсимвол не допустимый в значениях только один — перевод строки.
This comment wasn’t rated yet 0
Извините, но эти «ограничения» служат для удобства использования и никак не виляют на выразительность.

В то же время в Tree этого всего нет, а значит придется как-то это где-то специфицировать (как отличить сортированный от несортированного?). Введете TSD и Tree Schema?
Это не простота, это бедность.

> пачку управляющих символов
Эти подлежат «экранированию» по причине того, что просто так с клавиатуры их не ввести.
Остальные, действительно, ограничения, накладываемые форматом, здесь вы правы.

Идея использовать практически голые AST как формат хранения данных мне нравится.
Но то, что вы показываете — сильно недоработанная концепция.
И, пожалуй, его главная проблема — амбициозность разработчика, которая формирует соответствующее отношение к самому проекту.
Total votes 4: ↑4 and ↓0 +4
Вы зря недооцениваете стек XML технологий. Их разрабатывали куда более умные люди, чем вы или я. И идея разделения языка и формата — очень здравая, потому как позволяет иметь в рамках одного формата тысячи языков, для которых не надо писать отдельные парсеры.
Total votes 2: ↑1 and ↓1 0
Почему вы решили, что я его недооцениваю? XML хорошо показал себя в свое время, но сейчас ему находят более эффективные альтернативы. В IT все стремится к упрощению. Почему JSON стал так популярен? Потому, что он прост: не нужна никакая схема, не нужно ничего декларировать — просто используй.

>И идея разделения языка и формата — очень здравая
Разве я это отрицал? Я говорил лишь о том, что Tree не решает тех проблем, которые вы нашли в JSON. Во всяком случае, без использования схемы. А если использовать схему, то ваш формат усложняется. Причем это усложнение сразу нивелирует все его плюсы:
1. Он становится слишком неудобным для использования человеком
2. Он начинает конкурировать с BSON (так же «удобно» редактировать руками) и Protobuffers, где «сливает» вообще по всем параметрам.
This comment wasn’t rated yet 0
а) А при чём тут схема?
б) В чём проблема запилить схему? Я вам удочку даю, а вы от меня рыбы требуете.

1. Вы попробуйте сначала, а потом уже говорите о неудобности.
2. Вполне себе разумный компромис между компактностью и читаемостью. Всякие BSON и прочие бинарники имеют сильно ограниченное применение. В то время как адекватных применений Tree — гораздо больше.
Total votes 2: ↑0 and ↓2 -2
>А при чём тут схема?
При том, что ей вы описываете что есть что. Если в языке нет необходимого минимума, то приходится описывать вообще все.

>В чём проблема запилить схему?
Только в том, что это нужно сделать. И чем раньше это «нужно» появится, тем хуже.

>Вы попробуйте сначала, а потом уже говорите о неудобности.
Пробовал уже. Как только вы для этого предложили нечто похожее на формы Бэкуса-Наура.
В связи с чем, кстати, появился вопрос: как вам идея использовать вместо вашего решения bison? Он несравнимо более гибок, да и реализация уже есть. Получаем сразу и описание формата и парсеры под все популярные языки.

>Всякие BSON и прочие бинарники имеют сильно ограниченное применение
Тем не менее в бинарной области они работать будут лучше чем та спецификация Tree, что вы показываете. А в «небинарной» есть JSON (который, кстати, без проблем конвертируется в BSON).

> В то время как адекватных применений Tree — гораздо больше.
Попытка создать инструмент, который делает все, приводит к тому, что он делает все в равной степени плохо. В том смысле, что специализированный инструмент, справился бы с конкретной задачей значительно лучше.
This comment wasn’t rated yet 0
Я уже устал повторять, что Tree — это формат, а не язык. Примеры языков в статье есть и для ник вполне чётко определено что есть что.

Идея-то хорошая, но боюсь не найду в ближайшее время времени ковыряться с bison.

Специализированный инструмент справится лучше, только на изучение каждого инструмента нужно время и таскать их все с собой не очень удобно. Плюс ещё и стыкуются они друг с другом плохо.
This comment wasn’t rated yet 0
>Я уже устал повторять, что Tree — это формат, а не язык
Извините, что утомил вас. Не волнуйтесь, я помню, и это очевидно из его сравнение с JSON, XML, YAML.

Перефразирую: если формат не предоставляет достаточно конструкций сам по себе, то их придется где-то описывать. Пример с массивами: да, в JSON они нумеруются от 0 и только так. Но в Tree такого нет вообще. Нигде не написано, являются ли дочерние узлы упорядоченными или нет и какие им даются индексы. А это значит, что придется вводить новую спецификацию (схему), для того, чтобы это описать.

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

>только на изучение каждого инструмента нужно время
Даже если описать все эти языки в рамках одного формата, это не делает изучение более простым

>таскать их все с собой не очень удобно
Как это отличается от все-в-одном?

>Плюс ещё и стыкуются они друг с другом плохо
Весьма спорное утверждение. Все зависит от конкретного случая.

Напомню, что сама идея, мне нравится. Мне не нравится её текущая реализация и тот факт, что эту реализацию пытаются выдать за «убийцу» вышеперечисленных форматов.
Total votes 2: ↑2 and ↓0 +2
Вместо того, чтобы хардкодить некоторые типы (например, строки, числа, булевы), а с остальными (например, даты, телефонные номера, гео-координаты) ковыряйтесь как хотите, на мой взгляд лучше дать инструмент объявления своих типов и не навязывать какой-либо набор, «которого хватит всем». Посмотрите на описание языка xml.tree — оно же предельно простое, хоть и не формализованное с помощью каких-либо схем.

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

А вы зря недооцениваете универсальные инструменты. Возьмём вот например нож. Есть нож для рыбы, для мяса, для сыра, для хлеба, для разделки, для удаления костей, для раскрытия раковин устриц, тысячи их. Каждый из них предельно хорош в своей области. А тут прихожу я и говорю, что вот этими двумя типами ножей можно делать всё что угодно. Пусть и не будет того повышенного комфорта, как при использовании устричного ножа. Зато ножи будут взаимозаменяемы, требовать мало места, их не придётся менять каждые 5 минут, подбирая нужный для своего типа нарезаемого продукта.
This comment wasn’t rated yet 0
>Возьмём вот например нож
приятно видеть человека, видящего перспективность метафорического компьютера :)

данные: дождевая, вода из-под крана, столовая питьевая, минеральная, газированная сладкая, дистиллированная, вода из лужи, морская, речная, фильтрованная…

дистиллированная вода — бинарные данные
вода из-под крана — данные, вводимые пользователем

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

при смешении воды и средства получаем данные в формате

инструмент: щетка для обуви, зубная щетка, половая тряпка, веник, губка для мытья посуды, скребок для мытья посуды, расческа, щетка для пылесоса, пемза, полотенце…

То есть, вы утверждаете, что ваш формат — это мыло.
А ваши оппоненты, что не хотят употреблять молоко в формате сыворотка, когда есть еще масло, сметана, творог, сливки.

почему бы не провести опрос.
This comment wasn’t rated yet 0
Ну вы уж совсем мой тезис до абсурда довели :-)
Tree тогда уж, это не мыло, а органическая химия, где и преимущественно из одних только атомов углерода собирают самые разнообразные вещества.
This comment wasn’t rated yet 0
Почему JSON стал так популярен? Потому, что он прост: не нужна никакая схема, не нужно ничего декларировать — просто используй.

На самом деле, не поэтому, а потому, что на веб-клиенте (в браузере) его парсинг был существенно проще и дешевле, чем парсинг xml.

(xml тоже можно использовать без схемы и деклараций, если что)
This comment wasn’t rated yet 0
или всё же потому, что это серилизатор для ЯваСкрипта? )))
This comment wasn’t rated yet 0
Это не «сериализатор для яваскрипта», это сериализатор, который в некий момент решили использовать в JavaScript как самый простой (потому что чтобы разобрать этот формат, если без учета безопасности, достаточно сделать eval)
This comment wasn’t rated yet 0
ок, делали не столько для ЯваСкрипта.
Но получил популярность потому, что очень прост для ЯваСкрипта.
Тот же XML надо вначале распарсить в ДОМ, а уж потом из него вытаскивать данные для скриптов, а с использованием жсона — всё уже распакованно.
This comment wasn’t rated yet 0
А теперь перечитайте, что написано в комменте, на который вы отвечаете:
потому, что на веб-клиенте (в браузере) его парсинг был существенно проще и дешевле, чем парсинг xml.
This comment wasn’t rated yet 0
>вначале распарсить в ДОМ
SAX
This comment wasn’t rated yet 0
SAX на javascript?
Но получил популярность потому, что очень прост для ЯваСкрипта.
This comment wasn’t rated yet 0
То есть DOM на js вас не смущает?

>Но получил популярность потому, что очень прост для ЯваСкрипта.
К чему вы это?
This comment wasn’t rated yet 0
Если вы клоните к тому, что страница суть тоже xml, то что это меняет? Это запрещает использовать sax-парсеры?
This comment wasn’t rated yet 0
По распакованному JSON всё-равно придётся пройтись и преобразовать во внутреннее представление (объектики там всякие, перекрёстные ссылки и тд). Так что особой разницы нет по какому дереву бегать — json, tree или xml.
Total votes 1: ↑1 and ↓0 +1
Проблема в том, что распакованный JSON — это объект, который можно напрямую отображать на модель. На выходе же парсера tree — дерево узлов, которые требуется обрабатывать дополнительно.
This comment wasn’t rated yet 0
Беспредметный спор. Покажите как вы отобразите JSON модель данных на модель предметной области «на прямую». А я сделаю аналогичное отображение из Tree. А потом сравним у кого сколько «дополнительного» кода получилось.
This comment wasn’t rated yet 0
koko.mapping.fromTree(responceTree, viewModel);
Total votes 2: ↑1 and ↓1 0
Приведите библиотеку. А то по запросу «koko.mapping.fromTree» гуглится какая-то фигня, а без библиотеки сравнить количество «дополнительного» кода не получается.

This comment wasn’t rated yet 0
А что толку? Реализация будет точно такая же — через паттерн Visitor.
Total votes 1: ↑0 and ↓1 -1
Какой Visitor в гомогенном дереве, о чем вы?
Total votes 1: ↑1 and ↓0 +1
Где вы увидели гомогенное дерево?
Total votes 1: ↑0 and ↓1 -1
Ваш Tree — это гомогенное дерево (это то его достоинство, которым вы так гордитесь)
Total votes 2: ↑2 and ↓0 +2
Не совсем, имена-то узлов разные, а именно они определяют как транслировать абстрактное дерево в объекты приложения.
Total votes 1: ↑0 and ↓1 -1
Угу. Вот Visitor подключится (если надо) к делу после трансляции абстрактного дерева в объекты приложения, а не до — а на этой фазе уже не важно, из чего эти объекты смапили.
Total votes 2: ↑2 and ↓0 +2
Вообще-то мы тут обсуждали именно трансформацию из дерева данных в дерево объектов.
Total votes 2: ↑0 and ↓2 -2
… а на этой фазе visitor не используется, потому что дерево данных в вашем случае полностью гомогенно.
Total votes 2: ↑2 and ↓0 +2
>xml тоже можно использовать без схемы и деклараций
Не спорю, можно. Но несколько сложнее, взять хотя бы проблему выбора между атрибутом и дочерним элементом.

Хотя, пожалуй, вы правы.
This comment wasn’t rated yet 0
Если для вас это по каким-то причинам проблема — просто всегда используйте дочерние элементы.
This comment wasn’t rated yet 0
А можно пример того как ваш формат дружит с бинарными данными.
Total votes 10: ↑10 and ↓0 +10
Пример программного кода или пример файла?
This comment wasn’t rated yet 0
Пример файла конечно, зачем мне код.
This comment wasn’t rated yet 0
Отлично, а что будет если в бинарных данных один из символов будет \n?
This comment wasn’t rated yet 0
Очевидно, вместо одного узла-значения будет несколько.
This comment wasn’t rated yet 0
Это если за \n последует такое же количество табов (что мало вероятно), а если попутно ещё и = встретится так это сделает всё ещё хуже. Что то не вижу я бинарной безопасности в вашем формате.
Total votes 3: ↑0 and ↓3 -3
То есть мне придётся самому в коде разбивать данные на блоки? А чем это лучше экранирования " и \ в json?
Total votes 2: ↑2 and ↓0 +2
Зачем самому, если это можно делать автоматически?
This comment wasn’t rated yet 0
Разумеется. Вопрос в стоимости этой операции и человекочитаемости.
This comment wasn’t rated yet 0
Стоимость этой операции в обоих случаях O(n). В чем вопрос?
This comment wasn’t rated yet 0
Вопрос в размере константы.
This comment wasn’t rated yet 0
Во-первых, не в размере константы, а в отношении размеров констант. И вы не сможете адекватно посчитать k для JSON-кодировщика, потому что его реализация очень сильно зависит от возможностей платформы и изворотливости программиста.

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

Нотацию O(f(n)) для того и придумали, чтобы не размениваться на такие мелочи. Для разумной реализации на разумном языке стоимость кодирования и декодирования строкового примитива что в Tree, что в JSON будет сопоставима, и отличия будут вноситься больше на уровне «читаем из буфера vs читаем из потока».
Total votes 1: ↑1 and ↓0 +1
В JSON многие символы требуют экранирования, что вынуждает работать с байтами индивидуально. Tree же позволяет копировать данные пачками, что гораздо быстрее.
This comment wasn’t rated yet 0
Каким образом вы гарантируете, что в «пачке» нет переводов строки, если не пройдетесь по каждому байту индивидуально?
Total votes 1: ↑1 and ↓0 +1
Если пачка прочитана из Tree файла, или через readln(), то переводов строк там точно нет. Если же у нас дикие данные, то при импорте в дерево необходимо пробежаться по ним в поисках переводов строк. Поиск символа в строке — это куда более быстрая операция.
Total votes 1: ↑0 and ↓1 -1
При импорте в дерево вам нужно не просто «пробежаться… в поисках переводов строк», а точно так же, как и с экранированием, при каждом встреченном символе перевода строки добавить дополнительные символы экранизации: в вашем случае это табы и символ "=", и добавляются они не перед экранируемым символом, а после него. Причем, заметьте, вы не можете экранировать данные и затем вставить их в любое произвольное место в ваше дерево, как это возможно с тем же JSON, так как количество вставляемых в Tree табов после символа перевода строки зависит от контекста, т.е. конкретного места, для которого вы экранируете, а именно — от уровня вложенности объектов в этом месте. А это, в свою очередь, означает, что вы не можете взять некий объект, сериализировать его в Tree-представление и потом использовать сериализованный кусок текста в произвольном месте Tree-файла (или любого другого потока вывода), как это возможно с тем же json и XML. То есть, для сериализации объектов нужно заранее знать всю структуру сериализуемого дерева этих объектов целиком, и при сериализации обходить эту структуру в строгом порядке: от корня к листьям.
Total votes 3: ↑3 and ↓0 +3
При импорте в дерево не происходит экранирования — только составление списка диапазонов.

static Values
( T = string )
( T value , Tree[] childs = [] , string uri = "" ) 
{
	auto chunks = ( cast(string) value ).split( '\n' );
	auto nodes = chunks.map!( chunk =>
		new Tree( "" , chunk , [] , uri )
	);
	return nodes.array;
}

Функция split не копирует данные, если что, а возвращает так называемые срезы исходного массива.

При сериализации они просто сливаются в выходной поток как есть, без какой-либо обработки.

} else if( this._value.length || prefix.length ) {
	output.write( "=" ~ this._value ~ "\n" );
}
Total votes 1: ↑0 and ↓1 -1
В таком слчае так можно сказать про любое другое экранирование, вот например простейшие экранирование " и \
static Values
( T = string )
( T value , Tree[] childs = [] , string uri = "" ) 
{
	auto chunks = ( cast(string) value ).split( "\"\\" );
	auto nodes = chunks.map!( chunk =>
		new Tree( "" , chunk , [] , uri )
	);
	return nodes.array;
}

и потом
} else if( this._value.length || prefix.length ) {
	output.write( "\\" ~ this._value);
}

Имеются ли тут кардинальные различия? Не думаю.
Total votes 1: ↑1 and ↓0 +1
У вас при сплите данные теряются. Если разрезать по более чем одному символу, то потом не понятно по какому символу собирать.
This comment wasn’t rated yet 0
ну так всегда можно свой split написать который не будет обрезать символы, я просто хотел показать, что по сути экранирование ничем не отличается от вашего разделения.
Total votes 1: ↑1 and ↓0 +1
Экранирование в JSON отличается. Да, можно придумать экранирование, где перед кавычкой и бэкслешем ставится бэкслеш и всё, но чем это:
{ "lalala" :
    "foo\"
bar\\"
}

Лучше этого:
lalala
    =foo"
    =bar\

?
This comment wasn’t rated yet 0
Экранирование в JSON отличается.

ничем кроме символов, и того факта что спец символы нужно добавлять до а не после
Лучше хз, а чем хуже? Между экранированием символом \ и экранированием строкой неопределённой длинны, я бы честно говоря выбрал первый вариант.
This comment wasn’t rated yet 0
Тем, что исходный символ удаляется.
This comment wasn’t rated yet 0
Где же он удаляется? Знак переноса у вас всё также остаётся.
This comment wasn’t rated yet 0
В JSON удаляется.
"\n" — тут нет символа c с кодом 13
This comment wasn’t rated yet 0
Не позволяет. Вам нужно знать, где в данных \n, поэтому у вас не выйдет «просто прочитать» или «просто записать». Это все те же самые O(n) (а когда вы говорите про «прочитано через readln» — то для вас эта сложность просто спрятана внутрь вызываемой функции; но это не значит, что ее нет).

Так что утверждение про сопоставимые сложности алгоритмов остается неопровергнутым.
Total votes 1: ↑1 and ↓0 +1
Я с ним и не спорил. Речь о константах. Вы по ссылке ходили? Разница на порядок.
This comment wasn’t rated yet 0
Ходил, а толку? Эта ссылка не применима в вашем случае, потому что она относится к копированию целых массивов в памяти.

А у вас что? У вас
(а) копировать надо не весь массив, а до определенной позиции
(б) вы, на самом деле, вообще ничего не копируете, а либо читаете, либо пишете с/на I/O-устройство (сеть, диск и так далее), и стоимость самого I/O выше, чем стоимость всех операций сравнения, которые надо сделать (а больше отличий-то и нет)
This comment wasn’t rated yet 0
Вы не на палец смотрите, а туда, куда я показываю :-)
Это иллюстрация, что обработка сразу пачки данных куда эффективней побайтовой обработки.

This comment wasn’t rated yet 0
Эффективнее, конечно. Но для бинарно-небезопасных форматов это в чистом виде невозможно в любом случае. Поэтому все равно в том или ином виде будет обработка экранирующих последовательностей — которая, как уже говорилось, сводится к O(n) (с чем вы, впрочем, уже согласились). Дальше вопрос k. Вы утверждаете, что для JSON, в котором экранируемых символов больше, k существенно больше, чем для tree. А я утверждаю, что в типовых применениях эта разница не будет заметна на фоне стоимости основной операции (i/o).

Внимание, вопрос: будем на уровне логики обсуждать, или уже пора тесты писать?
This comment wasn’t rated yet 0
i/o между процессами заключается именно что в копировании памяти.
Total votes 1: ↑0 and ↓1 -1
Внезапно, tree предлагается для межпроцессной комуникации? А зачем? Там чистый бинарный формат намного эффективнее.

Я всегда считал, что основные применения таких форматов — это прочитай/запиши на диск, в БД или в сеть.
Total votes 3: ↑3 and ↓0 +3
Вы правда думаете, что unix pipes работает через копирование памяти? Странно, а я думал, что оно сделано через потоки (точнее, через форвард-онли файл-дескрипторы).
Total votes 1: ↑1 and ↓0 +1
Я правда думаю, что дерево сериализуется в память и парсится из неё же, без обращения к диску.
This comment wasn’t rated yet 0
Во-первых, далеко не факт, что это быстрее. Во-вторых, когда вы сериализуете и парсите дерево в памяти, у вас парсинг отдельно, копирование — отдельно, и поэтому оно в обоих алгоритмах является константой (благодаря чему радостно игнорируется O-нотацией). Ну и в-третьих, при чем тут диск, мы вроде как о unix pipes говорим?

Ладно, чтобы не заниматься дурацкими вопросами, напишите, пожалуйста, в псевдокоде, как, по-вашему, будет происходить процесс сериализации — передачи через unix pipe — десериализации данных, с указанием того, где именно копируется память.
This comment wasn’t rated yet 0
В случае tree:
При парсинге копировать ничего не нужно.
При сериализации просто копируются участки памяти в выходной буфер.

В случае json:
При парсинге происходит декодирование, для чего выделяется отдельная память.
При сериализации происходит кодирование и запись в буфер.
This comment wasn’t rated yet 0
Не так быстро.

Во-первых, почему ничего не надо копировать при парсинге tree?
Во-вторых, где пайп-то?
В-третьих, откуда вы берете участки памяти для копирования в выходной буфер? Вот у вас на входе строка, потенциально содержащая \n — откуда вы знаете, какие ее куски надо копировать?
Total votes 1: ↑1 and ↓0 +1
1. А зачем?
2. За кулисами. Пайплайном управляет операционка.
3. Из входного буфера и беру. Как бы tree-парсер строит дерево по входящему потоку — отсюда и знаю, где что.
This comment wasn’t rated yet 0
А зачем?

Ну то есть данные из входного потока попадают в структуру в памяти чудом?

За кулисами. Пайплайном управляет операционка.

Ага, то есть фраза «i/o между процессами заключается именно что в копировании памяти.» уже ни на чем не основана?

Из входного буфера и беру

Какого входного буфера?

Как бы tree-парсер строит дерево по входящему потоку — отсюда и знаю, где что.

Какой парсер, если речь идет о сериализации? Это, на минуточку, обратная операция. Речь идет о том, что у вас в приложении была прикладная информация, строка, которую кто-то хочет как данные записать в ваш формат. Вот это надо сериализовать. В какой момент (и с какой стоимостью) будут убраны \n?
Total votes 1: ↑1 and ↓0 +1
А что они там забыли? Пусть лежат себе в своём потоке.

Если у вас есть что возразить — дерзайте. Давайте не будем с умным видом загадывать друг другу загадки.

В который пришли данные. Что не понятно?

В момент создания соответствующей ветки дерева будет пробежка по данным в поисках переводов строк. Убирать их нет никакого смысла.
Total votes 1: ↑0 and ↓1 -1
Да я уже возразил (указав, что unix pipe — это не копирование памяти), только вы это игнорируете.

Что ж, вернемся к этому примеру еще раз. Вот у вас есть входной поток (именно поток, то есть либо cin, либо сетевое соединение, то есть читать вы его можете только один раз и только вперед; это как раз ситуация чтения из unix pipe), и вы в нем стоите на позиции «начало значения». Это значение нужно прочитать в память. Пожалуйста, покажите, как именно вы на этой операции получите разницу в скорости парсинга на порядок по сравнению с аналогичной операцией для JSON.

(С записью будем разбираться следующим этапом)
This comment wasn’t rated yet 0
А что же это? Прямая запись в адресное пространство другого процесса?

This comment wasn’t rated yet 0
Для программы это файловый дескриптор, с соответствующим набором операций. Что у него там внутри происходит, вы уже не знаете.
This comment wasn’t rated yet 0
Может поделитесь этим сакральным знанием как данные передаются между процессами без копирования?
This comment wasn’t rated yet 0
(Ну понятно, показывать, где у вас там разница на порядок, вы не хотите — или не можете, поэтому цепляетесь за удобную фразу.)

Так вот, где-то внутри unix pipe память, конечно, копируется. В том же значении, в котором запись элемента в массив — копирование значения этого элемента. Но важно то, что там внутри есть не только копирование, но еще и управление состоянием потока, buffer rotation и другие смешные вещи, поэтому давать ссылку на memcpy, а потом распространять описанную там производительность на unix pipe не надо.
This comment wasn’t rated yet 0
Работа пайплайна не зависит от того что за данные мы передаём. Но чтобы передать данные в пайплайн нужно подготовить их в том виде, в котором они должны в него идти.

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

В случае Tree данные не надо как либо экранировать, так что достаточно сказать «отправь этот кусок памяти в буфер, потом этот, а затем тот».
Total votes 1: ↑0 and ↓1 -1
В случае JSON мы должны выделить некоторый буфер, сериализовать в него дерево и сказать системе «отправь ка этот буфер в выходной поток».

Это еще зачем? Что мешает взять JSON и сразу сериализовать его в выходной поток?

так что достаточно сказать «отправь этот кусок памяти в буфер, потом этот, а затем тот».

А управляющие последовательности сами собой возьмутся? Ну и да, в случае Tree бремя экранирования лежит на пользовательском коде (потому что Tree не поддерживает значения, содержащие \n).

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

This comment wasn’t rated yet 0
Потокобезопасность мешает.

Вы не фантазируйте, а попробуйте разобраться в формате. А лучше сделайте свою реализацию и сразу всё поймёте.
Total votes 2: ↑0 and ↓2 -2
Потокобезопасность мешает.

Ээээ, это каким образом? (Почему-то реализациям в .net не мешает)

Вы не фантазируйте, а попробуйте разобраться в формате. А лучше сделайте свою реализацию и сразу всё поймёте.

Я не фантазирую, я уже набросал псевдокод реализации, и именно поэтому и говорю, что разница в скорости чтения в обоих случаях пренебрежима (и ни в одном случае нет необходимости в копировании буфера памяти целиком). Так что теперь мне интересен ваш псевдокод, на основании которого вы делаете вывод о разнице в скорости на порядок.
Total votes 1: ↑1 and ↓0 +1
Так покажите же свой псевдокод.
This comment wasn’t rated yet 0
(Srsly?)

Мы исходим из положения, что входной поток стоит ровно на начале читаемой строки.

Tree:
buf = "";
while(true)
{
  c = ReadNextChar();
  switch(c)
  {
    case EOF:
    case '\n':
      return buf;
    default:
      buf += c;
  }
}


Стоимость строго 4n (полагая операции перехода, чтения, выбора и присвоения идентичными по стоимости).

JSON:

buf = "";
while(true)
{
  c = ReadNextChar();
  switch(c)
  {
    case EOF:
      throw;
    case '"':
      return buf;
    case '\\':
      switch(ReadNextChar())
      {
        case 'u'
          buf += MakeChar(ReadNextChar(), ReadNextChar(), ReadNextChar(), ReadNextChar())
        case 'n':
          buf += '\n';
        //raise, rinse, repeat
        default:
          throw;
      }
    default:
      buf += c;
  }
}


Стоимость в пограничном случае m (ни одной эскейп-последовательности): 4n.
Стоимость в пограничном случае w (все символы — двухсимвольный эскейп): 3n
Стоимость в пограничном случае u (все символы — юникод-эскейп): 2.5n

Обобщенная формула стоимости: 4m + 6w + 15u, при n = m + 2w + 6u

BTW, решив простенькую систему неравенств, можно внезапно выяснить, что чтение JSON по такому алгоритму никогда не медленнее чтения tree.

PS Кстати, у меня тут из грамматики создалось ощущение, что tree не ждет \n в конце каждого значения, а это значит, что можно очень легко сломать файл, просто разорвав передачу, и способов это провалидировать не существует. Это нехорошо.
Total votes 1: ↑1 and ↓0 +1
Да, кривая грамматика. Там и символ перевода строки не тем кодом был задан.

Какой-то псевдокод у вас совсем оторванный от реальности.

Tree:
1. запоминаем начальное и конечное смещение = 0
2. читаем байты в цикле
2.1. если байт равен 0A, то создаём узел дерева, который хранит начальное и конечное смещение
2.2. иначе увеличиваем конечное смещение
3. формируем префикс
4. пробегаемся по списку узлов
4.1. говорим системе скопировать префикс в системный буфер
4.2. говорим системе скопировать данные по смещениям из узла в системный буфер

JSON:
1. выделить памяти с запасом под временный буфер
2. в цикле читаем байты
2.1. если спецсимвол, то смотрим какой и пишем в буфер соответствующий набор байт
2.2. иначе копируем байт как есть
2.3. если буфер вдруг закончился, то говорим системе скопировать его в системный буфер
2.3.1 начинаем заполнять его заново

Итого, отличие в следующем:
JSON: побайтово фактически копируем все данные во временный буфер, чем больше буфер, тем меньше системных вызовов
Tree: побайтово читаем, но создаём сравнительно небольшую структуру пропорциональную числу переводов строк, число системных вызовов в 2 раза больше числа переводов строк
This comment wasn’t rated yet 0
Какой-то псевдокод у вас совсем оторванный от реальности.

Он (а) гарантировано работающий и (б) выполняющий поставленную задачу

(Вы, все-таки, пишете, пожалуйста, псевдокод, а не текст, а то слишком вопросов много.)

Tree:
1. запоминаем начальное и конечное смещение = 0
2. читаем байты в цикле

Читаем откуда и куда? Что является верхней границей цикла?

2.1. если байт равен 0A, то создаём узел дерева, который хранит начальное и конечное смещение
2.2. иначе увеличиваем конечное смещение
3. формируем префикс
4. пробегаемся по списку узлов
4.1. говорим системе скопировать префикс в системный буфер
4.2. говорим системе скопировать данные по смещениям из узла в системный буфер

Что такое «системный буфер»? Скопировать данные откуда?

Tree: побайтово читаем, но создаём сравнительно небольшую структуру пропорциональную числу переводов строк, число системных вызовов в 2 раза больше числа переводов строк

У вас с переводом строки значение заканчивается, задача выполнена. Откуда вдруг следующие действия?

Я еще раз повторяю задачу: надо прочитать из входящего потока (т.е., forward-only источника данных) строковое значения, исходя из того, что сейчас положение потока — начало этого значения (в tree — после =, в JSON — после "). Если угодно, рассматривайте эту задачу как функцию, у которой на входе правильно спозиционированный поток, а на выходе — прочитанное значение (положение в потоке, понятное дело, меняется).

Если по каким-то причинам вы считаете эту задачу некорректной и никогда не возникающей, то объясните мне, что делает вот этот код (честное слово, я лучше даже не буду пытаться посчитать его стоимость по памяти, с учетом того, что строки в D неизменны):

if( input[0] == '=' ) {
  auto value = input.takeUntil( "\n" )[ 1 .. $ ];
  auto next = new Tree( "" , value , [] , baseUri , row , col );
  ...
}

...

string takeUntil( ref string input , string symbols ) {
  auto res = "";
  while( input.length ) {
    auto symbol = input[0];
    if( symbols.indexOf( symbol ) == -1 ) {
      res ~= symbol;
      input = input[ 1 .. $ ];
    } else {
      break;
    }
  }
  return res;
}
Total votes 1: ↑1 and ↓0 +1
In most Unix-like systems, all processes of a pipeline are started at the same time, with their streams appropriately connected, and managed by the scheduler together with all other processes running on the machine. An important aspect of this, setting Unix pipes apart from other pipe implementations, is the concept of buffering: for example a sending program may produce 5000 bytes per second, and a receiving program may only be able to accept 100 bytes per second, but no data is lost. Instead, the output of the sending program is held in a queue. When the receiving program is ready to read data, the operating system sends its data from the queue, then removes that data from the queue. If the queue buffer fills up, the sending program is suspended (blocked) until the receiving program has had a chance to read some data and make room in the buffer. In Linux, the size of the buffer is 65536 bytes.
en.wikipedia.org/wiki/Pipeline_(Unix)#Implementation

У вас условия меняются как перчатки. Входящий поток в каком формате?

Именно благодаря тому, что строки в D неизменны и есть GC, срезы этих строк занимают считанные байты.
This comment wasn’t rated yet 0
У вас условия меняются как перчатки. Входящий поток в каком формате?

Входящий поток в виде последовательности символов (чтобы не размениваться на детали реализации utf-8). И нет, эти условия как не менялись, так и не меняются.

Именно благодаря тому, что строки в D неизменны и есть GC, срезы этих строк занимают считанные байты.

Срезы-то да. А суммы?
This comment wasn’t rated yet 0
Тогда при чём тут пассаж про = и "?

Не знаю, умеет ли D объединять последовательно идущие срезы. Но даже если нет, то не проблема конкатенацию срезов заменить на пересоздание среза.
This comment wasn’t rated yet 0
Тогда при чём тут пассаж про = и "?

К положению в потоке.

Я так понимаю, что вы будете придираться к чему угодно, лишь бы не показывать свой псевдокод?
Total votes 1: ↑1 and ↓0 +1
Ага, я так и знал, что вашего псевдокода в итоге не будет. Ок, тезис про более высокую производительность tree на чтении значений считаем опровергнутым.
This comment wasn’t rated yet 0
import std.stdio;
import std.file;
import jin.tree;
import std.json;
import std.datetime;

void testJSON() {
	auto JSONString = cast(string) read( "./source/jin/tree/formats/sample.min.json" );
	std.file.write( "res.json" , parseJSON( JSONString ).toString() );
}
void testTree() {
	auto TreeString = cast(string) read( "./source/jin/tree/formats/sample.tree" );
	std.file.write( "res.tree" , Tree.parse( TreeString ).toString() );
}

int main(string[] argv)
{
	auto result = comparingBenchmark!( testJSON, testTree, 200 );
	writeln( result.point );
	writeln( result );

	result = comparingBenchmark!( testTree, testJSON, 200 );
	writeln( result.point );
	writeln( result );
	return 0;
}

Результат: 

1.42267
ComparingBenchmarkResult(TickDuration(5512316), TickDuration(3874621))
0.750915
ComparingBenchmarkResult(TickDuration(3867075), TickDuration(5149818))

Tree примерно в полтора раза быстрее JSON. При этом:
* в тесте есть чтение с диска и запись на него (впрочем, ОС всё-равно это дело кэширует)
* данные не содержат символов, которые необходимо в JSON экранировать
* JSON читается и сериализется в минифицированном виде
Total votes 2: ↑1 and ↓1 0
на чтении значений

С тем, что ваш формат в общем читается быстрее, я не спорил.
This comment wasn’t rated yet 0
А чем чтение значений отличается от чтения всего остального?
This comment wasn’t rated yet 0
Логикой. Дискуссия была именно про значения и влияние экранирования в них на скорость обработки.
This comment wasn’t rated yet 0
Кстати, безотносительно того, как работают unix pipes — вы правда думаете, что это самый частый сценарий использования вашего формата? А если нет, то что делать с типовыми применениями, где все-таки есть ощутимые потери на I/O?
Total votes 1: ↑1 and ↓0 +1
Очевидно, в этом случае разница в скорости будет не столь значительна. Но уменьшение нагрузки на процессор тем не менее будет.
This comment wasn’t rated yet 0
В каком сценарии использования это уменьшение будет давать ощутимый прирост производительности?
This comment wasn’t rated yet 0
Я так понимаю вы намекаете на base64, base62 и другие способы конвертации бинарных данных в текстовые? Вот собственно эта фаза перекодировки и мешает. Она не позволяет просто потоком вгрузить файл в память и далее просто ссылаться на его участки — обязательно надо выделять отдельные куски памяти для отдельных декодированных значений.


Как в случае Tree будет выглядить «просто ссылка» на бинарную переменную int-10?
Total votes 1: ↑1 and ↓0 +1
return numbers.select('int-10')[0].value!int

И да, в этот момент будет копирование. Более другие структуры типа StringBuffer могут обойтись без него.
Total votes 2: ↑0 and ↓2 -2
Вы привели код, после обработки парсером.
Ни о какой «ссылке на участок файла» речи здесь не идет.
С таким же успехом я и в xml запихаю бинарные данные в виде base64, распакую и верну результат.

Внимательно прочитайте цитату. Там вы говорите, что недостатком такого подхода является необходимость выделения отдельного буффера под данные перед их использованием.
Покажите код, который будет отдавать ссылку на int-10 без выделения дополнительной памяти под сборку этого самого инта.
Total votes 1: ↑1 and ↓0 +1
Вот именно, что вам придётся распаковывать, а я просто скопирую. Копирование участков памяти — это гораздо более быстрая операция, чем битовые операции или трансляция через таблицу символов.

А зачем вам ссылка, если он может быть сразу загружен в регистр процессора? ;-) Код не приведу, ибо программирую на более высоком уровне абстракции, но компилятору сгенерировать его не проблема.
This comment wasn’t rated yet 0
Я вообще не обсуждал скорость.
Я обсуждал ваш конкретный довод — «выделять отдельную память».
Вывод тут ясен — довод не актуален и, судя по всему, вброшен без серьезного обдумывания.
This comment wasn’t rated yet 0
Очевидно, для массивов байт без выделения отдельной памяти не обойтись. К счастью, если куда более экономные структуры. Связные списки, деревья, кучи и тп. Они вполне могут обходиться ссылками на участки памяти.
Total votes 2: ↑0 and ↓2 -2
Если уж мы говорим о «декодировании», то тут тоже особых проблем нет.
Ничего не мешает сунуть бинарные данные в тот же json. Единственное что придется сделать — экранировать кавычки и бэкслэш.
С точки зрения скорости исполнения и сложности кода нет разницы, экранировать один символ(перенос строки) или два(кавычки и бэк слэш).

Реальным плюсом вашего формата стало бы хранение цельного блока бинарных данных, т.к. это позволило бы делать то, о чем вы говорили — ссылаться на документ не работая с бинарными данными отдельно. Но у вас этого плюса нет. как уже было выяснено.
This comment wasn’t rated yet 0
Я не смогу это распарсить. Ваш JSON не валидный.

А вообще, в чем вы видите сложность? В том, что стандартные парсеры это не поймут? Ну так это естественно. Речь же как раз о том, что нужно изменить, чтобы тот же json смог хранить бинари не хуже чем у вас.
Или вы видите проблему в том, чтобы написать парсер, который будет считать значения валидными, если они содержат любые символы, а не только unicode(как это по стандарту должно быть).
This comment wasn’t rated yet 0
А, ну с такой позиции-то конечно. Только вот кавычки — это довольно частый в употреблении символ, поэтому их лучше бы не экранировать, чтобы не вредить читаемости.
This comment wasn’t rated yet 0
Есть вопрос, как вы сохраните бинарный массив интов каждый из которых имеет значение '\n'? Как это будет выглядеть в вашем формате?
Total votes 3: ↑0 and ↓3 -3
А как можно представить строковое значение, состоящее из одного/N пробелов? Пустое строковое значение? Если так, как я думаю — то без отображения в редакторе непечатаемых символов можно получить не то, что ожидаешь.
Total votes 9: ↑9 and ↓0 +9
Да, есть такой нюанс. К сожалению, большинство редакторов непечатаемые символы показывают слишком навязчиво и вырвиглазно. Думаю через плагин подсветки синтаксиса можно решить эту проблему.
Total votes 12: ↑2 and ↓10 -8
Думаю можно кроме "=" добавить «хередок» формат:
имя #= считается_всё
включая пробелы и переводы строк
до пустой
\n\s*#=\n
или в первой строчке до #=
#=
Total votes 2: ↑2 and ↓0 +2
А чем подсветка концов строк не угодила-то?
Total votes 4: ↑0 and ↓4 -4
Не знаю, как heredoc поможет увидеть, есть пробелы в значении, или там пустая строка. Но зато он может помочь при минимизации: глубоко вложенные данные, имеющие много символов перевода строки, будут минимизироваться за счет избавления от стартовых символов табуляции.

Я же имел в виду, что можно было бы сделать что-то вроде «присваивания с кавычками», как-то так:

something "="simple quoted string goes here"
emptyString "=""
singleSpace "=" "
doubleSpace "="  "
tooManySpaces "="                            "


Это повысило бы читаемость, особенно для тех, кто привык к тому же json и вообще «классическому» подходу объявления строковых литералов. Вместо "= можно использовать что-то вроде q= или |= или что угодно еще, чтобы избежать визуальной путаницы с кавычками. Ну и поддержку вложенных кавычек можно не реализовывать для таких значений: для этого есть обычное «безкавычечное» присваивание.

Однако, такое нововведение добавит в формат «еще один способ делать то же самое», что не всегда есть хорошо и не всем нравится. Ну и плюс парсинг и валидация документа усложнится.
Total votes 1: ↑1 and ↓0 +1
Модель Tree крайне проста — есть только один тип узлов, и каждый узел имеет: имя, значение, список дочерних узлов. Имя и значение являются взаимоисключающими.
Здесь точно нет ошибки? Вот же простой пример узла с именем и значением:

ip =8.8.8.8
Total votes 1: ↑1 and ↓0 +1
Это два узла, между ними стоит пробел :-)
Total votes 1: ↑0 and ↓1 -1
Тогда что такое узел? Я понимал что это узел дерева, но вы видимо называете узлом токены. Это надо было подробнее расписать и с примерами.
This comment wasn’t rated yet 0
Еще больше запутывает ваше описание «есть только один тип узлов, и каждый имеет имя, значение, список дочерних». Получается не один и не каждый.
Total votes 8: ↑8 and ↓0 +8
Видимо, имеется в виду, как у узлов традиционного дерева, скажем, бинарного: поля есть все у каждого узла, но некоторые могут быть пустыми (null). Если арибут(поле) узла «имя» заполнен, то это lvalue элемент, тот, что слева от присваивания. Иначе(имя=null) могут быть заполнены либо «значение» (окраинный лист), либо «дочерние» (ссылка на другой узел/список узлов, может быть реализовано как вырожденное дерево).
This comment wasn’t rated yet 0
Почти. Любой узел может иметь либо не пустое имя, либо не пустое значение, либо пустое и имя и значение. Любые узлы могут иметь дочерние.
This comment wasn’t rated yet 0
Тогда чем отличаются 
ip =8.8.8.8

и
ip
    =8.8.8.8

This comment wasn’t rated yet 0
Ничем. Первая запись — короткая форма, позволяющая не плодить лишних отступов, когда дочерний узел всего один.
This comment wasn’t rated yet 0
1) Почему узел с не пустым именем не может иметь значение? Почему запрещено ip=8.8.8.8?

2) Каким образом узел с не пустым значением может иметь дочерние? Так?
=8.8.8.8
    дочернийузел1
    дочернийузел2
Для чего это нужно?

А к какому узлу будут привязаны дочерние в этом случае?
ip =8.8.8.8
    дочернийузел1
    дочернийузел2
Правильно ли я понимаю, что в первом случае дочерние будут привязаны к узлу, который идет непосредственно перед ними, а во втором к предыдущему узлу? Т.е. к какому элементу буду привязаны дочерние узлы, зависит от типа родительского узла? Хотя вы и утверждаете что все узлы одинаковые. Либо все же не зависит, и дочерние узлы будут привязаны к узлу со значением =8.8.8.8? Но тогда ваше утверждение, что две записи равноправны, неверно.

3) Тот же вопрос, когда в родительской строке два или больше узлов только с названием.

4) С учетом всего вышесказанного вы по прежнему считаете, что ваш формат очень простой?
Total votes 2: ↑2 and ↓0 +2
1. Потому что значение может состоять из нескольких узлов, ввиду того, что символа перевода строки в них быть не может.

2. Яркий пример — указание для всех узлов, откуда они были взяты:

image

3. Почитайте внимательнее описание формата. «Наличие табуляции в строке означает, что первый узел в этой строке должен быть вложен в последний узел последней строки имеющей табуляцию на один меньше.»

4. Да, очень.
This comment wasn’t rated yet 0
UFO just landed and posted this here
Вы даете переводчикам переводить файлы в «сыром» виде, не давая воспринимающих эти форматы инструментов?.. Кажется, я начинаю понимать, почему качественных переводов днем с огнем не найти…
This comment wasn’t rated yet 0
UFO just landed and posted this here
Справедливости ради, в defaul language конструкция %d items тоже иногда не работает. Но я понял, о чем речь.
This comment wasn’t rated yet 0
UFO just landed and posted this here
Просто работаю с этими читающими человеками (переводчиками в моём случае) и каждый раз всё, что приходит на локализацию (а схемы у разных заказчиков ой какие разные, да даже в одном проекте может быть несколько разных форматов или разное использование одного формата), приходится перегонять во что-то более удобное и потом засовывать обратно, иначе будут переведённые ключи, убиение экранирования в значениях и прочая трудноуловимая содомия

В контексте вашей задачи tree ситуации не исправит — там тоже будет проблема с недопустимыми символами.
This comment wasn’t rated yet 0
UFO just landed and posted this here
В первую очередь — странные отношения со строками, которые вынесут мозг любому не-специалисту.

Для внутреннего представления, возможно, подойдет, но, я сильно подозреваю, что избыточно.
This comment wasn’t rated yet 0
UFO just landed and posted this here
Очень сложно объяснить, что если в конце текста нужен перевод строки, то нужно вбить перевод, отбивку табуляцией и еще один перевод; но если он не в конце текста, то начинать писать сразу после отбивки.
Total votes 1: ↑1 and ↓0 +1
Довольно странный кейс, но всё вполне логично — строк получится столько же сколько и символов равно.
This comment wasn’t rated yet 0
О нет.

=abc\n -> одна строка (с точки зрения человека)

=abс\n
=\n -> все еще одна строка с точки зрения человека

=abc\n
=def\n -> две строки с точки зрения человека.
This comment wasn’t rated yet 0
"abc\n" // одна строка с точки зрения человека
"abс\n\n" // всё ещё одна строка с точки зрения человека
"abc\ndef\n" // и опять же одна строка с точки зрения человека

Вы что доказать-то этой софистикой хотите?
This comment wasn’t rated yet 0
Что у tree есть свои странности, которые неподготовленному человеку вынесут мозг. Конкретный кейс конкретного massimus.
This comment wasn’t rated yet 0
Вы находитесь в плену собственных привычек.
Total votes 1: ↑0 and ↓1 -1
«Неподготовленному».
This comment wasn’t rated yet 0
Важно, что у всех узлов один апи, а так, да, можно ввести 3 отдельных субкласса, но я ограничился одним классом и 3 хелперами для их создания.

Тул для транскодинга, конечно будет. Я хочу использовать Tree как AST в которое перегонять остальные форматы (хоть xml, хоть css), трансформировать с помощью lisp/xslt-подобного языка в модель целевого языка и сериализовывать в него.

Может присоединишься к разработке? :-)
This comment wasn’t rated yet 0
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
vintage, вы зря игнорируете мой вопрос. Ваше описание формата основано на концепции узлов. При этом вы не говорите, что это такое. По прошествии суток я так и не могу понять синтаксиса вашего супер-простого формата.
Total votes 2: ↑2 and ↓0 +2
Прошу прощения, но днём я работу работаю, а не хабру хабрю :-) Ответил чуть выше.
Total votes 4: ↑1 and ↓3 -2
Само собой, нисколько не хотел претендовать на ваше рабочее время. Однако вы ответили на много других вопросов, заданных значительно позже, а тот, что выше, к тому моменту проигнорировали.
This comment wasn’t rated yet 0
Они были банально выше на странице. Я не сравнивал даты комментариев.
This comment wasn’t rated yet 0
До этого момента, я думал, что все понятно…
Total votes 3: ↑3 and ↓0 +3
Мне кажется, что основная проблема – с названием. Если нужно найти что-то на тему XML или JSON, то в Гугле можно набрать это слово, и оно сработает как тег, выдача будет существенно предметной. Если же завтра, допустим, Tree распространится, то придется каждый раз хитрить, чтобы отвязаться от биологов, теорий баз данных, описаний структур и онтологий. Если вводите новый термин, его нужно делать по возможности уникальным.
Total votes 17: ↑17 and ↓0 +17
Действительно. У вас нет идей, как его назвать так, чтобы название отражало его иерархическую суть?
Total votes 1: ↑0 and ↓1 -1
Чем множественная форма поможет в этом вопросе?
Total votes 4: ↑4 and ↓0 +4
На самом деле для меня это сокращение от TreeSpace. А множественная форма сильно поможет — www.google.ru/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#newwindow=1&safe=off&q=Trees
, потому что нет такого названия сущности. И гугл сумеет различить tree и Trees если появится.
Total votes 8: ↑6 and ↓2 +4
UFO just landed and posted this here
S-Tree, по аналогии с B-Tree.
This comment wasn’t rated yet 0
Кстати, SyntaxTree очень даже подходит идеологически.
Total votes 2: ↑0 and ↓2 -2
К сожалению, сейчас XML технологии не в почёте. А так, классная игра слов.
This comment wasn’t rated yet 0
Искать если и будут, то скорее не сам формат, а какой-то язык на его основе. Например, json.tree.
This comment wasn’t rated yet 0
Скорость парсинга/сериализации

Очень интересно как вы это оценили, по моему мнению ваш формат тяжелее того же json, грамматика у вас не проще, она сложнее т.к. она контекстно зависимая.
Удобство редактирования

Вот уж нет, ваш формат неудобно редактировать. Почему после = не должно быть пробела? Это ведь неудобно. Да и реализуется это не сложно.

Просто я тоже не давно писал свой формат, от нечего делать, и как по мне так он удобнее. Интересно сравнить как будет выглядеть в вашем формате подобная структура. Может что полезного для своего формата найду в вашем.
{
	// Узел может одновременно иметь атрибуты, значения, подузлы
	scene (type = Open; lods = on;) = "Start location" 
	{
		object = "Tree"
		{
			position = 56.42, 23.0, 234.325;
			rotation = 0, 45.34, 0;
			
			mesh (layout = pos, UV, norm, tang, wei, ind; animated = true) 
				= "./assets/meshes/tree.ms";
				
			animations = "idle_1", "idle_2", "idle_3";
			
			collider (static = true) = cylinder
			{
				offset = 0, 5, 0;
				radius = 45.351;
				height = 180.45;
			}
			
			material = cook torrance
			{
				albedo = "./assets/textures/tree_a.png";
				normal(normal = rgb; spec = a) = "./textures/tree_n.png";
			}
			
			object = "leaves"
			{
				mesh (tangents = on; animated = true) = "./assets/meshes/leaves.ms";
				animations = "idle_1", "idle_2", "idle_3";
				
				material(translucent = true; alpha = alpha test) = cook torrance
				{
					albedo = "./assets/textures/leaves_a.png";
					normal(normal = rgb; spec = a) = "./textures/leaves_n.png";
					translucent = "./textures/leaves_t.png";
				}
			}
		}	
	}
}
Total votes 18: ↑17 and ↓1 +16
А что сложного в тривиальной контекстно зависимой грамматике? Там нужно всего-лишь иметь стек узлов и по числу табов его обрезать.

Люди вон, к нагромождению скобочек в лиспе привыкли так, что удобным это считают, а вы тут на один пробел жалуетесь :-)

Насколько я понял код, в Tree он будет выглядеть примерно так:

image
Total votes 6: ↑1 and ↓5 -4
Тем что у вас она куда менее тривиальна чем у того же JSON. А на пробел жалуемся т.к. не понятен смысл данного ограничения, который разгуливается на раз.
Насколько я понял код, в Tree он будет выглядеть примерно так:

Ок тогда поговорим о проблемах которые в данном случае несёт ваш формат.
1) Он получился длиннее и намного (вы не описали материал и под узел leaves). И он неправильно передал структуру выше, а конкретно: почему у rotation в конце просто 0 а не =0 это опечатка? layout в моём случае это массив констант layout = pos, UV, norm, tang, wei, ind; у вас же это под узлы месша.
2) Такая же проблема как и у JSON, это отсутствие атрибутов (собственно потому мне и пришлось писать свой формат). Есть ли хоть какая нибудь гарантия что узлы name, type, lods в вашем случае не окажутся где то в середине узла между другими большими под узлами? Напомню что в ваш формат пишет не только человек, но и машина, а ей не укажешь какой узел должен идти раньше, а какой позже (по крайней мере подобного требования в вашем стандарте я не увидел).
3) Также имеется проблема которая сразу ставит крест на формате (по крайней мере для меня), отсутствие поддержки массивов. Серьёзно кому может понравится писать 
offset
    =0
    =5
    =0
// вместо
offset = 0, 5, 0;
//или
"offset" : [0, 5, 0],


В результате получаем что ваш формат проигрывает XML в случае когда активно используются атрибуты и массивы, и также проигрывает JSON в случае с использованием массивов и если он будет использоваться для протокола передачи (из-за табов).
Если так нравятся табы, то можно было бы сделать тот же JSON только без ", {
Выглядело бы лучше.
Total votes 3: ↑3 and ↓0 +3
При парсинге JSON вам точно также нужен будет стек, только ещё нужно будет разэкранировать строки.

1. Разумеется, специализированный DSL будет наглядней и короче, чем универсальный формат. 0 — это конечно же опечатка.

2. А это принципиальный момент, чтобы атрибуты шли первым? Если да, то и вставляйте их первыми :-) Формат лишь гарантирует, что в каком порядке их туда положил, в таком же и получишь.

3. Это только в тривиальных случаях «и в одну строку норм». 

"offset" : [ 123454.234345, 1234893434.3425342, 324589565.1342352461 ],

image

JSON плохо своей моделью данных прежде всего. Любое дерево (ast, html и прочее) в JSON выглядит как нагромождение костылей.
Total votes 4: ↑0 and ↓4 -4
1. Разумеется, специализированный DSL будет наглядней и короче, чем универсальный формат.

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

Честно говоря не нашёл этого требования в исходном тексте, разве это зависит не от реализации? Если для хранение нодов я буду использовать мапу или хеш, как можно гарантировать порядок записи?
3. Это только в тривиальных случаях «и в одну строку норм».

Это в любых случаях норм, и я не говорил что запись должна быть исключительно в 1 строку, вот пример записи матрицы из того же формата.
transform =
   1, 0, 0, 0,
   0, 1, 0, 0,
   0, 0, 1, 0,
   0, 0, 0, 0,

И да хотел бы я посмотреть в какой ад превратился бы формат коллады, используй они твой формат. По большому счёту именно твой формат является специализированным.
JSON плохо своей моделью данных прежде всего. Любое дерево (ast, html и прочее) в JSON выглядит как нагромождение костылей.

Он практически полностью идентичен твоему формату, все различия заключаются лишь в том что для блоков у тебя используются табы, а там {} ну и в требованиях использовать " во всём остальном он лучше твоего формата, опять же если использовать hjson то и от " можно будет избавится. Не вижу ничего в чём твой формат превосходит JSON и из-за чего на него хотелось бы перейти. Где те фичи ради которых хотелось бы на него перейти?
А ещё я никак не могу понять чем твоя «Произвольная иерархия» отличается от того же json или XML? И если уж говорить о возможностях то YAML на голову выше.
Вообще с таблицей которую ты предоставил я в корне несогласен. Она крайне субъективна.
Total votes 3: ↑3 and ↓0 +3
Честно говоря не нашёл этого требования в исходном тексте, разве это зависит не от реализации? Если для хранение нодов я буду использовать мапу или хеш, как можно гарантировать порядок записи?
Это не требование, это определение списка.

Матрицы могут быть представлены на уровне языка так:

image

Хоть это и потребует немного больше телодвижений, чем с простым вертикальным списком. С другой стороны, модель Tree позволяет делать такие выкрутасы:

image

Total votes 3: ↑0 and ↓3 -3
Это не требование, это определение списка.

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

То есть на уровне приложения мне придётся парсить 1..0..0..0?
С другой стороны, модель Tree позволяет делать такие выкрутасы:

В каком смысле? y.determinant нам придётся разбивать в коде?
Total votes 1: ↑1 and ↓0 +1
Присмотритесь внимательнее.

Точки — это подсветка пробелов в IDEA

Тут речь о том, что в ячейке может быть формула от другой матрицы.
Total votes 3: ↑0 and ↓3 -3
Точки — это подсветка пробелов в IDEA

А в ы можете не делать скриншот ide а просто вставить текст с тегом кода? Ато это сбивает с толку, я например в IDEA не работал, откуда мне занть что точки это пробелы.
Тут речь о том, что в ячейке может быть формула от другой матрицы.

В каком смысле формула? Мне придётся писать код чтобы из 1 0 0 0 получить нужную мне последовательность?
Total votes 5: ↑5 and ↓0 +5
Каким тегом? Хабр как бы не поддерживает подсветку Tree синтаксиса.

Тому, кто будет разрабатывать реализацию языка, придётся написать этот код.
Total votes 1: ↑0 and ↓1 -1
Текст без подсветки лучше его отсутствия.
Total votes 4: ↑4 and ↓0 +4
Но лучше всё же с подсветкой.
Total votes 2: ↑0 and ↓2 -2
Да, текст лучше с подсветкой. Но сейчас-то текста вообще нет.
Total votes 5: ↑5 and ↓0 +5
Если вам нужно его скопировать и поредактировать, то могу выложить и сырым текстом.
Total votes 2: ↑0 and ↓2 -2
А в ы можете не делать скриншот ide а просто вставить текст с тегом кода? Ато это сбивает с толку, я например в IDEA не работал, откуда мне занть что точки это пробелы.
В Visual Studio работаете? Ctrl+R, Ctrl+W
Total votes 3: ↑0 and ↓3 -3
Хабравчане, и за что минусы? Я лишь сделал предположение по профилю Chaos_Optima, что он работает с .NET и соответственно…

Хотя… нужно было на весь список подписок посмотреть.
Total votes 1: ↑0 and ↓1 -1
А что собственно мешает так записать? массив только будет рассматриваться как строка, и вся работа с ним ложится на приложение которое ожидает там массив. Или приложение знать не знает что там должен быть массив?
Total votes 3: ↑0 and ↓3 -3
Если так рассуждать так вообще ничего ненужно, сразу брать и перекладывать всё на приложение. Зачем нам вообще форматы какие-то.
В данном случае всё упирается в удобстве, приложение может не знать что там или менять логику работы в зависимости от того что там, массив или просто значение. В любом случае это одна из фундаментальных структур которую не плохо было бы иметь. В конце концов это нетрудно сделать. Достаточно добавить [ ] и сделать так чтобы внутри этих скобок табуляция и переносы не учитывались, на уровне элементов.
This comment wasn’t rated yet 0
Сделать вроде бы нетрудно, но сразу же поиметь неопределенность в другом и свести на нет остальные достоинства формата.
Собственно «сделать так чтобы внутри этих скобок табуляция и переносы не учитывались» это и есть перенос обработки массива на приложение.
Total votes 1: ↑0 and ↓1 -1
А в чём заключается неопределённость, и каким образом это сводит на нет остальные достоинства формата?
Собственно «сделать так чтобы внутри этих скобок табуляция и переносы не учитывались» это и есть перенос обработки массива на приложение.

эм… вообще то нет. Если мы напишем 
object
   transform =[ 1, 0, 0,
                             0, 1, 0,
                             0, 0, 1]

то это сломает парсер.
This comment wasn’t rated yet 0
Похоже на формат конфига nginx'а.
Есть в открытом доступе парсеры?
This comment wasn’t rated yet 0
Долго искал этот комментарий, но не нашёл.

С другой стороны, XML позволяет внедрять свои тэги внутрь текста…

<greeting>
    Hello, <b>Alice</b>!<br/>
    How do you do?
</greeting>



Это невалидный xml. Должно быть как минимум так:

<greeting>
<![CDATA[
    Hello, <b>Alice</b>!<br/>
    How do you do?
]]>
</greeting>

Total votes 36: ↑16 and ↓20 -4
Почему это невалидный? Вполне себе даже валидный. Но если вы намекаете на то, что контент надо хранить как единую сущность: то да — надо бы обернуть в CDATA.
Total votes 19: ↑18 and ↓1 +17
Почему же он невалиден? Совершенно нормальный mixed content, широко используется в том же XHTML. А вот CDATA как раз будет ошибкой, если требуется, чтобы <b> был именно тэгом, а не экранированным значением.
Total votes 20: ↑19 and ↓1 +18
>Узлы-значения – значением, предварёнными символом равенства.
зачем знак равенства?

>А теперь сравните с реализацией в Tree формате:
больше похоже на первый вариант
Total votes 1: ↑1 and ↓0 +1
Чтобы пробелы не рассматривались как разделители узлов.

Именно, только без лишнего визуального шума.
Total votes 3: ↑0 and ↓3 -3
>Редактирование других форматов, через Tree представление
хорошая идея
Total votes 1: ↑1 and ↓0 +1
Автору. Рекомендую продвигать эти идеи среди другой аудитории. На праздниках я тоже сделал вклад в развитие поддержки стандартов, ввёл новый «стандарт» jsonComm, который описывается очень просто, 2 строчками:
1) формат данных — как у JSON;
2) формат комментариев — как у JS и Yaml.
Вначале описал его на Хабре. Не только «стандарт», но и отлаженные процедуры, работающие в JS, для перевода в JSON и для работы с самим jsonComm, с тестами. Понятно, что праздники, но «плюсов» — всего 19, а минусов — 16. При этом никто не писал, что новый «стандарт» вреден. Посетителей на Гитхабе — под 4.5 сотни, но «star» — всего один. Что говорит об интересе.

Затем написал на EchoJS.com, просто ссылку на страницу Гитхаба. Посетителей всего 37, из них 10 могли быть остатком с Хабра, но «star» добавилось 4.

Скрин:

12-го — это всплеск с EchoJS.

По Вашему формату: какой-то странный у вас sample.tree на Гитхабе, не показывает элементы формата, только
user
    name =John
    age =30
и далее — 1024 повторения. И отличен от sample.json, где это — массив users. Примеры перед продвижением должны быть более представительны — никто не будет читать статью, чтобы ознакомиться с новым форматом, а посмотрит на примеры, примеряя на себе, «буду ли я это использовать». А тут все примеры — в статье с обилием промоутерских фраз, да на русском.

> Надеюсь мне удалось заразить вас идеей…
Заражают не так. Например:
Если вы новичок и еще не совсем уверены, что Backbone вам подходит, начните с просмотра списка проектов, использующих Backbone.
Total votes 27: ↑8 and ↓19 -11
ваш «стандарт» еще хуже, имхо
да и стиль написания статей так себе. отсюда и малый интерес
Total votes 7: ↑7 and ↓0 +7