DRAKON.SU https://forum.drakon.su/ |
|
ДАР формат. Он же DAR : ) https://forum.drakon.su/viewtopic.php?f=62&t=3943 |
Страница 1 из 4 |
Автор: | Ильченко Эдуард [ Среда, 18 Апрель, 2012 00:37 ] |
Заголовок сообщения: | ДАР формат. Он же DAR : ) |
У меня появились некоторые соображения : ) по поводу хранения дракон-схем и иже с ними в XML файле. Некоторые моменты проистекают сугубо из моей реализации раскладки графа дракон-схемы и, возможно, излишни или требуют правки. Буду рад советам и критическим замечаниям : ) ДАР — Дракон АРхив; DAR – Drakon ARchive; Кодировка, наверное, должна быть UTF8. Чтобы файлом можно было без проблем пользоваться в различных системах. Формат должен содержать не только дракон-схемы, но и другие сущности (картинки, тексты, таблицы) с возможностью их группирования. А поскольку хотелось бы, чтобы формат поддерживал все офисные возможности, то описание займёт ~1000 страниц : ) Например, описание формата Open Document что то вроде 800 страниц, если мне не изменяет память, ну и ДАР ещё страниц 200 : ) Но начну с малого … не формально ... И сразу же первая сложность: хранить только граф схемы или и какие-то свойства отображения (масштаб, смещение). Учитывая что этот формат мне нужен под конкретный редактор, то опишу как это видится мне. Двумя косыми чертами обозначены примечания, которые в XML файле не используются. По ходу изложения будет наблюдаться болтанка в применяемых обозначениях, просто пока не устоялось : ) Код: <scena name=”%имя_сцены”> <geometry> <xmin>%координата_xmin</xmin> <xmax>%координата_xmax</xmax> <ymin>%координата_ymin</ymin> <ymax>%координата_ymax</ymax> </geometry> <scheme kind=”drakon” version=”%версия” type=”%type”> %описание_схемы_примитив или %описание_схемы_силуэт </scheme> // на одной сцене могут присутствовать несколько схем </scena> %type primitive silhouette Куда-то ещё нужно viewport'ы прописать, через которые схема просматривается, а они могут находиться на разных страницах создаваемого документа … Как сделать у себя в программе, вроде понятно, а вот как сделать правильно и универсально в XML файле не совсем ясно ... Код: %описание_схемы_примитив <branch> <item name=”begin”> // обязательный элемент %содержание_begin </item> %тело_примитива <item name=”end”> %содержание_ end // обязательный элемент </item> </branch> %описание_схемы_силуэт <branch> // первая, самая левая ветка <item name=”begin”> // обязательный элемент только для первой ветки %содержание_begin </item> %тело_примитива // секция_инициализации %тело_ветки </branch> <branch> // вторая и последующие ветки <item name=”entry”> // необязательный элемент %содержание_ entry </item> %тело_примитива // секция_инициализации %тело_ветки </branch> <branch_last hidden=”no”> // последняя ветка <item name=”entry”> // необязательный элемент %содержание_ entry </item> %тело_примитива // секция_инициализации ветки <item name=”name_branch”> %содержание_name_branch </item> %тело_примитива // секция_финализации схемы <item name=”end”> %содержание_ end </item> </branch_last> %тело_примитива // состоит из сочетаний проходных и переключающих элементов // и имеет только один маршрут выхода %проходной_элемент %переключающий_элемент %тело_ветки <item name=”name_branch”> %содержание_name_branch </item> // состоит из сочетания проходных и переключающих элементов // имеет несколько маршрутов выхода // заканчивающихся элементом «икона Адрес» %проходной_элемент %переключающий_элемент_силуэта // отличается от примитивного : ) // возможным наличием иконы Адрес в конце маршрутов %проходной_элемент %проходная_икона или %контакт %проходная_икона // все иконы кроме Вопрос и Выбор %контакт <top_join/> // точка входа в цикл <bottom_join value=”%число”/> // точка схождения маршрутов, // value – кво правых маршрутов, входящих в точку <right_join/> // точка входа на маршрут от иконы Вопрос слева %переключающий_элемент %переключающая_икона <route> // самый правый маршрут, для Вопроса единственный // для Выбора — кво икон Вариант минус единица // состоит из сочетания проходных, переключающих // и связывающих элементов %проходной_элемент %переключающий_элемент %связывающий_элемент </route> %переключающая_икона <item name=”question”> %содержание_question </item> или <item name=”choice”> %содержание_choice </item> %связывающий_элемент <top_connect/> // подключение к top_join или <right_connect/> // подключение к right_join или <bottom_join/> // подключение к bottom_join %переключающий_элемент_силуэта %переключающая_икона <route> // самый правый маршрут, для Вопроса единственный // для Выбора — кво икон Вариант минус единица // состоит из сочетания проходных, переключающих // и связывающих элементов // может заканчивающихся элементом «икона Адрес» %проходной_элемент %переключающий_элемент_силуэта // отличается от примитивного : ) // возможным наличием иконы Адрес в конце маршрутов %связывающий_элемент </route> Основной тэг — item <item name=”%item”> %содержание_%item </item> %item begin, action, end, variant, comment … // английские названия икон top_join, right_join, bottom_join // точки контакта top_connect, right_connect, bottom_connect // связывающие элементы %содержание_%item %общая_часть // до конца ещё не ясно, что войдёт в общую часть %уникальная_часть Для примера икона Действие: %содержание_action <properties> <style>%style</style> <pen_width>%pen_width</pen_width> <pen_color>%pen_color</pen_color> <brush_color>%brush_color</brush_color> <x>%x</x> // смещение иконы в координатах вертикали // на которой находится элемент <y>%y</y> // в координатах вертикали, рассчитывается автоматически <w>%w</w> // ширина <h>%h</h> // высота // shift-параметры зависят от реализации редактора. // местоположение элементов рассчитывается автоматически, // затем вносится коррекция, если требуется <shift_down_manual>%shift_down_manual</shift_down_manual> <shift_height_manual>%shift_height_manual</shift_height_manual> // здесь можно было бы задать произвольный контур и другие свойства </properties> Вложение: r1.png [ 3.07 КБ | Просмотров: 17944 ] Код: // комментарий внутри элемента <comment_plain>comment_plain1</comment_plain> // значимый текст внутри элемента <text_plain>text_plain1</text_plain> // ещё один комментарий <comment_plain>comment_plain2</comment_plain> // ещё текст <text_plain>text_plain2</text_plain> // ещё комментарий <comment_plain>comment_plain3</comment_plain> // здесь возникает вопрос КАК ОПИСЫВАТЬ ФОРМАТИРОВАННЫЙ ТЕКСТ? // может как в Qt в формате HTML? // т. е. теги text_plain и text_html содержат один и тот же текст, // но разное форматирование Вложение: r2.png [ 1.97 КБ | Просмотров: 17944 ] Код: <leftward>%leftward_item</leftward> // элемент слева <dextral>%dextral_item</dextral> // элемент справа Вложение: r3.png [ 3.14 КБ | Просмотров: 17944 ] Код: /%содержание_action закончено Конечно, представленное описание далеко не полное : ) Я так думаю, что сначала нужно разобраться с «костями», а потом уже на них нарастить «мясо» : ) Перейду к «тазо-бедренным суставам» : ) Иконы Вопрос и Выбор принадлежат к переключающим элементам. Все правые маршруты от таких элементов оформляются тегом route, начиная с самого правого маршрута. Самый верхний route – самый правый маршрут. икона Вопрос Код: <item name=”question”> %содержание_question </item> %содержание_question <properties>Какие-то свойства</properties> <context_right>no</context_right> // правый маршрут в контексте отрицания <text_plain>Какой-то вопрос?</text_plain> <leftward>Что-то слева</leftward> // справа не может быть никаких икон <text_right>Ответ на вопрос для правого маршрута</text_right> <text_bottom>Ответ на вопрос для нижнего маршрута</text_bottom> Пример 1 Вложение: r3.png [ 3.14 КБ | Просмотров: 17944 ] Код: <scheme kind=”drakon” version=”0.0.001” type=”primitive”> <branch> <item name=”begin”> <text_plain>Начало</text_plain> </item> <item name=”action”> <text_plain>ДЕЙСТВИЕ</text_plain> <leftward> <item name=”pause”> <text_plain>Левый элемент для ДЕЙСТВИЯ</text_plain> <leftward> <item name=”left_comment”> <text_plain> Левый элемент для ПАУЗЫ </text_plain> </item> </leftward> </item> </leftward> <dextral> <item name=”right_comment”> <text_plain>Правый элемент для ДЕЙСТВИЯ</text_plain> </item> </dextral> </item> <item name=”end”> <text_plain>Конец</text_plain> </item> </branch> </scheme> Пример 2 Вложение: r4.png [ 7.19 КБ | Просмотров: 17944 ] Код: <scheme kind=”drakon” version=”0.0.001” type=”primitive”> <branch> <item name=”begin”> <text_plain>Начало</text_plain> </item> <top_join/> <item name=”choice”> <text_plain>Выбор</text_plain> </item> <route> <item name=”variant”> <text_plain>V2</text_plain> </item> <right_join/> <bottom_connect/> </route> <item name=”variant”> <text_plain>V1</text_plain> </item> <item name=”question”> <context_right>no</context_right> <text_plain>Q1</text_plain> <text_right>Нет</text_right> <text_bottom>Да</text_bottom> </item> <route> <item name=”question”> <context_right>no</context_right> <text_plain>Q4</text_plain> <text_right>Нет</text_right> <text_bottom>Да</text_bottom> </item> <route> <right_connect/> </route> <bottom_connect/> </route> <item name=”question”> <context_right>no</context_right> <text_plain>Q2</text_plain> <text_right>Нет</text_right> <text_bottom>Да</text_bottom> </item> <route> <item name=”action”> <text_plain>D1</text_plain> </item> <bottom_connect/> </route> <bottom_join value=”2”/> <bottom_join value=”1”/> <item name=”question”> <context_right>no</context_right> <text_plain>Q3</text_plain> <text_right>Нет</text_right> <text_bottom>Да</text_bottom> </item> <route> <top_connect/> </route> <item name=”end”> <text_plain>Конец</text_plain> </item> </branch> </scheme> Пример 3 Вложение: Код: <scheme kind=”drakon” version=”0.0.001” type=”silhouette”> <branch> <item name=”begin”> <text_plain>- Начало -</text_plain> </item> <top_join/> <item name=”question”> <context_right>yes</context_right> <text_plain>Q1</text_plain> <text_right>Да</text_right> <text_bottom>Нет</text_bottom> </item> <route> <top_connect/> </route> <item name=”name_branch”> <text_plain>A</text_plain> </item> <item name=”choice”> <text_plain>Выбор</text_plain> </item> <route> <item name=”variant”> <text_plain>V2</text_plain> </item> <bottom_connect/> </route> <item name=”variant”> <text_plain>V1</text_plain> </item> <bottom_join value=”1”/> <item name=”address”> <text_plain>B</text_plain> </item> </branch> <branch> <item name=”entry”> <text_plain>- вход -</text_plain> </item> <item name=”question”> <context_right>no</context_right> <text_plain>Q2</text_plain> <text_right>Нет</text_right> <text_bottom>Да</text_bottom> </item> <route> <bottom_connect/> </route> <bottom_join value=”1”/> <item name=”name_branch”> <text_plain>B</text_plain> </item> <item name=”action”> <text_plain>D1</text_plain> </item> <item name=”address”> <text_plain>B</text_plain> </item> </branch> <branch_last hidden=”no”> <item name=”name_branch”> <text_plain>Финиш</text_plain> </item> <item name=”end”> <text_plain>Конец</text_plain> </item> </branch_last> </scheme> P.S. Если где-то ошибся, говорите, поправлю. Добавлено 19.04.12 14:07 Свёртка блока — последовательность элементов прячется в одну икону. Такими иконами могут быть: Действие, Вопрос, Выбор. При этом в икону Действие сворачивается (прячется) блок элементов, расположенный ниже самой иконы Действие, а в иконы Вопрос, Выбор сворачивается блок расположенный выше. Нужно как-то выделять иконы, содержащие свёртку. Пока выделяю двойным контуром. Код: <convolution> <![CDATA[%тело_примитива]]> </convolution> Пример 4. Вложение: s1.png [ 3.68 КБ | Просмотров: 17779 ] Код: // пример 4 без свёртки <scheme kind=”drakon” version=”0.0.001” type=”primitive”> <branch> <item name=”begin”> <text_plain>Начало</text_plain> </item> <item name=”action”> <comment_plain>Что-то там делается</comment_plain> </item> <top_join/> <item name=”question”> <context_right>no</context_right> <text_plain>В1</text_plain> <text_right>Нет</text_right> <text_bottom>Да</text_bottom> </item> <route> <top_connect/> </route> <item name=”action”> <text_plain>Д1</text_plain> </item> <item name=”end”> <text_plain>Конец</text_plain> </item> </branch> </scheme> // пример 4 со свёрткой <scheme kind=”drakon” version=”0.0.001” type=”primitive”> <branch> <item name=”begin”> <text_plain>Начало</text_plain> </item> <item name=”action”> <comment_plain>Что-то там делается</comment_plain> <convolution> <![CDATA[ <top_join/> <item name=”question”> <context_right>no</context_right> <text_plain>В1</text_plain> <text_right>Нет</text_right> <text_bottom>Да</text_bottom> </item> <route> <top_connect/> </route> <item name=”action”> <text_plain>Д1</text_plain> </item> ]]> </convolution> </item> <item name=”end”> <text_plain>Конец</text_plain> </item> </branch> </scheme> Пример 5. Вложение: s2.png [ 4.75 КБ | Просмотров: 17779 ] Код: // пример 5 без свёртки
<scheme kind=”drakon” version=”0.0.001” type=”primitive”> <branch> <item name=”begin”> <text_plain>Начало</text_plain> </item> <item name=”action”> <text_plain>Д1</text_plain> </item> <item name=”action”> <text_plain>Д2</text_plain> </item> <item name=”question”> <context_right>no</context_right> <comment_plain>Это самый главный вопрос в алгоритме?</comment_plain> <text_right>Нет</text_right> <text_bottom>Да</text_bottom> </item> <route> <bottom_connect/> </route> <bottom_join/> <item name=”end”> <text_plain>Конец</text_plain> </item> </branch> </scheme> // пример 5 со свёрткой <scheme kind=”drakon” version=”0.0.001” type=”primitive”> <branch> <item name=”begin”> <text_plain>Начало</text_plain> </item> <item name=”question”> <context_right>no</context_right> <comment_plain>Это самый главный вопрос в алгоритме?</comment_plain> <text_right>Нет</text_right> <text_bottom>Да</text_bottom> <convolution> <![CDATA[ <item name=”action”> <text_plain>Д1</text_plain> </item> <item name=”action”> <text_plain>Д2</text_plain> </item> ]]> </convolution> </item> <route> <bottom_connect/> </route> <bottom_join/> <item name=”end”> <text_plain>Конец</text_plain> </item> </branch> </scheme> |
Автор: | Дмитрий Дагаев [ Среда, 18 Апрель, 2012 08:11 ] |
Заголовок сообщения: | Re: ДАР формат. Он же DAR : ) |
У меня понимание такое: ДРАКОН-формат должен содержать как схему для отрисовки, чтобы загружать редактором/вьюером, так и содержательную информацию (например, для кодогенератора). Поэтому 3 главных элемента должны быть: <item id='123' x='' y='' ..> - это как у Вас, но с id и с координатами <link from_id='123' to_id='456' ...> - логическая связь item'ов <line><x='612'><y='231'><x='612'><y='299'>..</line> - соединительная линия редактора Для отрисовки использовать item, line. Для обработки контента item, link. |
Автор: | Ильченко Эдуард [ Среда, 18 Апрель, 2012 12:21 ] |
Заголовок сообщения: | Re: ДАР формат. Он же DAR : ) |
Дмитрий Дагаев писал(а): Поэтому 3 главных элемента должны быть: … <item id='123' x='' y='' ..> - это как у Вас, но с id и с координатами … Самый первый вариант моего «построителя дракон-схем» : ) так и работал. Каждая икона имела свой id и связи использовали ссылки на эти id. В этом есть неудобство. Нужно следить за уникальностью номеров. Когда схем много, они большие и активно пользуется копипаст, отвлекаться на модификацию номеров оказалось совершенно лишним. Сейчас у меня граф схемы раскладывается прекрасно без использования уникальных id. Имхо, id может быть полезен только при обсуждении схемы, т. е. для человека. Машине он не нужен. Положение в схеме (читать "в сцене") задаётся координатами главного маршрута. Для икон полезна только координата x относительно вертикали (используется для «ручного» смещения влево-вправо). От неё можно отказаться, если, например, смещение задавать в %. Дмитрий Дагаев писал(а): … <link from_id='123' to_id='456' ...> - логическая связь item'ов … Логическая связь обеспечивается элементами контакта и связывания. См. Пример 2. Если соблюдать определённый порядок обработки вертикалей, то каждому элементу join однозначно будет соответствовать элемент connect. В результате отпадает необходимость в id для организации логических связей. У меня ветки обрабатываются слева направо, а боковые маршруты справа налево. Дмитрий Дагаев писал(а): … <line><x='612'><y='231'><x='612'><y='299'>..</line> - соединительная линия редактора … Хранить координаты линий нет необходимости. Координаты вычисляет редактор. Тег <branch/> содержит инфу об основном маршруте. Тег <route/> содержит инфу о боковом маршруте. |
Автор: | Роман М. [ Среда, 18 Апрель, 2012 13:31 ] |
Заголовок сообщения: | Re: ДАР формат. Он же DAR : ) |
Формат DAR уже забронирован. Смотри http://dar.linux.free.fr/ |
Автор: | Дмитрий Дагаев [ Среда, 18 Апрель, 2012 14:07 ] |
Заголовок сообщения: | Re: ДАР формат. Он же DAR : ) |
Ильченко Эдуард писал(а): Хранить координаты линий нет необходимости. Координаты вычисляет редактор. Тег <branch/> содержит инфу об основном маршруте. Тег <route/> содержит инфу о боковом маршруте. Хорошо, что Вы уже продумывали предлагаемый мной подход. Но я пока, что называется, не проникся, где-то в примере не до конца понятно. Считаю, что координаты и размеры нужно и вычислять, и менять с мышки редактора. Равно как и иметь таблицы с простым, по-возможности индексным (id)/адресным(имя+хэш-таблица) доступом. Однако буду внимательно читать, что Вы предлагаете. |
Автор: | Владислав Жаринов [ Среда, 18 Апрель, 2012 14:38 ] |
Заголовок сообщения: | Представление схем по Ильченко |
Ильченко Эдуард писал(а): ... Ну, "раз пошла такая пьянка..." (в смысле, конструктивная дискуссия о топологии устремлённых графов ) - всё-таки выложу "полуфабрикат", упоминавшийся здесь:Самый первый вариант моего «построителя дракон-схем» : ) так и работал. Каждая икона имела свой id и связи использовали ссылки на эти id. В этом есть неудобство. Нужно следить за уникальностью номеров. Когда схем много, они большие и активно пользуется копипаст, отвлекаться на модификацию номеров оказалось совершенно лишним. Сейчас у меня граф схемы раскладывается прекрасно без использования уникальных id. Имхо, id может быть полезен только при обсуждении схемы, т. е. для человека. Машине он не нужен. Положение в схеме задаётся координатами главного маршрута. ... Если соблюдать определённый порядок обработки вертикалей, то каждому элементу join однозначно будет соответствовать элемент connect. В результате отпадает необходимость в id для организации логических связей. У меня ветки обрабатываются слева направо, а боковые маршруты справа налево. Дмитрий Дагаев писал(а): … <line><x='612'><y='231'><x='612'><y='299'>..</line> - соединительная линия редактора … Хранить координаты линий нет необходимости. Координаты вычисляет редактор. Тег <branch/> содержит инфу об основном маршруте. Тег <route/> содержит инфу о боковом маршруте. Вложение: В итоге вещи, связанные со структурой, выразил несколько позже в графит-определениях здесь: http://grafit-basis.narod.ru/L3/grafit- ... l#GR-n1413. Ну а схему эту дорабатывать не стал. Потому там и терминология не совпадает с методом - так, "группа следования" в итоге стала графит-маршем/лианой.Но, м.б. из самой структуры разметки, а также применения нумерации можно что-то извлечь и для формата, и для его обработки... Т.е. разметка (как графа, конечно, а не нумерация по ГОСТ БС) нужна не только (и не столько) для человека... Теперь (учитывая и этот материал) - кое-какие мысли по результатам Эдуарда. Во-первых, можно понять, что он как раз переходит от топологической разметки к физической, чтобы делать то же самое. Т.е. координаты реперных точек линий и фигур используются для суждений в процессе обработки о структуре схемы и о её соответствии ограничениям. Во-вторых, в вычислении координат можно пойти дальше - исчислять и линии, и фигуры в шагах "размерной сетки" (на рисунке задана пунктирными линиями). И хранить в файле документа также отдельно физические (метрические/пиксельные) значения этих шагов (здесь в Правиле СЖ называемых ВШП и ГШП) и для элементов схем - их размеры уже в шагах. А функция отображения редактора, действительно, пусть вычисляет физические размеры/положения... В-третьих, насчёт порядка/соответствия для маршей/лиан. Разветвителю (join) и правда, по определению должен отвечать соединитель (connect). Но их относительное расположение будет разным (для марша на стволе схемы/ветки, лианы-скобы/ступени/плеча). Что по физике (в пикселях), что по логике (в осях). Кроме того, есть случаи схем с объединениями, когда иной раз можно считать (а при визуализации логики - нужно), что два и более рёбер-отводов с побочных выходов термовых развилок сходятся на пул бинарных соединителей, представляемых как единый мультисоединитель. Чтобы нельзя было вводить атомы в эти рёбра (это искажает логику). В-четвёртых, можно при описании сложных ветвлений пойти путём, логически намеченным Дейкстрой, а сформулированным для шампур-схем Рэйлвей Кагеном. Имеется в виду сказанное в этом посте (видимо, первая формулировка). Конкретно - в документе переключатель описывается также, как выбор Дейкстры в этом пункте, а для отображения детали скрываются как принято в шампур-методе (описано в этом пункте). Можно ещё кое-что обсудить для более укрупнённого представления о проекте, но это отдельно. |
Автор: | Владислав Жаринов [ Среда, 18 Апрель, 2012 14:59 ] |
Заголовок сообщения: | "Электронные проекты" по Ильченко |
Вот это существенно, если подняться с уровня отдельных схем на уровень документа/системы документов: Ильченко Эдуард писал(а): ... Во-первых, хорошо, что предлагается интегрировать с неким форматом машдоков - дабы не изобретать средства форматирования текста/таблиц/графики самих по себе. Да. интегрировать с этим ещё что-то - дело, наверное, не быстрое...Формат должен содержать не только дракон-схемы, но и другие сущности (картинки, тексты, таблицы) с возможностью их группирования. А поскольку хотелось бы, чтобы формат поддерживал все офисные возможности, то описание займёт ~1000 страниц : ) Например, описание формата Open Document что то вроде 800 страниц, если мне не изменяет память, ну и ДАР ещё страниц 200 : ) ... Во-вторых, о других сущностях. Считаю, группировка текста/таблиц/изображений/схем в документе могла бы идти на базе именно автофигур. Т.е. есть отдельные вершины, "накидываемые" на лист (их можно понимать как одновершинные схемы). И есть схемы, которые м.б. и связаны между собой в "модели". При этом группирование можно обеспечить, как описано здесь: viewtopic.php?p=64343#p64343. Т.е. группируем в специальной модификации силуэта (специализация гл. обр. в отображении), переходы по которому заменяют максимум гиперссылок в обычном тексте. И в формате тогда будет прописан более общий случай силуэта - примерно как здесь в Правиле 241 (но кое над чем в синтаксисе ещё думаю) - а для визуалов будет использоваться упрощённое определение. В перспективе надо продумать и связывание разных документов в "электронный проект"... с повторным использованием элементов... Да, говорил о том, как применялся XML для сходных целей (в этом посте про Путилина и Юрагова). |
Автор: | ==== [ Среда, 18 Апрель, 2012 15:25 ] |
Заголовок сообщения: | Re: ДАР формат. Он же DAR : ) |
Уже было - масштабный проект «Дракон и XML» http://forum.oberoncore.ru/viewtopic.php?p=66461#p66461 http://forum.oberoncore.ru/viewtopic.php?p=66867#p66867 Цитата: Четыре важных инициативы Ярослава Романченко
....... И, наконец, четвертая инициатива Ярослава – это масштабный проект «Дракон и XML». viewtopic.php?f=79&t=3627 |
Автор: | Дмитрий Дагаев [ Среда, 18 Апрель, 2012 15:36 ] |
Заголовок сообщения: | Re: ДАР формат. Он же DAR : ) |
Геннадий Тышов писал(а): Уже было - масштабный проект «Дракон и XML» Это Вы очень к месту напомнили. Для меня формат Я.Романченко более понятен. Кстати, в ИС ДРАКОН к какой-нибудь реализации конвертации схемы в XML и обратно Вы склоняетесь? |
Автор: | ==== [ Среда, 18 Апрель, 2012 15:40 ] |
Заголовок сообщения: | Re: ДАР формат. Он же DAR : ) |
Дмитрий Дагаев писал(а): Кстати, в ИС ДРАКОН к какой-нибудь реализации конвертации схемы в XML и обратно Вы склоняетесь? Нет, конвертирования в XML не планируется.Используется файл типа CSV - данные разделенные запятой. Вполне компактный и оправдавший себя. Формат файлов *.drt описан на форуме. Цитата: Для меня формат Я.Романченко более понятен. Файл хранения не предназначен для восприятия, содержание однозначно отображается и доступно в дракон-редакторе.Для обработки используются структуры данных в программе. Структуры данных в программе так же описаны. |
Автор: | Дмитрий_ВБ [ Среда, 18 Апрель, 2012 15:49 ] |
Заголовок сообщения: | Re: ДАР формат. Он же DAR : ) |
Я сейчас, Геннадий Николаевич, перестал следить за новыми версиями ваших форматов. Но по старой вопрос в том, что можно было бы сгенерить файлы данных для вашей среды, но проблема была в индексах элементов. Я не стал с этим разбираться. Если бы индексов эл-тов не было, то генерация файлов для ИС Дракон была бы делом техники. |
Автор: | ==== [ Среда, 18 Апрель, 2012 15:53 ] |
Заголовок сообщения: | Re: ДАР формат. Он же DAR : ) |
Дмитрий_ВБ, я помню Вы генерировали *.drt файл своей программой и он отображался в ИС Дракон. С индексами не сложно разобраться. Сейчас формат незначительно отличается от опубликованного |
Автор: | Ильченко Эдуард [ Среда, 18 Апрель, 2012 15:55 ] |
Заголовок сообщения: | Re: ДАР формат. Он же DAR : ) |
Роман М. писал(а): Формат DAR уже забронирован. Смотри http://dar.linux.free.fr/ Полагаю не забронирован, а используется ... Ничего страшного. У меня первоначален ДАР : ) |
Автор: | Владислав Жаринов [ Среда, 18 Апрель, 2012 21:02 ] |
Заголовок сообщения: | Ещё по ДАР формату : ) |
Ну, вот наконец и сделал выдержку: Вложение: Хотя источник не совсем новый - но, может статься, что-нибудь и сгодится... Ещё м.б. полезно учесть сказанное Усовым о графических языках в этом сообщении. Также непренебрежимы суждения Рэйлвей Каген о гармонизации с другими графическими языками в этом посте (как видно, Эдуард в чём-то этому следует). |
Автор: | Ильченко Эдуард [ Среда, 18 Апрель, 2012 21:06 ] |
Заголовок сообщения: | Re: ДАР формат. Он же DAR : ) |
Дмитрий Дагаев писал(а): Но я пока, что называется, не проникся, где-то в примере не до конца понятно. Считаю, что координаты и размеры нужно и вычислять, и менять с мышки редактора. Равно как и иметь таблицы с простым, по-возможности индексным (id)/адресным(имя+хэш-таблица) доступом. Задавайте вопросы. Попробую защитить, а заодно и лучше понять ДАР формат : ) Все координаты точно хранить не нужно. И без них всё работает, включая изменение положения икон мышкой. |
Автор: | Владислав Жаринов [ Среда, 18 Апрель, 2012 21:31 ] |
Заголовок сообщения: | ДАР формат. Некоторые итоги |
Что же можно сказать о перспективах разработки такого формата? Если кратко - то для целостности и масштабируемости нужно реализовать:
* схему типа "лист-силуэт" (шампур-силуэт также окажется её частным случаем); * связывание схем в систему-"модель", например, как показано здесь в Правилах 234-239 (частные случаи - через вызовы по вставкам и/или обмен сообщениями); * сборочное конфигурирование схем (через "ящики"-области). |
Автор: | Ильченко Эдуард [ Среда, 18 Апрель, 2012 21:36 ] |
Заголовок сообщения: | Re: Представление схем по Ильченко |
Владислав Жаринов писал(а): Теперь (учитывая и этот материал) - кое-какие мысли по результатам Эдуарда. Во-первых, можно понять, что он как раз переходит от топологической разметки к физической, чтобы делать то же самое. Т.е. координаты реперных точек линий и фигур используются для суждений в процессе обработки о структуре схемы и о её соответствии ограничениям. Мне казалось, что всё как раз наоборот: от физической разметки к топологической : ) Координаты (если речь об X и Y) не используются для суждений. Используются понятия: слева, справа, сверху, снизу, контакт вверх, контакт вниз, контакт вправо. |
Автор: | Владислав Жаринов [ Среда, 18 Апрель, 2012 21:49 ] |
Заголовок сообщения: | Re: ДАР формат. Он же DAR : ) |
А, это как я сделал при описании ограничений на веточные циклы здесь: viewtopic.php?p=70770#p70770 - чтобы не определять нумерацию на схеме и от неё отталкиваться - тоже через "туда-сюда"-текст (внешний по отношению к схеме) определил... Тоже можно... без текста в модели, конечно, не обходимся - но иное место ему находим... Одно "но" у такого подхода есть. Как раз на ВЦ видно - чтобы установить некоторые свойства, каждый раз придётся делать обход графа (в данном случае на поиск доминаторов/рецессоров по Правилу 25). Если сразу вводить/поддерживать разметку графа, как в "полуфабрикате" - то суждения можно выносить на её основании (в т.ч. и в динамике). А обход делать только при реальном изменении топологии - для переразметки. |
Автор: | Ильченко Эдуард [ Среда, 18 Апрель, 2012 22:27 ] |
Заголовок сообщения: | Re: Представление схем по Ильченко |
Владислав Жаринов писал(а): В-четвёртых, можно при описании сложных ветвлений пойти путём, логически намеченным Дейкстрой,... Что-то путь намеченный Дейкстрой от меня ускользает : ) Все сложные ветвления, которые я смог придумать, уложились в ДАР формат. Буду рад примерам ветвлений, которые не описываются в терминах ДАР. Собственно, поиск такого примера одна из целей создания данной темы. |
Автор: | Ильченко Эдуард [ Среда, 18 Апрель, 2012 22:47 ] |
Заголовок сообщения: | Re: "Электронные проекты" по Ильченко |
Владислав Жаринов писал(а): При этом группирование можно обеспечить, как описано здесь: viewtopic.php?p=64343#p64343. Т.е. группируем в специальной модификации силуэта (специализация гл. обр. в отображении), переходы по которому заменяют максимум гиперссылок в обычном тексте. Не уверен, что использование силуэта целесообразно. Обычно силуэт физически занимает много места. А что должно получиться в результате? Было бы здорово, если бы Вы смогли привести практические примеры (не теорию : ) использования силуэта в предложенном контексте. |
Страница 1 из 4 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |