XPATH + XML = быстрая обработка

[gleb_l]

Синтаксис XPath настолько корявый, что забывается раньше, чем взгляд разработчика перемещается от страницы в MSDN до открытого окна студии. Одна только нотация с использованием тире вместо подчеркивания, заимствованная из мира каскадных таблиц стилей, чего стоит! Восходит, наверное, к 5-битным телеграфным кодировкам, когда нижнего подчеркивания еще не было. Ощущение, что пишешь инструкции какому-то роботу из фантастического фильма 50-х годов.

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

PS — в поясниловке много синтаксических ошибок — не OCR-ом ли пользовались — subling вместо sibling, например, но как компактный справочник под рукой — неплохо сгодится.

[tuxi]

С момента появления первой реализации xpath (и xslt) уже прошло столько времени, что если бы в нем можно было бы что-то улучшить кардинально — уже улучшили бы. И насчет css: xpath это курица, а css это яйцо, но не наоборот)

[gleb_l]

если бы в нем можно было бы что-то улучшить кардинально — уже улучшили бы

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

На XPath можно писать шаблоны, и если делать это часто, можно даже не ощущать дискомфорта (подобно тому, как нас абсолютно устраивает нотация оператора присваивания X = Y — для непрограммиста такая интерпретация покажется извращенной). Видимо, поэтому необходимости в усовершенствовании синтаксиса XPath не было — поскольку, как хороший летчик может летать на всем, что способно передвигаться по воздуху, так и хороший программист плюется, но пишет на всем, на чем возможно закодировать какую-нибудь последовательность действий ;)

Что касается курицы или яйца — спасибо, что напомнили — обе этих технологии появились ЕМНИП в конце 90-х, но мне почему-то запомнилось, что CSS был раньше :) Может быть потому, что тупо XSLT в разработке пришлось использовать позже, чем руками клепать HTML/CSS

[tuxi]

шаблоны пишут на xslt, на xpath пишут запросы
просто xpath самодостаточный

[Tsimur_S]

Единственно место в 2020 году, где про xpath помнят, это написание селекторов для парсинга сайтов и автоматизированных тестов в браузере. И то он применяется в редких случаях, когда нужно делать поиск вверх по дереву от найденого элемента(например найти предка div элемента с заданным id). CSS движки спроектированы под один проход и поэтому не способны сделать такой поиск.
Во всех же остальных случаях он вместе с XSLT, Xquery и тд завернулся в одеяло и медленно перемещается в сторону кладбища.

[vagon333]

Во всех же остальных случаях он вместе с XSLT, Xquery и тд завернулся в одеяло и медленно перемещается в сторону кладбища.

Прочитал ваш комментарий и взял новый проект по трансформации XML, валидации против XSD и DTD, написании набора правил согласно спецификации XML структур на 400+ страницах. :)
Критика должна быть конструктивной: если хороним XML, XSD, XSLT, Xquery, то нужна альтернатива. Иначе, субъективный негатив.

[a-tk]

Стильно, модно, молодёжно же JSON. Только вот с самодостаточностью у него всё плохо, а аналоги, приехавшие из мира XML, либо уродливы, либо неполноценны.
Если взять JPath (аналог XPath), то он куда менее логичен, чем JPath, и многословен.
JSON Schema тоже вроде есть, но проблемы те же, что у JPath.

Так что пойду запилю очередную XSLT-шку.

[tuxi]

с конца нулевых хоронят, все никак похоронить не могут :)))
xslt/xpath живет и здравствует и в новых проектах используется