Сериализация структур. Нет вопроса. Ваши замечания

«Вы изобрели YAML, только хуже.»

Почему, собственно, не его?

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

понадобится повторять имя поля для каждого поля в каждой структуре

IMHO так даже читабельнее...

есть ли в нем встроеная валидация

Разве что типов данных. Но на вики пишут, что можно прикрутить какие-то валидаторы.

Непонятно что делать, если понадобится интерпретировать его буквально как "-", а не как пустое поле

Используй backslash же: «\-»

Тоже об этом сначала подумал. Наверное так и сделаю. Типа если нужно поле с одним-единственным символом "-" - пиши «\-»

Правда возникает вопрос, а что если нужно поле со значением «\-»

А что не протобуф?

Погуглил. А очень даже неплохо. Может и не буду свой велосипед писать) Есть под сишечку. Минифицированный js весит 50kb. Адекватный язык описания схемы. Констрейтов правда нет - это беда.

Минимум Максимум

Даже для строк и других структур?

Для строк длина. А других структур нет. Разве что массивы типизированные еще.

Но что-то я приуныл, глядя на юникод. 20 пробелов и 8 символов newline

Выглядит вполне разумно

ENTER-ами

омг. А Ctrl+M нельзя?

Так и быть, напишу «символами переноса строки» когда мой уберформат будет принимать женевская штаб-кравтира ISO

Правда возникает вопрос, а что если нужно поле со значением «\-»

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

Кросплатформенности значит не будет? В винде два символа, например.

И при чём тут ISO, если должна машина читать? Это стохастический формат? Должен ли алгоритм чтения проходить тест Тьюринга?

Кросплатформенности значит не будет? В винде два символа, например.

Это ты мне скажи. надо ли кроме CR и LF интерпретировать NEL LS и PS?

И при чём тут ISO, если должна машина читать?

Задумка в том, чтобы можно было и руками написать если что и глазами проанализировать HTTP-запрос если что. И без проблем распарсить любым примитивным языком, если что )

Можно услышать о причинах изобретения своего решения и плюсах по сравнению с рассмотренными вами существующими решениями?

о причинах изобретения своего решения

JSON избыточен для коллекций и не умеет в типы и ограничения. YAML тяжел для браузера и есть не на всех языках. Protobuf - есть не везде и бинарный.

и плюсах

Типизация. Сам себя валидирует. Ограничения для значений. Парсер (надеюсь) в пару сотен строк - легко реализовать на нужном языке. Человекочитаемый/писаемый. Для простых скриптов можно пропустить схему и тупо читать значения линия за линией.

надо ли кроме CR и LF интерпретировать NEL LS и PS?

Нет. Только эти.

Задумка в том, чтобы можно было и руками написать если что и глазами проанализировать HTTP-запрос

Лажанулся я с тестом Тьюринга, признаю. Похоже задача сложнее, чем я думал. Как будешь эмулировать руки и глаза - нейросети? Уже копал в сторону GPU? Потому что явно основной процессор не осилит. Или сразу затачиваешь парсер под суперсистемы?

Зависимость от порядка полей при передаче данных (не схем) может привести к двойной работе, если вы этот порядок захотите поменять.

При всей велосипедности задумки ТС хочу отметить, что такие парсеры обычно генерят. По крайней мере я генерю. Так что ИМХО это не проблема.

Можно в функцию сериализации добавить параметр-массив с порядком полей. Если я вас правильно понял

По крайней мере я генерю.

Чем, если не секрет?

Про GPU с нейросетями поржал. Нет, все намного проще - кроудсорсинг. Сделать онлайн сервис, где любой индус сможет парсить ваши данные используя свои руки и глаза

Чем, если не секрет?

В простых случаях (90%) sh.

В сложных иерархических случаях проще лисп (он по-умолчанию иерархический).

Сейчас размяк, захотелось комфорта. Написал интерпретатор карт памяти (конкретно freemind, у него карты в xml). Очень удобно и наглядно.

Если взять yaml и потребовать чтобы первым объектом шёл массив типов полей, а дальше шли массивы данных. То получится ровно тоже самое что у тебя, но со спецификацией.

Непонятно что делать, если понадобится интерпретировать его буквально как "-", а не как пустое поле

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

А что не протобуф?

Схемы в протобуфе статические. Придётся либо на лету генерировать парсеры и генераторы по схеме и всё равно делать базовый формат для передачи схемы с блобом протобуфа, либо костылить ещё один формат поверх самого протобуфа.

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

Тогда уж лучше эту бадягу поверх JSON реализовать. Разницы особой не будет. Так и сделаю если будет лень писать свой костыль для трех языков

Схемы в протобуфе статические. Придётся либо на лету генерировать парсеры и генераторы по схеме и всё равно делать базовый формат для передачи схемы с блобом протобуфа, либо костылить ещё один формат поверх самого протобуфа.

Не распарсил. Любая либа умеет читать файлы со схемой. Получаешь бинарь (например, в теле HTTP-ответа), натравливаешь его на схему - на выходе распарсенный объект. В обратную сторону тоже самое. Или я не прав?

MessagePack, BSON

Они не умеют в схему. Вот представь, получил ты json. И хрен пойми что в нем. Как в таких условиях работать? Проверять кодом всю структуру?

Любая либа умеет читать файлы со схемой... Или я не прав?

Реализации протобуфа обычно так не работают, они из схемы гененируют код парсеров и генераторов пакетов на выбранном ЯП. Далее, в зависимости, от ЯП, код нужно скомпилировать и только потом этим кодом можно что-то делать.

Короче, забраковали вы мой революционный формат. Значит будет так:

[
["schema", 1.0],

["id", "number", 0],
["name", "string", 1, 100, "Jonh Doe"],
["sex", "enum", "Male", "Female", "Male"],
["hetero", "boolean", true],

["data"],

[1, "Петров"],
[2, " Иванова", "Female", false]
]

Да, так красивее и парсить проще)

Это опасный путь. Можно закончить чем-то вроде:

{
  "schema": [
    {
      "name": "id",
      "type": "number",
      "minimum": 0,
      "default": 1
    },
    ...