Мне было поручено найти синтаксический анализатор DOM XML с открытым исходным кодом. Парсер должен минимально поддерживать XPath 1.0. Поддержка схемы желательна, но не является преградой
Файлы, которые мы анализируем, будут небольшими, поэтому скорость и потребление памяти не имеют большого значения.
Любой объектно-ориентированный язык (C++, C#, Java и др.).
Чтобы прояснить, план состоит в том, чтобы интегрировать синтаксический анализатор XML в приложение гораздо более жестко, чем это можно сделать с помощью внешнего анализатора. Мы создаем адаптивную объектную модель на основе XML (изменить XML, изменить объектную модель). Для этого нам нужно интегрировать синтаксический анализатор на довольно низком уровне. Это приводит к уровню элегантности, который необходимо испытать, чтобы понять (спасибо, мистер Йодер). Часть этой элегантности исчезает, если у нас нет возможности перемещаться по этой объектной модели через XPath.
Мы создали прототип, который использует синтаксический анализатор, предоставляемый операционной системой. Он работал довольно хорошо, но страдает сложностью и проблемами с производительностью. Но эй, это был прототип. Теперь я хочу заняться настоящим делом и могу написать парсер с нуля. (Я проделал эту часть работы, и это было довольно легко.) Теперь другая история с движком XPath. Я почти уверен, что не сделаю этого за выходные.
Итак, вы действительно хотите, чтобы синтаксический анализатор с открытым исходным кодом с поддержкой XPath использовал с вашим собственным анализатором - что - и скопировал часть XPATH? Вы просто делаете это из личного интереса и любопытства? Может быть, экзотическая ОС?
Я изучаю адаптивные объектные модели (с использованием метаданных для управления топологией объектной модели). Как я уже сказал, прототип на самом деле работает довольно хорошо, но я знаю, что могу добиться большего с моим собственным парсером.
является ли совместимость с DOM требованием?
Да, нам нужна совместимость с DOM. Я не закончил изучать это, но у меня есть решение, которое работает. Я написал свой собственный DOM-парсер. Я использую System.Xml.XmlTextReader для фактического анализа. Объектная модель для моей реализации - это облегченная версия объектной модели System.Xml.XmlDocument. Он дает мне необходимые функции (интерфейс DOM Level 1 Core и поддержка XPath), но значительно снижает накладные расходы.





Чтобы правильно ответить на этот вопрос, я думаю, вам нужно предоставить немного больше контекста. Сказав это, я обнаружил, что новая объектная модель (XElement и т. д.) Для Xml в .NET 3.5, поддерживающая Linq to XML, значительно упрощает навигацию по XML, и я действительно имею в виду на порядок, проще и лучше, чем использование DOM.
У меня есть устаревшее приложение, в которое мы склеили код, чтобы выразить его внутреннее состояние как XML (похоже на парсер DOM). Теперь я хочу перемещаться по этой «DOM» через XPath. Выразить внутреннее состояние в виде XML DOM было несложно. Я обнаружил, что написать парсер XPath для навигации по этой DOM не так-то просто.
Linq заинтриговал меня, но я не могу понять, что может означать использование его для навигации и объектной модели.
Если вы разрешаете C#, разве у вас не будет стандартных библиотек C#? Они неполноценны?
То же самое для Java? И все началось с C++. Я не понимаю недостатка.
Поиск в Google по запросу "XML parser XPATH" находит множество совпадений для CPAN, JDOM и J2SE, какао, MSXML и т. д.
Вы только начинаете здесь поиск или стандартных ответов недостаточно?
Обновлено:
Ваши пояснения подсказывают мне, что вы не хотите его использовать, вы хотите использовать исходный код для запуска вашего собственного модуля XPATH в вашем собственном анализаторе XML? Это верно? И вам наплевать на язык, потому что все, что вам нужно, - это дизайн, а не код?
Ты прав. Некоторое время я искал подходящий пример реализации XPath. При необходимости напишу сам, но хороший пример никогда не помешает. Коллега посоветовал мне опубликовать здесь.
Всегда отличный Jaxen может быть вам здесь полезен. Это реализация Java XPath, используемая как для JDom, так и для Dom4J.
При рефакторинге общей функциональности для обхода двух реализаций DOM теперь у вас есть механизм XPath, который может запрашивать любую древовидную модель. Вам нужно только написать то, что они называют навигатором, что сравнительно просто.
How do I support a different object model?
The only thing required is an implementation of the interface org.jaxen.Navigator. Not all of the interface is required, and a default implementation, in the form of org.jaxen.DefaultNavigator is also provided.
Since many of the XPath axes can be defined in terms of each other (for example, the ancestor axis is merely a the parent recursively applied), only a few low-level axis iterators are required to initially get started. Of course, you may implement them directly, instead of relying upon jaxen's composition ability.
Я нашел их относительно быстрым.
Джамеш, у меня было всего несколько часов, чтобы осмотреть Джаксена, но я хотел сообщить вам, что это выглядит очень многообещающим. Большое спасибо за предложение.
Если все, что вам нужно, - это логика дизайна, на которой будет основываться материал, а не код, вы можете изучить библиотеку REXML Ruby. Это объектно-ориентированный подход, неплохой и имеет полную поддержку XPath.
MRI реализован на C и Ruby. JRuby имеет реализацию на Java.
Вероятно, маловероятно, но jQuery явно поддерживает синтаксис XPath для ссылки на DOM; и я думаю, что его исходный код доступен.
вопрос не имеет смысла: C#, Java и я предполагаю, что C++ имеют синтаксический анализ XML, доступный на уровне языка - что вы пытаетесь сделать?