DRAKON.SU

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

1. Никто не заставляет вас делать id по порядку. Главное --- это уникальность id. Например, возмите значение системного таймера, когда вам нужен новый id и у вас всегда будут уникальные значения.

2. Если всё-таки хочется id по порядку, то заведите счётчик, который после каждого обращения к нему выдаёт номер и увеличивает на единицу своё значение. И заведите список, куда заносите значения id, для удаляемых элементов. Тогда для нового id, вы посмотрите в список, если он пуст, то обратитесь к счётчику, а если не пуст - возьмёте значение оттуда.

Что в этом сложного ?

Эдуард, в данном случае XML удобно рассматривать как базу данных. Ведь не будете-же Вы хранить связи между элементами, полагаясь на порядок следования записей в таблице базы данных. Для этого в базах данных предусматривают уникальные ключи по которым можно однозначно идентифицировать конкретную запись в таблице.

И вобщем-то уникальные ID по большому счёту нужны только на стадии сериализации/десериализации. У Геннадия Тышова в первых версиях редактора все связи между элементами строились через указатели, наверное и сейчас так. Поскольку все указатели были помещены в списки, то и ID получались автоматически... ID были просто равны порядковому номеру указателя в списке.

Для новых объектов Id выбирается с минимальным свободным значением, Id удаленных объектов доступно для выбора.

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

Я, наверно, туплю : ) В чём заключается удобство рассматривать дракон-схему, сохранённую в XML, как базу данных? В базе данных порядок элементов роли не играет, а в дракон-схеме, с точностью до наоборот, каждый элемент занимает строго определённое место, что благополучно эмулируется прикручиванием ID к каждому элементу в базе данных. К тому же доступ к сохранённой схеме одноразовый, никакой выборки из середины в последствии не производится.

У меня складывается впечатление, что тот или иной способ обработки структуры дракон-схемы всего лишь вопрос веры : )

А вот отсутствие упорядоченности в элементах одного уровня в XML - серьёзный довод.

Согласен.

А вот интересно, SAX парсер считывает теги однозначно в том порядке как они появляются или могут быть нюансы?

Да, и я,кстати, имел в виду именно фиксацию порядка в схеме (а не при выгрузке/загрузке).
Кстати, сразу не пришёл на ум очевидный пример. Есть обычный документ - типа такого: download/file.php?id=3079. Его докэлементы можно уподобить вершинам схемы (собственно, так и будет, если представить документ на базе лист-силуэта - но мы сейчас не о том). И пусть в процессе переработки понадобилось вставить/дописать что-то. Если это можно добавить как часть элемента - это одно дело (можно сравнить с редактированием содержания/типа вершины). Если же нужно добавить как целый элемент - что делать будем? Правильно - вводим новый индекс в оглавление (вместе с заголовком, если нужно)... и реиндексируем кое-что.
А что именно? Оно как раз и зависит от принятой нумерации. Если многоуровневая - то номера текущего уровня (разделов/подразделов/пунктов/подпунктов) в текущем ряду нумерации от вставленного и до конца ряда. Т.е. вставили новый п. 3.5.2 - перенумеруем (+1) каждый, начиная с бывшего 3.5.2 и до последнего 3.5.N. И всё - по определению нумерации ясно, что больше ничего трогать не надо.
Если линейная (одноуровневая) - то все вообще докэлементы от вставленного и до конца документа придётся перенумеровывать... случайно не знакомая ситуация?..

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

Вовсе не лишнее.

При выполнении программы, связи между объектами определяются указателями, указатели двухсторонние, т.е. влево, вверх, вправо, вниз. В файле хранения связи между объектами записаны значениями Id, связи односторонние, т.е. вправо, вниз.

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

Id объектов в схеме никогда не изменяются.

Дублирования идентификаторов не возникает, т.к. в буфере хранится схема или ее фрагмент с Id скопированными из схемы. При вставке из буфера в схему, создаются объекты с новыми идентификаторами, связи между объектами в схеме устанавливаются на основе идентификаторов объектов в буфере.

В ИС Дракон Id имеет обозначение UN - уникальный номер.
В ИС Дракон Id является идентификатором иконы, который присваивает пользователь, его наличие предусмотрено ГОСТом -19.701-90.

Для пользователя Id является важным свойством объекта и используется для идентификации схем и икон.