Я один из разработчиков XQSharp, поэтому у меня есть опыт в этой области. XQSharp фактически начал свою жизнь как реализация XPath, прежде чем мы расширили его для поддержки XQuery.
Наше первоначальное внедрение заняло у нас около 6 месяцев, хотя это было не единственное, над чем мы работали в то время.
После этого времени у нас была полная реализация. Было много областей, в которых это не было полностью совместимо, где стандартные методы .NET не вели себя так же, как требуемая спецификация. Некоторыми примерами этого являются преобразование значений в строки и из строк, регулярные выражения, много вещей в Unicode, проблемы с представлениями XML .NET (например, обработка xml: base) и т. Д.
Для реализации этого необходимо было сделать несколько областей:
Синтаксический :
Сам синтаксический анализатор был прост и в основном генерировался из спецификации EBNF. Я бы оценил, что это изначально представляло собой работу за несколько недель.
Модель данных :
Как данные представлены. Чтобы иметь полную реализацию XPath, необходимо реализовать много новых типов данных (например, xs: gDay). В нашем случае все наши элементы являются производными от базового типа, и все наши выражения возвращали бы их перечислители. Вы также должны иметь возможность определить, соответствует ли тип элемента конкретному типу XPath. Мы с самого начала поддерживали статическую типизацию и понимание схемы, но без этих функций этот раздел, вероятно, станет тривиальным, но вы все еще ожидаете работы за несколько недель.
Выражения / Абстрактное синтаксическое дерево
Это модель самого выражения. Мы использовали документ формальной семантики XQuery для создания сопоставления различных конструкций XPath (например, осей и предикатов) с более простым базовым грамматиком (который заканчивается огромным количеством выражений let, if и typeswitch!). В нашей первоначальной реализации все эти выражения имели методы оценки, как и окончательное представление выражения. В нашем случае все выражения также имеют методы проверки типа, но это может быть пропущено изначально (основное назначение - оптимизация). Создание всех этих выражений снова заняло несколько недель.
Функция
Как указывал предыдущий комментатор, библиотека функций для XPath довольно велика. Вся библиотека XPath заняла у нас несколько месяцев.
Статический анализ
Требуется небольшое количество статического анализа. Ссылки на переменные и вызовы функций должны быть связаны с правильными переменными и функциями. Большинство реализаций XPath основаны на стеке, поэтому фаза выделения стека требуется для назначения указателей (или индексов) всем переменным. Этот статический анализ занял неделю или две. Книга Дракона должна помочь вам решить большинство из этих проблем.
Вы, вероятно, смотрите на ценность работы за месяц для всех дополнительных кусочков работы, которые не попадают непосредственно в эти категории.
После всей этой работы у нас осталась в основном функциональная реализация XPath; но это было очень медленно для реального использования (возможно, в 100 раз медленнее, чем XPath 1 в .NET). Так что после этого начинается веселая работа - Оптимизация.
Для доведения движка до 100% соответствия и добавления оптимизаций, вероятно, потребовалось еще 12-18 человеко-месяцев (хотя мы, вероятно, немного отстали от оптимизации!), Но к этому моменту мы уже перешли к реализации XQuery .
Мой совет - начать с подмножества XPath (может быть, только с прямыми осями и очень ограниченной библиотекой функций), и вы сможете собрать реализацию через месяц или два, но серьезная реализация XPath2 будет большие инвестиции во времени.
Убедитесь, что вы используете XPathNavigator для представления своего узла, поскольку у него есть такие методы, как SelectChildren, которые могут использовать преимущества индексов в базовых представлениях (например, XPathDocument).