SOFT FOR YOU,
в последнее время мне немало приходится работать с xml, посему заинтересовался темой.
Бегло просмотрев, хочу высказаться. Т. к. я пишу в основном под .NET, то сравню вашу задумку с имеющимся в этой платформе.

То что вы изобретаете, отчасти похоже на сериализатор xml. В частности, в .NET есть такой класс - XmlSerializer. Есть утилита xsd.exe, которая по имеющейся схеме генерирует набор классов (c# или vb.net). Дальше всё просто: читаем xml в сгенерированные классы одной строкой. Валидация, строгая типизация - всё присутствует. Дальше работаем уже не с xml, а с объектами c#. Это намного быстрей и удобней любого хранилища DOM.

DOM - не нужен! Вообще. Ибо сложно представить более неудобный API. Единственное оправдание его существования - легаси-код.
То ли дело API LINQ to xml - ну, тут можно долго петь дифирамбы (хотя и недостатки есть) :)

Почему именно SAX? Гляньте это: Сравнение XmlReader и SAX Reader .

Упомянутый XmlReader позволяет читать данные строготипизировано. Например, имеются методы ReadContentAsBoolean, ReadContentAsDateTime, ReadContentAsDouble и т. п.

Для ускорения работы XmlReader'а предусмотрена специальная возможность: сравнение имён элементов/атрибутов/неймспейсов не как строк, а как указателей. Для этого есть класс NameTable, куда заранее заносятся те имена, которые мы желаем читать (ведь как я понял, ваша идея скорости основана на знании структуры (схемы) документа xml).



Напоследок. Как я понимаю, весь код пишется вручную? Это во втором десятилетии XXI века?? Имхо, кодогенераторы рулят. Когда вся грамматика распарсиваемого языка описывается в виде РФБН в несколько десятков строк, и код парсера генерируется автоматически.

SOFT FOR YOUДело в том, что существуют 2 основные схемы распознавания XML: SAX и DOM
Таки это разные вещи.
В основе всех API для работы с xml лежит парсер. SAX (зажигающий события) и такого типа, что реализован в дотнете (назову его pull-парсер, т. к. он не выталкивает данные, а их нужно вытягивать). Но не суть важно, какой тип у парсера, важно, что он, и только он читает поток текста, представляющего собой xml, и выдаёт наверх готовые элементы дерева xml.

Все остальные API для работы с xml (сериализаторы, DataSet'ы, DOM, и прочие) используют парсер (sax или pull) для чтения xml и загрузки данных в себя.

Так что неверно смешивать SAX и DOM в одно целое.


SOFT FOR YOUЧто имея XSD мы можем существенно оптимизировать парсинг (сгенерировать конечный автомат)
Да, если нам заранее известна схема документа, то можно сгенерировать либо набор классов, куда сериализатором загрузим данные из xml, либо сгенерировать типизированный класс с иерархическим деревом, представляющим xml в том или ином виде (например, в .NET их аж три штуки разных), либо сгенерировать типизированный DataSet - набор таблиц (датасет может обходиться и без схемы, но при этом данные в нём будут нетипизированные - просто строки).


SOFT FOR YOUНафига вообще вызывать калбеки по атрибутам ?
Верно, нафига их вызывать? И для элементов нафига? Pull-парсер будет чуточку быстрее именно потому, что не тратит время на вызов колбеков.


SOFT FOR YOUНу и последние сутки я думаю, что на основе этого "SAX"-парсера, можно вполне сделать и DOM-парсер.
Ещё раз: DOM - это не парсер! Это объектная модель документа. Когда весь документ целиком хранится в памяти, и благодаря этому мы получаем очень быстрый доступ к его узлам, с помощью того или иного API (например, XPath). Наиболее известен именно API W3C DOM (в дотнете есть ещё API navigator, имитирующий курсорную модель, знакомую всем, кто работает с БД).


SOFT FOR YOUДля SAX память под элементы будет выделяться в стеке, но для них будут вызываться калбеки.
Потоковый парсер тратит память лишь на один только что прочитанный элемент, и как только отдаст его дальше, тут же можно освободить память. Однако, память будет тратиться на хранение информации о стартовых тэгах (до тех пор, пор не будет прочитан закрывающий тег этого элемента), о пространствах имён (до тех пор, пока не закончится область действия этого пространства имён), также нужно хранить информацию о дефолтных и фиксированных значениях элементов и атрибутов, о сущностях.

Опять же, приведу в пример дотнетовский pull-парсер - он тщательно вылизан, с кучей ручных оптимизаций, и работает настолько быстро (бьюсь об заклад, вам его не побить ;) ), что зачастую клиентский код не успевает обрабатывать выдаваемый им распарсенный xml. Чтобы ускорить клиентский код, имеется таблица имён (NameTable), куда можно занести заранее имена элементов, которые будут в xml, и в итоге сравнивать уже не строки (что медленно), а ссылки. К сожалению, размер этой таблицы может стать очень большим, т. к. парсер заносит в неё все имена встреченных элементов. То есть опять же размениваем скорость на память.


SOFT FOR YOUДля DOM память будет выделяться в пуле (такой способ менеджмента памяти) и наводить связи между Child-Parent ами.
Да. Чтобы обеспечить быстрый доступ ко всем узлам, нужно всё дерево хранить в том или ином виде в памяти целиком.


Таким образом, SAX и DOM напрямую не связаны. Парсер лишь читает поточные данные в один проход, без возможности возврата назад. Ведь чтобы вернуться назад к любому произвольному узлу, нужно хранить всю информацию о всех ранее прочитанных узлах. Прыгнуть вперёд к произвольному элементу парсер тоже не может, т. к. у него ещё нет информации, где этот элемент (и есть ли он вообще).