Является ли поведение реализации регулярного выражения XSLT/XQuery зависимым от реализации?

Question

Использование спецификаций регулярных выражений, определенных для XPath и XQuery, возможно ли для двух разных реализаций fn:analyze-string, заданных в качестве вхождений в те же строки регулярных выражений и строк соответствия, чтобы возвращать разные результаты и по-прежнему считаться соответствующими Рекомендации W3C? Или же те же самые входы всегда возвращают одни и те же результаты для разных процессоров XQuery и XSLT?

В частности, я спрашиваю о содержании match, non-match, group и @nr значений, а не базовые URIs или идентификаторы узлов (которые четко определены как зависит от реализации).

Answer 1

Есть один или два очень незначительные аспекты, в которых спецификация зависит от реализации:

• Поставщик имеет право решить, какую версию Unicode принять в качестве базовой линии. Существуют некоторые изменения между версиями Unicode, например, изменениями в категориях символов, которые могут влиять на результат выражений типа \ p {Cn} или \ p {IsGreek}, или вопрос о том, считаются ли два символа случайными вариантами каждого Другие.

• Правила для захваченных подстрок не совсем точны в кромочных случаях.Спецификация дает пример: например, учитывая регулярное выражение (a *) + и входную строку «aaaa», реализация может законно захватывать либо «aaaa», либо строку нулевой длины в качестве содержимого захваченной подгруппы.

Кроме того, результаты должны быть одинаковыми для всех процессоров. Но, конечно, это одна из областей, где процессоры могут решить, что 100% -ное соответствие слишком сложно - например, в Saxon-JS мы решили сделать все возможное, чтобы использовать механизм регулярных выражений Javascript 6, что, безусловно, оставляет нам меньше 100 % соответствует правилам XPath.

Answer 2

Следует различать три аспекта терминологии, имеют решающее значение:

• недетерминизм, что означает, что то же функция/выражение может возвращать разные результаты при оценке несколько раз с тем же параметрами/контекстом (с той же реализацией, в том же запросе).
• Поведение, зависящее от реализации, что означает, что реализации могут вести себя по-разному для конкретной функции (но это не означает, что она не может быть детерминированной в рамках одной и той же реализации).
• Реализация, определенная поведением, что аналогично поведению, зависящему от реализации, за исключением того, что реализация должна документировать свое поведение точно так, чтобы пользователи могли положиться на него.

Мое понимание из спецификации XQuery, но и из спецификации XML-схемы, которая определяет язык регулярных выражений, является то, что две реализации должны возвращать одинаковые результаты вызова fn:analyze-string, соображения относительно вмещающего элемент узлов левой стороны ,

В спецификации XQuery говорит, что недетерминизм из fn:analyze-string только из-за, как было упомянуто в вопросе, к тому, что личность узел может или не может быть одинаковой по повторяющимся и идентичных вызовов.

Базовый URI и префиксы зависят от реализации, и я понимаю, что по-прежнему подразумевается, что они должны быть выбраны детерминистически в запросе.

Если я ничего не заметил, спецификация XML Schema, похоже, не дает возможности разработчикам регулярных выражений. XQuery расширяет регулярные выражения XML Schema, но единственная функция , зависящая от реализации, - это захват некоторых групп, что имеет значение только для замены.