Ну вот, недавняя практика "структурного редактирования офисными средствами" показала, что на самом деле надо
в первую очередь от
действительно структурного редактора в части документов (проектов)...
Короче. С чего надо начинать - это с поддержки организации и ведения в среде общедоступных указателей, интегрируемых в документы. Реально их видов (кроме оглавления) три:
Схемная форма, как видим, на общей основе - лист-сетей - учитывающих сказанное здесь:
viewtopic.php?p=64292#p64292. На третий вид указателей тоже. Можно выложить - но всё равно сейчас идёт обсуждение формы (начатое с теми, кто об этом знает
) - а корректированное предполагается включить в ГРАФИТ-базис. Так что ссылки всё равно должны измениться.
Что ещё общего д.б. - текстовая "морда" - такая, как в нормальных книгах (можно хотя бы Фридланда посмотреть). Но - гиперизованная. Как следствие того, что содержательно позиции указателей "повторно используются" как вхождения в документы. Притом - так, чтобы не забывать всё то же замечание Ильи об эргономике ссылок
. А значит - система ссылок на вхождения "из общего корня".
Ещё - ведутся сокращения для имён. Их формирование несколько различно по видам указателя - если для имён и терминов, определяемые составителем (слова, аббревиатуры, инициалы) - то для источников, кроме типичного варианта "№п/п в списке" это символические индексы, составляемые по правилам для данной предметки. Ну, знаете, как в некоторых науках/странах принято, например, вместо привычного номера источника п/п в списке документа ставить текст вида '/'<имя-автора>[', '<начало-заголовка-издания-из-ряда-в-пределах-года>]', '<год-издания>'/'...
А по сути всё это - частные случаи синонимов - т.е. на самом деле среда просто поддерживает многотерминность определения. И также - многозначность термина. Соответственно варианты "для машины" разделяются на полные и сокращённые, нумеруются в этих разделах, один принимается как основной - ну а как их выбирать для вхождения, это пользователь определяет... по правилам, прописываемым в среде...
Что частного? Предлагаемый состав основных полей записи по видам указателей будет различаться. Графит-вьюшку можно видеть на этом примере хотя бы:
http://grafit-basis.narod.ru/L3/complex ... Pril3-n221.
К этому нужно добавить, что с источником д.б связан корпус цитат из него. Дабы их тоже просто подставлять в документы.
Отсюда принципы оргведения вижу такие. Указатели - это, ессно, БД позиций - каждая своего вида и со своим форматом записей, - ведомые теми из зареганных в среде, кому назначены роли админов этих БД. Они (и все остальные
) их пользуют, выбирая нужный состав позиций в свои документы. Соответственно в каждом документе ведётся указатель использованных позиций. Вторичный - и потому со своей индексацией в пределах документа.
Специфическая "добавка" для документа (по сравнению с БД) - как раз вторичный номер позиции (по сути, закладка для ссылок из мест вхождения). В документе индекс изначально и хранится как пара "первичный-вторичный". Всё содержательное для отображения подставляется из первичного указателя (значения полей БД) - а в документе, ессно, не хранится.
Ну и при выгрузке во внешнюю вьюшку (я это называю "символ-сборкой"), например, ЕСКД-шную или книгоиздательскую, всё также подставляется неким специфицированным для этого типа вьюшки образом. Надо, чтоб был отдельный словарь - прописывается, каким внешним документом (каким разделом какого документа из комплекта вьюшки) он д.б. и какие поля из БД как располагаются и форматируются.
Как и правила употребления синонимов, в т.ч. сокращений - по сути, формализующие элементы стиля. Например, на каждое вхождение полного термина допускается столько-то подряд сокращённых... а имена допускается сокращать только в цитатах... ну и т.д.
Всё это определяет кто-то из админов - ну а для коммерческого решения (об этом аспекте в целом ещё скажу - теперь здесь:
viewtopic.php?p=76351#p76351) может и разработчик среды постепенно делать "типовые конфигураторы представлений"...
Далее составитель по мере работы над документом употребляет позиции в тексте (в таблицах, на схемах). В результате
что должно получаться? К индексу в документе добавляется перечень вхождений. По сравнению с видом в бумажных документах разницы две, и обе довольно большие.
Во-первых, каждое вхождение на одной странице указывается отдельно. Понятно, что с ним в перечне связывается адрес в "координатном пространстве" физической разметки документа (начало в тексте, ячейка таблицы, вершина/ребро графа схемы). Ну и номер п/п на странице при текущей компоновке (вёрстке) содержимого.
Для человека эти "п/п" удобнее свёртывать - допустим, к номеру страницы приписывается (пусть в скобках) число вхождений. Но "для машины" в файле документа всё сохраняется...
Во-вторых, каждое вхождение в документе - это ссылка для перехода по физическому адресу. Вторичному - т.е. на позицию перечня (представляющего указатель в машинном документе). Но. Для "эргономики ссылок" переход д.б. "многие вхождения к одному месту указателя" - ну и обратно тоже желательно детерминировать.
Отсюда можно так. В самом документе "для машины" по месту вхождения ставится, разумеется, только индекс ("техноимя" - а "для человека" подставляется значение поля "эргоимя") - и адрес позиции (строки) перечня. Кликнул на поле - перешёл к позиции. Там уже "эргоимя" ссылается на первичную позицию (на случай, если клик был с целью посмотреть определение) - а номера вхождений на свои адреса. Причём то, откуда сейчас перешли, особо выделено - чтобы, если больше ничего не надо, туда же и вернуться новым кликом. Можно, видимо, и как в смотрителях ("браузерах") для веб, поддерживать команды "вперёд-назад"... но это надо думать...
При переходе в первичку (по клику на "эргоимени") перечень вхождений остаётся доступен (в графит-вьюшке можно видеть графу для него - она как раз заполняется по текущему документу, откуда пришли).
Теперь
как это может получаться? Тут такие варианты.
Или по типу "викификации" - сначала написал, потом отсматриваешь, чего где совпадает с "эргоименами" из указателей... Нашёл - выделяешь и командуешь "преобразовать выделение во вхождение <имени|термина|источника>". Среда сначала ищет среди "эргоимён" (ну, это мы знаем, как - по Вирту/Б-М/К-М-П с образцом сопоставляет ), потом спрашивает: "правильно я [не ]нашла?". Юзер подтверждает - или уже лезет в БД и ищет то, что нужно.
Или "полуавтоматически" - пишешь и соображаешь, что сейчас д.б. "что-то указательное". И сразу командуешь "подставить <имя|термин|источник>". Тут среда просто открывает нужный указатель текущего документа - где ко всем существующим позициям есть вариант "ни одно из перечисленных". Если его выбрать - то начинается диалог пополнения указателя (как мы помним, ссылкой на БД).
Или автоматом - по мере ввода (или периодически по запросу) среда ищет и найденное предлагает преобразовать. Здесь тоже м.б. "ни одно из перечисленных".
Однако "перечисленных" может не быть и в БД. И тут мы должны перейти к работе с документами в целом...
Теперь по реализации. Содержательно каждая запись в указательной БД может трактоваться как "вынесенная нагруженная область" в смысле этого механизма:
viewtopic.php?p=59660#p59660. Что унифицирует процедуры компоновки документов - ибо оригинальная часть их содержания в среде изначально должна набираться как из уникального для документа ввода составителя - так и из таких же областей. Только не в указателях, а в "каталожной" БД - возможно, разделяемой по предметкам, например. В реализации компоновки важна роль структуры документа - ну и её схематического представления. Это уже обсуждалось в связи с теми же лист-сетями.
Тогда записи в БД указателей (как, впрочем, и каталогов) можно понимать как области, права на работу с которыми зависят от ролей. Ежели юзер и админ - то он сам и БД тоже пополняет. Ежели нет - то формирует временные указатели и отправляет админам на рассмотрение. Но, чтобы не "изобретать велосипеды" - имеет возможность делать времянки "относительно имеющегося" - т.е. и как проекты правок существующих записей в БД указателей.
Для чего это надо? Во-первых, для согласованности системы определений в пределах коллектива пользователей. Админы за это и отвечают. Во-вторых, для соблюдения авторских прав. Скажем - вам понравится, если цитировать вас будут "в стиле Вити Суворова" - буквоизбирательно и/или с форматированием "от себя"?.. или если "третье лицо" безо всяких законных оснований будет указывать кому-то, какое из ваших произведений использовать?..
То-то...
Посему - автор или его законный представитель, не входящий в круг составителей документов в конкретной инсталляции среды, тем не менее должен иметь свою пользовательскую роль в ней - или в силу "good practice" (взялись за его материал - известили и запросили), или "by law" (обнаружил автор/представитель нечто новое с упоминанием имени в его юрисдикции - изъявил законное желание влиять на результат). И именно экземпляр этой роли, например, утверждает каждую из цитат (вообще все основаниия - правоустанавливающие и goodwill-документы - фиксируются в профиле экземпляра, если уж на то пошло ). А в любой иной роли можно только добавлять к цитате комментарии, тэги формата - уже от своего лица, явно указанного для каждого добавления (получится, например, как здесь: viewtopic.php?p=74438#p74438 - понятно что Kori д.б. в роли автора, а В.Ж. - комментатора).
В общем содержательно это просто разновидность поддержки "совместной работы над документом". Технически это реализуется как SUBST-правила для областей, условно применяемые в зависимости от роли/экземпляра. Скажем:
Код:
"ДЛЯ <такой-то> перечень :
ЕСЛИ хочет изменить/удалить эту область/часть её содержимого, ТО отвергнуть операцию;
ЕСЛИ добавить содержимое ТО разрешить И заключить каждый добавленный фрагмент в <такие-то> комбинации символов И добавить в <таком-то> положении относительно результата имя <такого-то> по <такому-то> варианту;
ЕСЛИ добавить формат ТО разрешить И добавить в <таком-то> положении относительно результата описание форматов И имя <такого-то> по <такому-то> варианту"
.
Отсюда, кстати, снова видно, как работает подход Усова к деятельности.
В самом деле, роли-то оказываются едины для разработчиков и пользователей... И механизмы компоновки документа тоже - т.е. не надо ничего изобретать "специально для указателей" - реализовал поддержку областей и используй её...