DRAKON.SU

Чем объективно хуже использование уникальных ID элементов и связей по ID? Формат с использованием ID получается проще, при желании можно конвертировать потом во что угодно... поростым как полено конвертором

Я применял ID для икон и пришёл к выводу, что это лишняя сущность.

Например сравните:

Справа от иконы Вопрос находится икона Действие с ID 17.
и
Справа от иконы Вопрос находится икона Действие.

Ну и какая мне разница, у иконы Действие ID 17 или "тридцать четыре тысячи семьсот восемьдесят девять" ? : )

Насчёт проще, сомневаюсь. Пока у меня сложилось другое мнение.

Не могли бы Вы привести пример возможной сложности при конвертации из моего формата?
Во что нужно конвертировать?

А Вы просто покажите код для чтения Вашего формата.

Это такой новый тип разводки? : )
Я пока не планирую делать исходники open source : ), в отличии от ДАР формата.



Я так понял, по существу (объективно : ) пример сложности найти сложно? : )

Непонятно, что смущает?
Попозже попробую изобразить нечто вроде алгоритма разбора.

Зачем нужен ОТКРЫТЫЙ формат, если способ его разбора понятен только самому автору? Можно и не открывать формат в таком случае, т.к. смысла в его "открытости" будет мало.
Или это такой новый тип разводки?
Такой формат и ДАРом не нужен...

Поддерживаю!

Не вижу связи между открытым форматом и каким-то незначительным исходным кодом его реализующим.

А вот алгоритм конвертации, например, из ДАР в DRT и обратно можно было бы и разобрать на форуме. Наверно было бы полезно. Ну или ДАР в Pascal или ещё куда : )



Господа-товарищи!
На форуме неоднократно поднимался вопрос о нужности-необходимости открытого формата хранения дракон-схем.

Я предложил свой вариант, который попытаюсь защитить : )
Возможно я совершенно не прав и несу "галиматню", но пока я этого не вижу.

Опубликуйте своё видение формата, с удовольствием поучаствую в обсуждении.

Лично я с ID в качестве связующего средства уже поупражнялся и отказался от него.
Кроме того, конструкции, использующие ID некрасивы : )

"Вместо рыбки лучше дать удочку" (С)

Ниже картинки, на которых я попробовал объяснить как может происходить связывание элементов, извлекаемых из XML файла, содержащего дракон-схему в формате ДАР.

Алгоритм



Пояснения на примере абстрактного слепыша



Тот же слепыш (для наглядности)

Несколько поясню свои мысли об универсальном XML-формате представления процедурных языков.
Или управляющего графа программы. Правда, расширенного передачами управления через временной интервал, и параллелизмом.



Далее. Помимо <derevo> соответствующего "шампурам" Паронджанова, можно использовать.


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


Подобное представление можно визуализировать разными способами (сверху-вниз, слева-направо), используя различные графические примитивы для обозначения действий и условий ("иконы" по Паронджанову), с разбиением на листы различного размера.

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

Призываю Степана Митькина и Геннадия Тышова подумать о поддержке примерно подобного формата "высокого уровня" в своих редакторах.

Спасибо, посмотрю.

Ярослав, ещё раз спасибо!
Ваши сообщения помогают мне продираться через дебри XML : )

Поясните, пожалуйста, вот эти ID используются только для указания связей между элементами при их извлечении из XML файла или и в дальнейшем, уже в программном коде?

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

Например, есть в одном пространстве (листе, сцене) две схемы, которые содержат элементы с уникальными ID (в пределах одного сеанса работы с редактором) и одна в XML файле (результат предыдущей работы редактора). Необходимо импортировать схему из XML файла в то же пространство, где находятся две другие схемы. Появляется конфликт ID, которые нужно как-то устранить.

Подобная ситуация возникает и если поддерживать уникальность ID в пределах одной схемы. Например, при копировании элементов из одной схемы в другую.

Если активно работать с одной и той же схемой, то, в результате копи-пастов, удалений-добавлений порядковый номер новых ID стремится в бесконечность : ) и время от времени их нужно как-то нормализовывать, ужимать или следить за выбывшими номерами. В общем, головная боль на ровном месте.

После ваших сообщений закралось сомнение, может я в очередной раз чего не понимаю : ) и всё делается гораздо проще?

Тут штука в том, что у Вас, как можно понять, нумерация линейная вообще в пределах документа. А целесообразна иерархическая согласно структуризации возможных схем. О чём и говорил здесь: viewtopic.php?p=72208#p72208. Кстати, там ещё не упомянут индекс всей схемы (вводится, скажем, здесь в каждом заголовке). Об этом же и TAU здесь: viewtopic.php?p=72328#p72328. Да, кстати, и декларативные схемы, и связывание их с императивными (для конкретного исполнителя) тоже надо представить в формате постепенно... для чего его принципы должны допускать расширение...

Да, я тоже эту мысль по Pure Builder оценил...

А связь как раз определяется заявленной открытостью формата - раз и предложением его как стандарта - два. То, что показано в этом посте - это спецификация (где-то даже доматематическая) - вернее, её основа, пожалуй. О важности математической (м.б. и нестрогой в смысле Герасименко ) можно судить по обсуждавшемуся выше - есть матмодель - понятно, как с толком использовать те же индексы.
Значимость же кода реализации - в определении формата уже на следующем уровне. Чтобы не было вольностей и несовместимостей. И та форма публикации, как в этой выдержке - она не зря...

Другой вопрос - как реализацию описывать? Тут совершенно необязательно раскрывать свой код на конкретном языке. Есть, скажем, такой язык, специально созданный Виртом в т.ч. "для публикации алгоритмов и программ"... подскажу, что название конференции от него образовано... Вот на нём процессы разбора описать можно...

Не могли бы Вы привести (если сочтёте возможным) наглядный, простой, конкретный пример. ID схем текущего сеанса работы, ID схем предыдущей работы, хранящихся во внешнем файле. Если ID никогда не повторяются - каким механизмом это обеспечивается, если повторяются - как ими оперировать при операциях импорта, копирования, вставки.

По Вашим ссылкам разобраться не смог : (

Даже если делать нумерацию каждого элемента уникальной в пределах всего мира это не избавляет от проблем.

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

Ну, значить, конкретный пример (извиняюсь, что общая идея и текстом будем считать, что это я так тоже не раскрываю своего полностью ). Заодно для начала ответ на вполне резонное удивление. Да, для каждой отдельно взятой схемы (одного структур-класса - здесь мы о маршрутных) возможно совпадение внутрисхемных индексов с другой схемой. Но с учётом схемных и вышестоящих частей индекса - совпадения не будет.

Так вот. Выделили мы фрагмент (размеченный индексами). И захотели его скопировать. При структурном ограничении (скажем, как у Тышова для выделения было) что это значит? Что выделяется законченная конструкция. Что с ней делаем? Вставляем как атом. А что у нас на месте вставки? Тоже индексы вершин, соседних с используемым ребром ввода. Вот они и будут производящими для новых индексов вставляемого атома. Я же говорил, что любые состоявшиеся изменения структуры схемы требуют переиндексации (и обхода затронутой части схемы). И соответственно индексы изменяются "на лету" в целевой схеме (ну а в источнике, понятно, остаются неизменными ).

И вот тут мы лишний раз видим экономичность ограничения строго атомарными структурами. Если всё сводится ко вставке атома - какова область, требующая переиндексации? Всегда отдельно взятый графит-марш (по TAU - lineinyi_uchastok) в целевой схеме. Нужно провести нумерацию вершин на главной вертикали вставленного от "соседа сверху" - затем продолжить перенумерацию от "соседа снизу" до ближайшего соединителя/излома. Да если вставка нелинейная - согласовать иерархию групп нумерации во вставке с целевой схемой. И всё.
А если лианами оперируем? Тут уже нужно разыскивать верхние/нижние границы вновь образуемого "лианного/адресного макроблока" (по "доминантности/рецессивности" - см. правила графит-метода для структур схем). А потом уже всё переобходить в этих границах (м.б. с какими-то оптимизациями - но они обнаруживаются не просто так, а на базе терграф-законов - хотя бы и понятых также интуитивно из построений)...

А любые лишние розыски - это увеличение времени ответа редактора... не так ли?.. Т.е. экономичность создаёт условия для эргономичности...

Удивления нет, есть непонимание : ) Зачем использовать индексы, если в любом случае их требуется переиндексировать. Какую такую волшебную нагрузку они несут : )?


Вот и я о том же. Отказ от ID ведёт к экономии ресурсов.

А вот для локального использования в XML файле, возможно и придётся использовать ID, для установления порядка следования : ) Что-то xsd какое-то громоздкое и на первый взгляд лишнее : )