XQuery / XPath с Saxon API - нужны регистрозависимые пути

Question

Проще говоря, я бы хотел, чтобы все пути ниже имели одинаковые значения:

• / root / item1 / text ()
• / ROOT / ITEM1 /text ()
• / Root / Item1 / text ()

Насколько я понимаю, идея состоит в том, что узлы XML с различным регистром фактически обрабатываются как разные.Проблема здесь в том, что я строю динамический сборщик XML на основе набора реляционных таблиц SQL DB.Это приложение будет установлено на более чем 50 различных серверах с собственными экземплярами SQL.50% структуры таблиц, имен и типов будут отличаться, тогда как остальные 50% МОГУТ отличаться в буквенном регистре имени.Цель состоит в том, чтобы применить стандартные преобразования XQuery к этим динамически генерируемым XML-файлам, имеющим пользовательский И стандартный раздел, что означает, что оно применимо ко ВСЕМ 50+ серверам.Вот почему я ищу логику пути без учета регистра, несмотря на то, что она идет вразрез с основами XML, это дало бы ОГРОМНОЕ преимущество для нашего варианта использования, чтобы "выбрать" такую ​​возможность.

Полезный обходной путь, который я сейчас использую для тестирования, - это предварительное преобразование с использованием XSLT для преобразования ВСЕХ имен узлов элемента в нижний регистр.Так что, если из этого ничего не выйдет, то, по крайней мере, все равно будет достаточно работоспособным.

Я новичок в XQuery / XPath / XSLT, поэтому пространства имен по-прежнему для меня странная концепция.Одна вещь, на которую я наткнулся, это объявление сличения.Однако я не могу сказать, если это только для типичных сравнений строк ($ x = $ y) или других подобных вещей.Saxon имеет встроенный метод своего процессора под названием Processor.DeclareCollation (), я пытался его использовать, однако я не заметил, что запросы выполняются по-другому.

Является ли сопоставление моим ответом и просто вопросомнастроить его (никогда до этого не путался)?Есть ли другой способ пойти по этому поводу?Или я должен придерживаться имеющегося у меня решения?

* PS Имена функций без учета регистра также были бы отличным бонусом [text () против TEXT ()] НО я могу жить без этого, простобыть полезным для nooblets в моей команде, чтобы испытать меньше ошибок.:)

Answer 1

XML чувствителен к регистру.Мой обычный совет при написании преобразования, которое должно обрабатывать различные форматы ввода, - записать их в виде конвейера, в котором первая фаза избавляет от ненужных изменений, чтобы фаза «бизнес-логики» могла сосредоточиться на одной задаче, не отвлекаясь на разныевходные представления.

По сути, это решение, предложенное @ MadsHansen.

Другой способ сделать это (на саксонском) может быть изящным, хотя и немного сложным: вы можете реализовать собственную модель деревав котором имена элементов и атрибутов представлены в нормализованном регистре, скрывая любые вариации регистра в базовых данных.В Saxon есть много механизмов для реализации пользовательских моделей деревьев в качестве оберток над другими моделями деревьев, поэтому на самом деле это не будет большой объем кода;но знакомство с внутренностями Саксонии в достаточной степени, чтобы заставить его работать, было бы серьезной проблемой.

Мой реальный совет, однако, не начинать отсюда.То, как вы создали словарь XML, неверно.В XML «Straße» и «STRASSE» - это разные имена, и все инструменты XML будут рассматривать их как разные имена, и если вы хотите рассматривать их как альтернативные способы написания одного и того же имени, то вы идете против естественногопоток и это всегда увеличивает сложность и затраты.

В XPath параметры сортировки полезны для сравнения пользовательских данных: можно использовать параметры сортировки, в которых строки «Straße» и «STRASSE» считаются эквивалентными, когда они появляются втекстовое содержание элементов и атрибутов.Но они никогда не используются при сравнении имен элементов и атрибутов.

Answer 2

Этот XPath,

/*[lower-case(name()) = "root"]/*[lower-case(name()) = "item1"]/text()

будет охватывать ваши примеры без учета регистра.

Примечания:

1. Пожалуйста, не делайте этого. XML учитывает регистр символов при разработке и стандартизации.
2. Нет, не существует глобального способа объявления нечувствительности к регистру.См. № 1.
3. Нет, стандарт не должен уступать уникальным проектам;уникальные проекты должны уступить этому.