Роман, как вы правильно сказали
Роман М. писал(а):
Reader управляется "сверху" объектом модели контейнера, когда Reader'у указывается что, где и сколько нужно прочесть.
значит только полное повторение кода управляющей сущности может привести к повторению последовательности операций чтения, а значит моя фраза про отсутствие возможности узнать, что же записывает Store, глядя на odc извне, верна. То есть, внешним утилитам надо быть "как ББ" только на своём языке программирования. И каждое новое отображение в документе будет требовать такого же отображения реализованного на другом языке.
Далее, мы говорили о том, что Stores.Reader предоставляет интерфейсы перемещения и произвольного чтения каретки по цепочке байт, следовательно, этот интерфейс должен быть реализован в хранилище на основе xml, вместе с тем, интерфейс Stores.Reader таков, что позволяет прочитать весь файл, а не только область выделенную для конкретной Store, следовательно, этот интерфейс может быть использован в работе одной из Store ещё неизвестной нам, а значит, она не будет работать с вашей реализацией хранилища, контракты будут нарушены. А компонент персистентности на основе XML с нарушением контракта не может считаться полноценным. Но это не исключает возможности создания чего-то на основе XML, только наверное не стоит называет это Stores.
Я это говорю не к тому, что я против вашей идеи, на самом деле, возможность полноценной экстернализации в различные форматы данных является привлекательной с точки зрения осуществления обмена информацией по всяким сетям, но после изучения интерфейса я понял, что интерфейс сам по себе не позволяет нам ограничивать контракты и функциональность Reader/Writer так как они не являются расширяемыми. Фактически, либо мы пользуемся функциями персистентности, которые реализованы в Stores, либо не пользуемся ими, создаём свои механизмы и используем их в обход Stores.