Как (красиво) шаблон сопоставить несколько определенных дочерних элементов (объединение) в более широком XPATH

Я просмотрел все, и большинство ответов на похожие проблемы включали копирование повторяющейся части XPATH в каждый элемент и объединение всего этого вместе. Но есть способ получше! Легко забыть, что сопоставление определенного элемента относительно эквивалентно сопоставлению имени этого элемента в XPATH.

Используйте name() или local-name() вместо сопоставления элемента непосредственно в шаблоне сопоставления *.

Помните о проблемах / потребностях вашего пространства имен при выборе того, что использовать. Это по-прежнему позволяет использовать расширенные условия для атрибутов и т. Д. Этих элементов.

Например, первое совпадение выглядит следующим образом:

 <xsl:template match="div[contains(@class, 'special-sauce')//
     element()[local-name() = ('input', 'select')]">

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

Где это действительно хорошо видно, так это последний пример в вопросе (беспорядок):

 <xsl:template match="div[contains(@class, 'major-mess')]/
     div[contains(@class, 'special-sauce')]//
     element()[local-name() = ('dataset', 'optgroup', 'fieldset')]//
     element()[local-name() = ('button', 'option', 'label')]">

И поскольку я не могу вспомнить, полностью ли это XSLT / XPATH 1.0 совместимо путем создания фрагмента дерева элементов в скобках для сравнения, если вам действительно нужна обратная совместимость, «contains() с скобками разделителей» (уменьшая вероятность ложного срабатывания от другого элемента будучи подстрокой целевого полного имени) тоже всегда работает:

 <xsl:template match="div[contains(@class, 'major-mess')]/
     div[contains(@class, 'special-sauce')]//
     element()[contains('|dataset|optgroup|fieldset|'), concat('|', local-name(), '|'))]//
     element()[contains('|button|option|label|', concat('|', local-name(), '|'))]">

* = "шаблон соответствия" vs "XPath"

Если вам сложно понять, почему наивный подход (первое, что я попытался использовать в вопросе) терпит неудачу в XSLT, поможет понять, что правила шаблона, такие как «соответствие», должны следовать XSLT-шаблоны, которые, по сути, являются лишь подмножеством допустимых выражений XPath (что легко усложняет различение и запоминание, особенно когда многие источники просто притвориться, что это весь XPath целиком). Обратите внимание, что круглые скобки отображаются только как допустимый вариант для использования в качестве токенов выражений, которые находятся только в выражениях в пределах предикатов, а не в любой другой части пути к местоположению или расположение шагов.

Заключительные соображения

Производительность: я понятия не имею, есть ли заметные различия в производительности с этим подходом по сравнению с объединением каждого отдельного элемента в качестве полного пути к каждому из них, или есть даже реальная разница в производительности между обращением к элементу изначально и как предикат анонимного element() селектор. Я подозреваю, что, хотя большинство процессоров XSLT, вероятно, могут добиться более быстрого поиска в дереве DOM, когда одно совпадение записывается с использованием собственной структуры пути по сравнению с предикатом с функцией name () в анонимном селекторе, случаи объединения могут выполняться быстрее в зависимости от того, насколько хорошо процессор пытается предварительно скомпилировать и оптимизировать для логических шаблонов. Я оставлю эту задачу кому-то другому, чтобы он попробовал провести сравнительный анализ, потому что в конечном итоге реальным препятствием становится разумность разработчика и проблемы с обслуживанием (вероятность возникновения человеческих ошибок). Я считаю, что в сложных матчах любое небольшое снижение производительности, вероятно, будет легко компенсировано простой читаемостью и уменьшенной / устраненной избыточностью данных этого подхода.

Я думаю, что ваш шаблон законен в XSLT 3.0, как написано. Но я думаю, вам нужно решение XSLT 2.0 ...

Один отличный способ, который люди часто упускают из виду, - это использование шаблонов, поддерживающих схемы. Если вы хотите сопоставить выбор элементов, вполне вероятно, что они тесно связаны в схеме, например, имея общий тип T или будучи членами группы подстановки S. Затем вы можете написать

div[contains(@class, 'special-sauce')//schema-element(S)

or

div[contains(@class, 'special-sauce')//element(*, T)

Но я думаю, вам нужно решение, которое не поддерживает схему ...

В таком случае я не думаю, что могу предложить что-то лучше, чем то, что есть у вас.

Иногда ответом является несколько режимов: например, что-то вроде

<xsl:template match="div[contains(@class, 'special-sauce')]">
  <xsl:apply-templates mode="special"/>
</xsl:template>

<xsl:template match="select|input" mode="special">

В целом я считаю, что режимы используются недостаточно.

Почему бы не разделить этот шаблон на два или три (по одному для каждого уровня) с режимами? Что-то типа

<xsl:template match="div[contains(@class, 'special-sauce')">
  <xsl:apply-templates select=".//select|input" mode="special-sauce"/>
</xsl:template>

<xsl:template match="select|input" mode="special-sauce">
  <!-- ... -->
</xsl:template>

На мой взгляд, так читается яснее.