Конструирующий XPath? Алгоритмический XPath? Ничего, кроме XPath

[ybqwer]

Валидационный xpath: посмотреть нет ли каких то условий, вроде:

all(/OBJS/Var[@A is int and @A > 5] )

и использование условий типа

if all(/OBJS/Var[@A is int and @A > 5] ):
/OBJS/Var[@A]
else:
/OBJS/Var[@B]

concat_list($#, $##): add_list(#/self::*) and add_list(##/self::*)
что за вырвиглаз с этим $##, не лучше просто встроить тривиальные операторы

Вообще XPATH подойдёт и для любого графа обьектов в программе, просто получается вырвиглаз синтаксис. я бы предложил нотацию типа

all(.objs.var.(a == 1 and b== 1). x)

ненадо плодить лишние @#/[]<> там где можно обобйтись без.

[pekunov]

Синтаксис — вопрос абсолютно открытый (я на своем варианте не настаиваю), если вдруг когда-нибудь эта идея дойдет до какого-то промышленного воплощения. Меня же интересовал почти исключительно вопрос о том, насколько возможна реализация идей, изложенных в посте.

[ybqwer]

конечно возможно. Это похоже на то что проскакивало в моём хобби проэкте правда там вроде XPATHA по обьектным данным то есть а.b это b поле обьекта a но вообщем сгодится и можно расширить на любые типа структурированных данных, приходит на ум кроме XML и обьектов ещё и URI.

Встраиваем функции типа exec (stmt) -> исполнить стейтмент, validate(stmt) -> свалидировать стейтмент, all, any, cat, etc…

остальное легко сделать на Питоне с использованием разных плюшек типа оверлоада точки (__getitem__)
Можен побыдлокожу так как часть этого у меня есть, только тогда будет Питоний перегруженый, то есть мой синтаксис без ненужных символов.

[nitrosbase]

достраивать новые узлы таким образом, чтобы они полностью соответствовали запросу.

• Предикат сводит информацию, содержащуюся в документе, к True/False. C  [@A=2 or @A=3] вы что-то придумали, а как будете восстанавливать [@A>1]?
• Выражение XPath сводит структуру элемента к списку, положим, элементов. Как будете обрабатывать // и * ?

[ybqwer]

а как будете восстанавливать [@A>1]?

а в чём проблема, если путь привёл меня к конкретному значению a?

Выражение XPath сводит структуру элемента к списку, положим, элементов.

для агрегации условий по множеству значений могут использоваться any, all, notall, none или использование булевого массива как вилки в if/else которая возвращает массив значений оттуда или оттуда

вообщем принцип как в Numpy индексировании приходит на ум.

[pekunov]

C [@A=2 or @A=3] вы что-то придумали, а как будете восстанавливать [@A>1]?

Такой элемент выражения может присутствовать в конструирующем XPath. Но используется он только для фильтрации на очередном шаге, порождать новых вариантов такая часть, разумеется, не будет. Она просто отсечет порожденные варианты с @A>1, если они появятся, например, [(@A=1 or @A=6) and (@A>1)] просто тогда даст единственный вариант с @A=6.

Как будете обрабатывать // и *

Они присутствовать могут, и рассматриваться при интерпретации/продвижении по выражению тоже будут, здесь противоречий нет. Но, конечно, "*" ничего создать не может.

[ybqwer]

Но используется он только для фильтрации на очередном шаге, порождать новых вариантов такая часть, разумеется, не будет.

Но, конечно, "*" ничего создать не может.

можешь поподробнее обьяснить разницу?

[youngmysteriouslight]

Мне кажется, тут лучше быть более последовательным. Например, при использовании [@A>1], // и * кидать исключение «Порождаемый документ бесконечен из-за элемента ...».

Кстати, Вы не думали, как формально поставить задачу, который решает Ваш инструмент? Очевидно, речь идёт не о генерации минимального XML, удовлетворяющего XPath, потому что нужно перебирать все члены дизъюнкции под [ ], но и не максимальный XML, потому что другие атрибуты и дочерние узлы, кроме упоминаемых в запросе, не добавляются.

[pekunov]

Относительно формальной постановки. Думаю, так:
Генерация минимальных дополнений исходного XML, таких, что:
1. Гарантированно истиннен каждый шаг заданного XPath;
2. Если на шаг был наложен логический предикат [], то полученный XML удовлетворяет ВСЕМ случаям из его таблицы истинности, дающим в результате истинное значение.

[youngmysteriouslight]

полученный XML удовлетворяет ВСЕМ случаям из его таблицы истинности, дающим в результате истинное значение.

Не всем же.
Например, Var[@A=1 or @A=2] сгенерирует <Var A=«1»> и <Var A=«2»>, но не <Var A=«1» B=«5»>, хотя он тоже является случаем из таблицы истинности.
Или: Var[@A=1 or @B=2] что породит? Входит ли <Var A=«1» B=«2»> в результат? Ответ должен следовать из постановки задачи.

[pekunov]

В случае Var[@A=1 or @A=2] таблица истинности предиката включает единственную переменную A, при чем же здесь B?
А случай Var[@A=1 or @B=2] породит три варианта:
A=«1»
B=«2»
A=«1» B=«2»

[youngmysteriouslight]

В случае Var[@A=1 or @A=2] таблица истинности предиката включает единственную переменную A, при чем же здесь B?

В моём понимании таблица истинности — эта таблица из двух колонок, в первой перечислены все объекты из области определения предиката (все возможные узлы в нашем случае, в т.ч. содержащие другие атрибуты, дочерние узлы и т.п.), а во второй — True/False.
В остальном Ваше отношение понятно.

[sshikov]

Это вы не XQuery случайно изобрели?

[funca]

Напоминает Emmet, только вместо CSS селекторов у автора XPath.

[pekunov]

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

[sshikov]

Я не про синтаксис — он конечно не похожий. На самом деле было бы интересно, если бы вы прокомментировали, чем это отличается от множества известных технологий.

[pekunov]

Отличается, повторюсь, применением XPath в конструирующем смысле, и минимализмом средств.

[Ithilvir]

Полностью поддерживаю.

[yakov-bakhmatov]

В условном «кровавом энтрепрайзе»™ мне довольно часто встречалась задача «пропатчить» буквально один узел в XML-документе (в том числе, не существующий в исходном документе). Писать для этого полноценное XSL-преобразование (или делать десериализацию в объект) совершенно не хочется. И «конструирующий XPath» здесь — то, что доктор прописал.