Есть формат даты принятый в нотации по умолчанию (чтобы не возникало коллизий при парсинге), но вы вольны использовать любой (и передавать обычным текстовым значением). Если ваш реципиент примет это соглашение, то сможет его корректно обработать.
Спасибо за похвалу и за конструктивный комментарий.
Принципиально иной подход к сериализации данные данных невозможен в современной лингвистической парадигме (язык общения людей). Да и смена парадигмы не принесла бы ничего принципиально иного. Время открытий прошло, сейчас может начаться только эра оптимизаций.
Надеюсь, что у меня хватит ресурсов не просто добавить язык в пул языков для конфигов, а заместить старые. Хотя полностью этого не получится, тот же старинный INI вроде как до сих пор много где используется.
А что касается обмена с браузерами, тут может измениться и сама концепция браузинга. Мне очень не нравится современный Интернет и я бы сделал его более простой аналог, будь у меня ресурсы и единомышленники.
Сейчас начал проектировать обмен между учётной системой и интернет-магазином с применением UNO. Предполагаю сделать на порядок более быстрое и надёжное решение, чем текущий стандартный обмен. И человекочитаемость на этапе отладок будет здесь огромным подспорьем.
А можете пояснить подробно ход ваших мыслей? Мне не для спора, а просто вычленить рациональное зерно. Это из-за того, что файл может неполным прилететь? или что-то другое, чего я не знаю? Буду благодарен за развёрнутый ответ.
Дуализм делителя это великая находка, позволяющая красиво решить поставленные перед языком задачи. Если у вас настроение только выискивать негатив, а не попытаться понять иной, непривычный для вас подход, то не мучайте себя.
Если у передающей и принимающей сторон есть соглашение (описание данных), то, естественно, коллизий не возникнет ни в XML ни в JSON, ни в YAML, ни в других языках разметки. Но много ли вы встречали, например, действительно рабочих описаний XSD? Обычно всё решается полуформально и догадками. UNO же позволяет многое передавать самоописанием без соглашений (в статье ещё не все аспекты заявлены).
Не так. Если делитель выражения двоеточие, то это строка, если знак равно, то это число (f64). key= 12345
Если вам, как составителю данных важно указать иной формат, то вы можете двигаться двумя путями (как вам покажется удобнее в конкретной ситуации):
либо указать требуемый тип данных непосредственно в строке key= int:12345
либо в проверочном шаблоне добавить проверку $ type: int
Всё элементарно. А если вы имеете в виду неявное определение типа числа по наличию точки key= 12345.0, то это тупиковый путь. Составителю придётся ставить эти точки и нули (а UNO Core предназначается и для ручного оформления данных) и обязательно забудет это сделать. А оставить это для угадывания нельзя: допустим мы передаём список товаров с ценами и где-то будет стоять точка, а где-то нет -- возникнет коллизия. Плюсом отказа от угадывания является и ускорение обработки данных парсером.
Ну да, отправитель и принимающая сторона могут договориться о каких-то своих правилах и понимать друг-друга в частном случае. Однако язык обмена данными подразумевает возможность нормальной интерпретации данных и неподготовленной стороной. По идее они могут взять стандартный парсер, который проверит синтаксис и при отсутствии ошибок переведет всё в абстрактное дерево, а затем уже можно конвертировать в привычный джейсон или что иное, но эффективнее как раз оперировать данными напрямую из абстрактного представления. В данном примере цена= 1200 rub абсолютна валидна в UNO, такое представление называется спаренное значение, состоящее из величины и единицы её измеряющей.
А вот мне не хотелось бы вникать в множество форматов. Мне кажется можно оставить CSV(TSV), XML, чистый JSON, UNO, возможно ещё какие-то узкоспециализированные типа Apache Parque -- в нём я не разбирался ещё и бинарные.
UNO можно без проблем использовать как замену экстремально минималистичному ENV и будет даже короче, можно не проставлять кавычки для текстовых значений.
Вроде как Rub(1200) и Grams(650)невалидно. В RON это валидно, только если это именованные Tuple Struct или Enum-варианты. Если это просто текст, нужны кавычки. Да и прочее вызывает сомнение. Скорее всего код будет выглядеть так:
{
"книга": {
"rating": 4.9,
"артикул": "LOTR-SILM-01",
"название": "Сильмариллион",
"авторы": [
"Дж. Р. Р. Толкин",
"Кристофер Толкин",
],
"основной жанр": "Эпическое фэнтези",
// Сырые строки (Raw strings) в RON поддерживаются идеально
"аннотация": r#"История Первой Эпохи Средиземья, создания Сильмарилей и падения Моргота.
Древняя хроника, определившая лицо современной мифологии."#,
// Коммерческий блок как вложенная мапа
"коммерция": {
"цена": 1200,
"валюта": "rub",
"тираж": 50000, // суффикс u32 убираем, RON его не поймет
"вес": 650,
"единица_измерения": "g",
},
},
}
Но я не специалист, настаивать не буду. К тому же и первый вариант мне нравится меньше, чем УНО.
Прошу прощения за безапеляционность. Пришлось намеренно ввести элемент провокационности исключительно для привлечения внимания, т.к. первая статья https://habr.com/ru/articles/1075348/ прошла незаметно. Что касается сложности обусловленной мощностью функционала, это решено путём разделения на продвинутую и основную спецификацию UNO Core, в которой нет никаких модификаторов, импортов и прочего.
Это настолько предсказуемо и уже давно не смешно. Может быть нам всем следует отказаться от попыток что-то улучшить или вообще вернуться в докаменный век, стать животными не умеющими использовать орудия труда?
Борюсь с этим в зародыше. Во-первых, есть 3 уровня спецификации: Core -- самая простая, осилят абсолютно все и для большинства случаев может и достаточно. Advanced уже полноценный механизм, но всё ещё однопроходный быстрый парсер. Правил чуть больше, но однозначно понятные. И Extremum -- это уже узкоспециализированная редко используемая более медленная штука, обычных пользователей она не затронет. Сейчас дописываю вторую часть статьи, думаю станет яснее.
Спасибо за информацию. Про Universal Network Objects не знал. Но менять название не буду. Понятие нотации гораздо шире узкоспециализированной программы, поэтому аббревиатура от UNderstandable UNiversal NOtation of Objects здесь будет полезнее.
Спасибо большое. Про пользователей задумывался, но на всё времени не хватает. Джетбрейнс раньше пользовался, но потом они ограничили регион пользования. С подсветкой кода не должно быть сложно. Если вдруг вам захочется её сделать, то можете взять все регулярки из подсветки для ВСКода и скормить нейросетке. Даже бесплатная Джемини должна справиться. У меня не скоро руки до этого дойдут. А отрисовка на лету это вы имеете в виду чтобы мгновенно всё переводилось в html и можно было наблюдать результат в браузере? Что-то я даже не подумал что это возможно, а похоже идея рабочая.
Дело в том, что при создании Марквана я абстрагировался от веб-отрасли. Была задача создать абстрактное представление не виртуального, а практического книгоиздания (естественно со всеми выгодами гиперссылок и кода). Есть мысли определенным образом переструктурировать информацию, выделив всё что есть полезного у человечества, отсеив некачественное и мусор. Но боюсь, задача усложняется с каждым днём :-) Что касается технологий. Статический веб-сайт может быть весьма функционален. Посмотрите здесь https://markvan.mudrium.ru/osnovnaya_spetsifikatsiya/vklyucheniya/tehnicheskie.html есть включения с формулами, диаграмами, нотами, картами. Это всё яваскрипт. Я ещё во второй версии не успел сделать демку (в первой была) -- там был онлайн-редактор, где вы могли побаловаться вводом марквана и одновременным его преобразованием в ХТМЛ. Кроме того, не так уж и сложно реализовать даже поиск по сайту. Если добавлять в статический сайт электронную коммерцию, то с этим сложнее. Пока не размышлял. Придётся вероятно встраивать виджеты от банков. Есть, конечно и сервисы встраивающие процессинг магазина в сайт, когда-то был Эквид, сейчас не знаю. Ну а стили вы можете вообще какие заблагорассудится вставлять. Т.е. есть папка с вашим контентом, а есть папка с темой и конвертер всё это объединяет в готовый сайт.
Пришлось чуть усложнить. Необходимо было заложить гораздо больше смыслов чем в маркдовн и в хтмл. Да и веб в этом проекте вторичен, задачи у стандарта иные (но об этом не в ближайшее время). На самом деле маркван запоминается легко, если понять общие принципы и у пользователя есть реальная задача.
Спасибо. Особо продвигать не планирую, это пока инструмент для решения своих задач, ну и проверка себя на креативность. Сейчас работаю над более фундаментальным проектом. Как закончу, может и вернусь к этому.
Есть формат даты принятый в нотации по умолчанию (чтобы не возникало коллизий при парсинге), но вы вольны использовать любой (и передавать обычным текстовым значением). Если ваш реципиент примет это соглашение, то сможет его корректно обработать.
Спасибо за похвалу и за конструктивный комментарий.
Принципиально иной подход к сериализации данные данных невозможен в современной лингвистической парадигме (язык общения людей). Да и смена парадигмы не принесла бы ничего принципиально иного. Время открытий прошло, сейчас может начаться только эра оптимизаций.
Надеюсь, что у меня хватит ресурсов не просто добавить язык в пул языков для конфигов, а заместить старые. Хотя полностью этого не получится, тот же старинный INI вроде как до сих пор много где используется.
А что касается обмена с браузерами, тут может измениться и сама концепция браузинга. Мне очень не нравится современный Интернет и я бы сделал его более простой аналог, будь у меня ресурсы и единомышленники.
Сейчас начал проектировать обмен между учётной системой и интернет-магазином с применением UNO. Предполагаю сделать на порядок более быстрое и надёжное решение, чем текущий стандартный обмен. И человекочитаемость на этапе отладок будет здесь огромным подспорьем.
А можете пояснить подробно ход ваших мыслей? Мне не для спора, а просто вычленить рациональное зерно. Это из-за того, что файл может неполным прилететь? или что-то другое, чего я не знаю? Буду благодарен за развёрнутый ответ.
Дуализм делителя это великая находка, позволяющая красиво решить поставленные перед языком задачи.
Если у вас настроение только выискивать негатив, а не попытаться понять иной, непривычный для вас подход, то не мучайте себя.
Если у передающей и принимающей сторон есть соглашение (описание данных), то, естественно, коллизий не возникнет ни в XML ни в JSON, ни в YAML, ни в других языках разметки. Но много ли вы встречали, например, действительно рабочих описаний XSD? Обычно всё решается полуформально и догадками. UNO же позволяет многое передавать самоописанием без соглашений (в статье ещё не все аспекты заявлены).
Не так. Если делитель выражения двоеточие, то это строка, если знак равно, то это число (f64). key= 12345
Если вам, как составителю данных важно указать иной формат, то вы можете двигаться двумя путями (как вам покажется удобнее в конкретной ситуации):
либо указать требуемый тип данных непосредственно в строке key= int:12345
либо в проверочном шаблоне добавить проверку $ type: int
Всё элементарно. А если вы имеете в виду неявное определение типа числа по наличию точки key= 12345.0, то это тупиковый путь. Составителю придётся ставить эти точки и нули (а UNO Core предназначается и для ручного оформления данных) и обязательно забудет это сделать. А оставить это для угадывания нельзя: допустим мы передаём список товаров с ценами и где-то будет стоять точка, а где-то нет -- возникнет коллизия. Плюсом отказа от угадывания является и ускорение обработки данных парсером.
Ну да, отправитель и принимающая сторона могут договориться о каких-то своих правилах и понимать друг-друга в частном случае. Однако язык обмена данными подразумевает возможность нормальной интерпретации данных и неподготовленной стороной. По идее они могут взять стандартный парсер, который проверит синтаксис и при отсутствии ошибок переведет всё в абстрактное дерево, а затем уже можно конвертировать в привычный джейсон или что иное, но эффективнее как раз оперировать данными напрямую из абстрактного представления.
В данном примере цена= 1200 rub абсолютна валидна в UNO, такое представление называется спаренное значение, состоящее из величины и единицы её измеряющей.
А вот мне не хотелось бы вникать в множество форматов. Мне кажется можно оставить CSV(TSV), XML, чистый JSON, UNO, возможно ещё какие-то узкоспециализированные типа Apache Parque -- в нём я не разбирался ещё и бинарные.
UNO можно без проблем использовать как замену экстремально минималистичному ENV и будет даже короче, можно не проставлять кавычки для текстовых значений.
Вроде как
Rub(1200)иGrams(650)невалидно. В RON это валидно, только если это именованные Tuple Struct или Enum-варианты. Если это просто текст, нужны кавычки. Да и прочее вызывает сомнение. Скорее всего код будет выглядеть так:Но я не специалист, настаивать не буду. К тому же и первый вариант мне нравится меньше, чем УНО.
Прошу прощения за безапеляционность. Пришлось намеренно ввести элемент провокационности исключительно для привлечения внимания, т.к. первая статья https://habr.com/ru/articles/1075348/ прошла незаметно. Что касается сложности обусловленной мощностью функционала, это решено путём разделения на продвинутую и основную спецификацию UNO Core, в которой нет никаких модификаторов, импортов и прочего.
Это настолько предсказуемо и уже давно не смешно. Может быть нам всем следует отказаться от попыток что-то улучшить или вообще вернуться в докаменный век, стать животными не умеющими использовать орудия труда?
На Трее даже близко не похож, в нём нет делителей и слеши:
user
name \Jin
age \35
Когда разрабатывал, изучал XML, JSON, TOML, YAML. Потом уже начал делать углубленный обзор всего имеющегося наследия. https://uno.mudrium.ru/o_proekte/preimuschestva/obzor_yazyikov.html
Кстати, если не ошибаюсь, мы с Дмитрием как-то очень-очень давно по скайпу общались, правда не на эту тему.
Борюсь с этим в зародыше. Во-первых, есть 3 уровня спецификации: Core -- самая простая, осилят абсолютно все и для большинства случаев может и достаточно. Advanced уже полноценный механизм, но всё ещё однопроходный быстрый парсер. Правил чуть больше, но однозначно понятные. И Extremum -- это уже узкоспециализированная редко используемая более медленная штука, обычных пользователей она не затронет. Сейчас дописываю вторую часть статьи, думаю станет яснее.
Извиняюсь. Работаю на локале -- статический сайт постоянно переконвертирую из Марквана, не глядя скопировал ссылку. Вот верная: https://uno.mudrium.ru/o_proekte/preimuschestva.html
Спасибо за информацию. Про Universal Network Objects не знал. Но менять название не буду. Понятие нотации гораздо шире узкоспециализированной программы, поэтому аббревиатура от UNderstandable UNiversal NOtation of Objects здесь будет полезнее.
По поводу отличий от YAML, здесь побольше информации http://127.0.0.1:5500/o_proekte/preimuschestva.html
В следующей части подробнее расскажу об иных аспектах языка UNO и разница с YAML будет заметна "невооружённым" глазом.
Не уверен, что понял посыл статьи. Можете кратко сформулировать ключевую мысль? Или у вас есть какие-то собственные решения и вы к ним подводите?
И его тоже рассматривал в самом начале. Но он также был недостаточно широк и пересекался с символами, которые могут встретиться в обычном тексте.
Спасибо большое. Про пользователей задумывался, но на всё времени не хватает.
Джетбрейнс раньше пользовался, но потом они ограничили регион пользования. С подсветкой кода не должно быть сложно. Если вдруг вам захочется её сделать, то можете взять все регулярки из подсветки для ВСКода и скормить нейросетке. Даже бесплатная Джемини должна справиться. У меня не скоро руки до этого дойдут. А отрисовка на лету это вы имеете в виду чтобы мгновенно всё переводилось в html и можно было наблюдать результат в браузере? Что-то я даже не подумал что это возможно, а похоже идея рабочая.
Дело в том, что при создании Марквана я абстрагировался от веб-отрасли. Была задача создать абстрактное представление не виртуального, а практического книгоиздания (естественно со всеми выгодами гиперссылок и кода). Есть мысли определенным образом переструктурировать информацию, выделив всё что есть полезного у человечества, отсеив некачественное и мусор. Но боюсь, задача усложняется с каждым днём :-)
Что касается технологий. Статический веб-сайт может быть весьма функционален. Посмотрите здесь https://markvan.mudrium.ru/osnovnaya_spetsifikatsiya/vklyucheniya/tehnicheskie.html есть включения с формулами, диаграмами, нотами, картами. Это всё яваскрипт. Я ещё во второй версии не успел сделать демку (в первой была) -- там был онлайн-редактор, где вы могли побаловаться вводом марквана и одновременным его преобразованием в ХТМЛ.
Кроме того, не так уж и сложно реализовать даже поиск по сайту.
Если добавлять в статический сайт электронную коммерцию, то с этим сложнее. Пока не размышлял. Придётся вероятно встраивать виджеты от банков. Есть, конечно и сервисы встраивающие процессинг магазина в сайт, когда-то был Эквид, сейчас не знаю.
Ну а стили вы можете вообще какие заблагорассудится вставлять.
Т.е. есть папка с вашим контентом, а есть папка с темой и конвертер всё это объединяет в готовый сайт.
Пришлось чуть усложнить. Необходимо было заложить гораздо больше смыслов чем в маркдовн и в хтмл. Да и веб в этом проекте вторичен, задачи у стандарта иные (но об этом не в ближайшее время).
На самом деле маркван запоминается легко, если понять общие принципы и у пользователя есть реальная задача.
Спасибо. Особо продвигать не планирую, это пока инструмент для решения своих задач, ну и проверка себя на креативность. Сейчас работаю над более фундаментальным проектом. Как закончу, может и вернусь к этому.