Отличный вопрос.
Иногда нужны именно свойства атрибута: уникальность, примитивность, неделимость.
Кстати, в спеке написано:
Attributes are used to associate name-value pairs with elements.
Ещё атрибуты бывают разных типов: https://www.w3.org/TR/2008/REC-xml-20081126/#sec-attribute-types
#ID
для атрибута-идентификатора (*/@id
в HTML), по ним потом можно выбирать элементы xpath-функциейid()
;#IDREF
и#IDREFS
для ссылок на ID (label/@for
,th/@headers
в HTML);#NMTOKEN
и#NMTOKENS
для атрибутов-имён (a/@name
,map/@name
в HTML).
См. для примера DTD от XHTML: https://www.w3.org/TR/xhtml1/dtds.html#a_dtd_XHTML-1.0-Strict
Это всё делается, описывается и поддерживается встроенными средствами XML.
2) Почему встроенные шаблоны не выводят атрибуты?
Потому что первый встроенный шаблон вызывает <apply-templates/>
без select
, который применяется ко всем дочерним элементам (ось child
), но не к атрибутам (ось attribute
).
https://www.w3.org/TR/xslt-10/#section-Applying-Template-Rules:
В отсутствие атрибута select инструкция xsl:apply-templates обрабатывает все непосредственные потомки текущего узла, включая узлы текста.
См. пункт №1 в https://www.w3.org/TR/xslt-10/#conflict:
Во-первых, из рассмотрения исключаются все соответствующие узлу правила шаблона, которые имеют более низкий приоритет импорта, чем проверяемое правило шаблона и правила с наивысшим приоритетом импорта.
То есть, как мы и говорили, никакой подключённый шаблон не может иметь приоритет больше локального, если только не используется <xsl:apply-imports/>
.
Я вас немного обманул, они конечно же одинаковые, отличается приоритет у матча на произвольный элемент неймспейса: foo:*
.
Итого:
Приоритет -0.5 только у шаблонов с match="*"
и match="node()"
.
Приоритет -0.5 только у шаблонов с match="foo:*"
.
Приоритет 0 только у шаблонов с match="account"
и match="foo:account"
.
У любых других приоритет 0.5, так что приоритет регулируются в основном порядком шаблонов в файле и импортами.
Посмотреть приоритеты можно, запустив xsltproc
с параметром --verbose
.
В презентации поправил.
Помимо схлопывания пробелов (и переводов строк!) вокруг <xsl:text>
, о котором мы говорили, и возможности использовать атрибут disable-output-escaping="yes"
у элементов <xsl:text>
/<xsl:value-of>
я не обнаружил никаких отличий.
В xml-режиме трансформации символы <>&
эскейпятся как внутри <xsl:text>
, так и в обычных текстовых нодах.
В текстовом режиме трансформации не эскейпятся и выдаются прямо <>&
(логично).
https://www.w3.org/TR/xslt-10/#disable-output-escaping:
Обычно метод вывода xml, представляя текстовые узлы, маскирует
&
и<
(а также, возможно, и другие символы). Тем самым обеспечивается вывод корректного XML документа.
А disable-output-escaping
нужен в том случае, если вы хотите вывести подготовленную где-то в другом месте разметку и уверены в ней, либо если вы по каким-то причинам хотите нарисовать элемент «вручную». Такой код выведет <br/>
:
<xsl:text disable-output-escaping="yes"><br/></xsl:text>
Судя по вопросам после лекции, нужно было отдельно упомянуть о том.
У нас в понятие фронтенда входит тот вью-слой на питоне, о котором мы говорили, на самом деле для браузера это самый что ни на есть бэкенд.
В браузере тоже можно, но это неудобно и никто так не делает + есть отличия в поддержке.
Я поднял архивы, и действительно:
цель иметь все сервисы на одной платформе и языке Цель именно один язык.
Ещё так можно использовать Джава-клиенты бэкендов вместо тупого РЕСТа. Ну и понадёжнее всё же, с типизацией и всеми делами.
Однако есть мнение, что настоящая причина — чтобы фронтендеры писали только фронт и не писали бизнес-логику, а полубоги-бекэндеры могли делать всё остальное, включая интеграционную логику. Просто бекэндеры не могут в Питон.
¯\_(ツ)_/¯
На самом деле многие могут, и бэкендеры в Питон, и некоторые фронтендеры в Джаву.