На макете, который теперь находится
в этом примере, реализованы
общеязыковые требования с уточнениями; в частности, унификация описаний РДП-объектов доведена до близкой к логически целесообразной, а структура документа приведена к текстобазированному шаблону условной УСД, используемому в примерах здесь.
Что же иллюстрирует этот пример? Прежде всего то, что представление документа в самом передовом виде при реализации д.б. увязано с традиционным. И дело здесь не только в позиции, которую неоднократно озвучивал (подразумевая, что текст - это письменная внешняя речь
) тот же Фёдор Васильевич - что картинками, взятыми сами по себе, не обойдёшься - и которая с самого начала (собственно, ещё до знакомства с ней
) нашла отражение в виде поэтапного уточнения классификации формализуемых знаний по Паронджанову (в полном виде и содержащейся в примере). Нужно помнить также, что существуют стандарты документирования, закрепляющие вполне определённую логическую организацию как системы реквизитов (с закономерными их вариациями по составу и содержанию) - и если физику мы можем перевести на графовую базу, то логику надо сохранить - чтобы был изоморфизм для той же символ-сборки. Кроме того, и физика реквизитов практически полезного документа вполне определённая (по атрибутам свойств формата, которые должны объединяться в стили) - и это тоже нужно учесть. Чтобы можно было из схематизированного массива данных в редакторе получить документ, определённый у тех же Пшенко и Охотникова
в этом сообщении - конечно, при некоторых условиях, определяемых сочинителем.
Важным обстоятельством является и участие документа в таких операциях, как согласование (с возможными исправлениями) и визирование (с принятием исправлений). Эти вопросы освещены в статьях из того же сообщения - а технология коллективной работы с формализованным знанием в таких стандартах, как IDEF (см. в этом сообщении).
Без этого любой супер-пупер-редактор, каким бы визуально-структурным он ни был (пусть даже там будут реализованы все частные графит-языки, придуманные мной
), превратится для массового пользователя, желающего формализовать профессиональные знания, в проблему даже при когнитивной эргономичности его интерфейса и технической эффективности как приложения. Ибо придётся как-то "подгонять" допускаемые представления документа и операции над ним под реальные требования - а это лишняя работа, та же "избыточная сложность" - не говоря о том, что некоторые вещи и не получится реализовать таким путём.
Конечно, это относится как к любому готовому инфопрогизделию, так и к любому проекту требований на него - начиная с концепции инфор-документа. Именно поэтому РДП-требования сочетают лист-силуэтную основу графбазированного представления документа со стандартной структурой докэлементов. И прорабатываются в направлении предоставления пользователю средств управления этой структурой.
Конечно, из тех же стандартных 30 типов реквизитов документа активно используются едва ли десяток-дюжина - но и их нужно определить (притом информатизованно - как прототипы конечных структур данных). Некоторые специфичны только для текстовых или для графических в стандартном понимании документов - и чётко там описаны.
Кстати, поэтому детально не определяются реквизиты РДП-листа - в ЕСКД есть про форматы и основную надпись, а в условном шаблоне, как можно видеть, колонтитулы представляют как раз их упрощённую (и учитывающую машинный документооборот) версию.
Также не определено представление для формул и динатабов - предполагается, что они готовятся внешними средствами и вставляются как объекты (изображения или внедрённые) - аналогично неграфовым иллюстрациям.
Возможно, такие решения нужно обсуждать - но следует отметить, что РДП-документ мыслится как интегрирующий результаты относительно специализированной переработки данных об объектах деятельности в других приложениях (расчётно-логической, специально-оформительской) - а не как заменяющий их. Сама РДП-среда обрабатывает (для чего и содержательно представляет внутри себя) только структуры деятельности (в т.ч. реализуемой [программно-]аппаратно).
Ещё один вопрос - об авторизации редактирования документов. Пока предполагается, что для каждого объекта, представленного РДП-переменной, ведутся версии по пользователям и меткам времени, и в редакторе можно сличать версии (с отображением разницы). Возможно, следует принять подход офисных пакетов - вести непосредственно исправления по авторам и меткам с возможным добавлением обосновывающих комментариев - но это м.б. сложнее в реализации.
Здесь и в общеязыковых требованиях также не детализируется представление о графит-вершине как модельном объекте (логика как оператора визуализируемого языка) и как элементе графит-схемы (физика как одно/многоячеечной автофигуры на листе). Отчасти эти вопросы разбирались, напр., для своей реализации Дмитрием_ВБ в этой теме.
Сказанное распространяется на другие концепции инфор-документа, такие как схемокурс, Ты-проект, "текст как интерфейс" - но последняя-то как раз даёт пример разумной информатизации на текстовой базе. Более того, наметилось движение к совместимости её реализации в ББ-среде со стандартами документов - примером может служить появление построителя оглавлений по заголовкам. Кроме того, что это стоит продолжить, единственное, что можно заметить - для массового пользователя-непрограммиста д.б. привычный интерфейс редактирования - впрочем, ББ-среда позиционируется для программистов. Ряд операторов ЛС-диалекта в принципе соответствует сущностям "текста как интерфейса" - так, ЛС-вставка может пониматься как визуальный коммандер.
Некоторые концепции (как-то PureBuilder-документа), видимо, ещё не вполне определены (во всяком случае, форма PureBuilder-описания или извлечения из него как документа, допускающего согласование и визирование, на сегодня неясна).
По поводу РВ-интерфейса можно также заметить вот что. Распределение категорий содержания документа по вкладкам вполне удобно для программного проекта как "вещи в себе". Когда же мы документируем порождающую его задачу, тем более во взаимосвязи с другими задачами, то нужно найти каждому программному компоненту (в его видимом представлении) место в документе. И вкладки естественно назначить уже документам - а также компонентам содержания, не вошедшим (быть может, временно) в документирующие структуры.
Чтобы показать, как сделан макет, здесь приводится файл с выдержкой из его подлинника:
Вложение:
Комментарий к файлу: Макет бланка РДП-документа (начало).
РДП-макет А2LS [имя-РДП-докум] (бланк 2xA4LSx2, с титулом).odg [273.26 КБ]
Скачиваний: 469
Включён только титульный раздел, т.к. объём файла Draw растёт с увеличением числа врезок-таблиц (которыми смакетированы жёсткие поля), а для иллюстрации этого достаточно.
Если взглянуть на лист-силуэтную структуру документа, то можно сказать, что она в некотором смысле представляет дерево докэлементов (схемных; понятно, что внесхемные образуют альтернативное дерево, где все вершины "на одной ветке"), "прошитое" регулярными ссылками (по адресам строк; нерегулярные - из текстов вершин - конечно, должны представляться отдельно, если это требуется) и помеченное наборами атрибутов вершин.
Конкретно титульный раздел играет роль интерфейса к элементам структуры (естественно, находящимся за его пределами ; сам раздел есть предопределённое содержание РДП-документа и управляется из РДП-редактора только в плане показывать/скрыть); на макете показан общий состав, а использование в сочиняемой части определяется вручную.
Естественно, подробный макет нужен и для информатизации - играя роль "внешней схемы" задачи. Тут стоит отметить, что именно умению формировать подобные описания и должна учить прежде всего информатика в школе - и программирование при этом играет функциональную роль (т.к. именно попытка выразить задачу как "структуры данных + алгоритмы для формального исполнителя" приводит к необходимости инфор-моделирования).
Вообще вопросы интерфейса и информатизованного представления документов вкупе с реализацией системно и довольно подробно освещены у Коутса и Влейминка - по-видимому, эта работа может служить ориентиром разработчикам РДП-средств (скажем, как подсистем к тому же ББ). Для конструкторско-технологических применений не стоит забывать и о стандартах на КТД - примеры информатизации которых можно найти в статьях, вложенных в это сообщение.
Итак, язык схематизации - главный в документе и первый подлежащий реализации в РДП-редакторе (в полном соответствии с генеральной классификацией данных
). Тем более, что ЛС-язык определяется как исполнимый и логически соотносим с компонентным прогязыком. Единственная разница - что нужно определить модули в рамках графит-модели (для ЛС-языка весь несоставной документ можно считать одномодульной моделью, а схемы разделов - её процедурами, в составном входящие документы м.б. модулями; но явно это не отражается - разве что в оглавлении) и решить вопрос с явным описанием исполнителя (актив-знания).
P.S. В принципе возможна последовательная визуализация структуры докэлементов - скажем, если придать переключателю (в особой синтаксической форме) роль узла ветвления маршрутов, включающих жёсткие поля (каждое из которых в этом случае должно представлять один докэлемент и быть единственным на линии следования). Однако это выглядит несколько экзотически
- в частности, надо решать, определять ли заголовки и индексы в жеполях. Хотя, если придать вариантам переключателя форму имён строк и в них хранить имена докэлементов, то возможно некое визуальное единообразие... надо подумать