Comments 6
Чем это лучше описания на yaml, для которого достаточно создать нужную json-cхему?
Читаемый
Легко передавать людям, не знакомым с нотацией
Может содержать markdown
Верифицируемый
Не надо создавать специальное приложение для цветовой разметки текста, т.к. есть куча сред, которые уже это умеют, и даже умеют в подсказку на основе схемы
Имеет фатальный недостаток
Пытался в этом направлении думать, остановился на таких доводах (могу быть не прав, такое часто случается, поправьте меня пожалуйста):
Тип объекта в случае xml указывается в имени тэга, а в случае json или yaml нужно выносить его отдельный атрибут + имя объекта не уникально в пределах одного уровня вложенности. В совокупности это мне показалось не интуитивным, в том числе с точки зрения реализации набора с автодополнением. Ну то есть, если первое слово в строке это указание на тип, то в тот момент, когда система ожидает ввод типа мы просто предлагаем пользователю выбрать нужное имя и оно же печатается в редактор. А если тип указывается как атрибут, то возникают вопросы по дизайну (в связке с эргономикой) - не смог их решить.
Разделители для атрибутов в yaml это переносы строк => визуально сложно читать (ориентировался исключительно на свои ощущения). Ниже запись в ямл-подобном синтаксисе с игнорированием требования к уникальности имени объекта (вопрос с неуникальностью можно решить добавлением "-", то есть использованием неименованных списков, не стал записывать). Возможно, у меня просто нет глубоких знаний о фичах ямл, исходил из того что описание на нем будет выглядеть примерно так (ниже такое же описание как в примере в статье, для демонстрации читаемости):
процесс:
имя: Примерный процесс
дорожки: роль пользователя
событие:
расположение: начальное
задача:
текст: начать делать процесс
тип: ручная
событие:
тип: условие
текст: я устал
расположение: промежуточное
шлюз:
тип: эксклюзивный
ветка:
текст: да
задача:
текст: вызвать подмогу
тип: пользователь
событие:
прерывающее: нет
расположение: промежуточное
генерирующее: да
тип: сигнал
текст: включена система оповещения
задача:
тип: сервисная
текст: запустить протокол психологической помощи
событие:
тип: время
текст: получены цйенные указания
ветка:
текст: нет
задача:
тип: ручная
текст: продолжать трудиться
событие:
тип: время
расположение: промежуточное
задача:
тип: пользователь
текст: отчитаться о выполненной работе
событие:
расположение: завершающееПонимаю что плохой аргумент, но в рамках каприза: двоеточие в русской раскладке нужно набирать через shift.
Про фатальный недостаток, допускаю что он есть, можете подсветить пож-та?
Тип объекта в случае xml указывается в имени тэга, а в случае json или yaml нужно выносить его отдельный атрибут
Так же, как у вас: "процесс" = это тип объекта, и он стоит в начале описания объекта. Или вы о чем?
Ну то есть, если первое слово в строке это указание на тип, то в тот момент, когда система ожидает ввод типа мы просто предлагаем пользователю выбрать нужное имя и оно же печатается в редактор. А если тип указывается как атрибут, то возникают вопросы по дизайну (в связке с эргономикой) - не смог их решить.
атрибут "тип" определяется в схеме с перечнем (enum) допустимых типов, тогда редактор предложит значение из перечня
+ имя объекта не уникально в пределах одного уровня вложенности.
Поскольку yaml - это тот же json, то нельзя в одном объекте иметь одинаковые ключи.
То есть вот так нельзя:
процесс:
состояние:
задача:
состояние:
задача:Можно вместо объекта сделать массив:
процесс:
- состояние:
задача:
- состояние:
задача:И, на мой взгляд, это более читаемое, т.к. состояния и задачи четко сгруппированы в отдельные элементы, каждый элемент списка имеет описанную структуру, порядок элементов определяется списком
Про фатальный недостаток, допускаю что он есть, можете подсветить пож-та?
https://yandex.ru/search/?text=фатальный+недостаток
https://neolurk.org/wiki/Фатальный_недостаток
https://www.rsdn.org/forum/dotnet/8558237.hot
https://ru.wikipedia.org/wiki/Синдром_неприятия_чужой_разработки
Да, спасибо за замечание.
По использованию массивов вместо именованных объектов размышлял (в комменте выше писал об этом), мне показалось что писать ямл с таким допущением сложнее, чем разметку из примера, и читать, в свою очередь, тоже сложнее, потому что она занимает больше места по вертикали и мозгу нужно как то интерпретировать черточки и отступы. Плюс еще есть аргумент, которые писал выше про указание типов объектов (задача/событие/шлюз и т.п.) в свойствах сущностей а не в тэгах, как в xml.
Ну то есть вместо
процесс
задача .атрибут1 значение .атрибут2 значение
событие .атрибут1 значение .атрибут2 значениенужно будет написать
процесс:
- тип: задача
атрибут1: значение
атрибут2: значение
- тип: событие
атрибут1: значение
атрибут2: значениеОднако, вероятно, я не прав. Записал себе на развитие все таки сделать ямл.
По велосипедам - каюсь, грешен. Даже в названии статьи попытался обыграть "yet another" :) Мне действительно показалось что есть какие то улучшения, поэтому сделано то что сделано.
Идея красивая, чем-то напоминает Mermaid, но для BPMN.
Если предполагается формировать текстовое описание вручную, то для правильного форматирования нужна среда с IntelliSense и валидацией полученного текстового файла.
Иначе, не зная синтаксиса и не получая подсказок, процесс будет сплошная боль.
Если же вы предполагаете формировать текстовый файл на основании формочек, как в примере с 1С, то формат может быть лучше сделать более машиночитаемым, например JSON.
Спасибо! Да, похоже на Mermaid или на PlantUML (вдохновлялся PlantUML).
Попытался сделать улучшение опыта в части написания/чтения самой разметки, а для синтаксиса сделал простенький редактор, он предоставляет подсветку и контекстную подсказку с автодополнением.
Ну то есть работает как везде: начинаем писать - под курсором появляется менюшка в которой выбраны варианты, подходящие с точки зрения ожидаемых типов токенов (например, если пишем имя атрибута для тэга "событие", то будут предложены все допустимые имена атрибутов этого тэга). Мы можем дописать руками или выбрать вариант и нажать "Tab" - произойдет автодополнение.
Выглядит так:
Если же вы предполагаете формировать текстовый файл на основании формочек, как в примере с 1С, то формат может быть лучше сделать более машиночитаемым, например JSON.
Пока что разметка сохраненных схем и формочек хранится и в JSON и "сырым" введенным текстом, но сам текст из формочек не генерируется, только из ручного ввода (как дойдут руки, планирую добавить чтобы генерировался). Выше в статье рисовал схемку, см. ниже: то что пунктиром - не работает. То есть если пользователь сделал форму руками в граф редакторе то текстового описания на нее не будет, только JSON, а если сгенерировал по текстовому описанию, то будет сохранено и оно и JSON.
Еще один язык разметки для аналитиков