Ну, по сравнению с решением на sed задачи, тривиальной для xmlstarlet (с использованием в качестве формата данных какой-нибуль приятной и удобочитаемой LALR-грамматики вроде c-подобного синтаксиса в конфигах bind) он не такой уж громоздкий и косноязычный. XPath все-таки достаточно удобная штука.
Верно. Зачем нужны sed и grep, когда есть XSLT? Там во второй версии даже регвыражения вроде пробили, все как у людей. Если и этого не хватает, тут уже что-то на серьезном скриптовом языке надо писать.
XSLT, к сожалению, ни в каком виде не имеет eval-режима.
Минимальный объем XSLT - всё же шаблон строк на 10.
Вместо дерга grep или sed ну никак не катит. А вот просто выборки xpath очень хороши, но вот чего не хватает в голом xpath, так это переменных для выполнения в несколько шагов: хочется выбрать $a = //A[...]; а потом уже вывести $a/../../something.
Да-да Можно сказать grep строка файл Можно сказать xpath дорожка файл Это займет десять секунд.
А вот нельзя сказать xsltproc шаблон файл, потому что шаблон написать надо, а это уже минимум минут пять. Поэтому я всячески приветствую создание инструментов более простых, чем полноценный XSLT, но более мощных, чем простой xpath.
Наконец?! Да я им уже года три как пользуюсь! А вообще, если вас интересуют утилиты для grep-анья XML, могу кроме XMLStarlet посоветовать также Xtract (http://www.cs.york.ac.uk/fp/Xtract/) и sgrep (http://www.cs.helsinki.fi/u/jjaakkol/sgrep.html) (последний выглядит более мощным, но под Windows мне его запустить не удалось)
Не подскажешь, можно ли сделать при помощи xmlstarlet выборку по таблице, нужно пройтись по всем //is/i/@t и по ним распечать //es/e/@y если //es/e/@x == @ ?
xml sel -t -m //is/i -m //es/e[@x=/@t] -v @y -n lookup.xml не знаю, что ставить на месте ???
Если не два вложеных xsl:for-each ( вложенных -m ), а просто //es/e[@x=//is/i/@t], то кажется //is/i/@t воспринимается как множество, а не как список, поэтому игнорируется порядок дубликатов.
PS. в XSLT и XPath сильно плаваю, знаю только самые-самые верха. Пробовал поискать в гугле, но испльзуются некие xsl:variable которые тут из командной строки недоступны.
Кстати, у меня сложилось впечатление, что проще писать циклы в скрипте по DOM-дереву, с выборкой по xpath, чем XSLT, хотя и это наверное и не оптимально. Есть ли какой-то общепризнанный синтаксический сахар над XSLT?
Сработало, спасибо! xml sel -t -m //is/i/@t -v //es/e[@x=current()]/@y -n test.xml
PS. Когда искал синтаксический сахар, нашёл SLAX, обсуждение (http://www.mail-archive.com/xslt@gnome.org/msg00674.html), код (http://code.google.com/p/libslax/), дока (http://www.juniper.net/techpubs/software/junos/junos83/swconfig83-automation/download/slax-overview.pdf). Попробовал скомпилировать, но запустить реальные примеры пока не получилось.
no subject
Date: 2009-02-19 09:35 am (UTC)Так что xml это по прежнему не формат для людей.
no subject
Date: 2009-02-19 10:11 am (UTC)no subject
Date: 2009-02-19 01:51 pm (UTC)no subject
Date: 2009-02-19 10:42 am (UTC)P.S. xpath дает прикурить всему.
no subject
Date: 2009-02-19 11:45 am (UTC)no subject
Date: 2009-02-19 11:49 am (UTC)no subject
Date: 2009-02-19 09:24 pm (UTC)Верно. Зачем нужны sed и grep, когда есть XSLT? Там во второй версии даже регвыражения вроде пробили, все как у людей. Если и этого не хватает, тут уже что-то на серьезном скриптовом языке надо писать.
no subject
Date: 2009-02-19 10:00 pm (UTC)Минимальный объем XSLT - всё же шаблон строк на 10.
Вместо дерга grep или sed ну никак не катит. А вот просто выборки xpath очень хороши, но вот чего не хватает в голом xpath, так это переменных для выполнения в несколько шагов: хочется выбрать $a = //A[...]; а потом уже вывести $a/../../something.
no subject
Date: 2009-02-19 10:03 pm (UTC)Ну, он много чего не имеет... Это для чего-то конкретно нужно?
no subject
Date: 2009-02-19 10:08 pm (UTC)no subject
Date: 2009-02-20 08:13 am (UTC)Можно сказать grep строка файл
Можно сказать xpath дорожка файл
Это займет десять секунд.
А вот нельзя сказать xsltproc шаблон файл, потому что шаблон написать надо, а это уже минимум минут пять.
Поэтому я всячески приветствую создание инструментов более простых, чем полноценный XSLT, но более мощных, чем простой xpath.
no subject
Date: 2009-02-19 06:39 pm (UTC)А вообще, если вас интересуют утилиты для grep-анья XML, могу кроме XMLStarlet посоветовать также Xtract (http://www.cs.york.ac.uk/fp/Xtract/) и sgrep (http://www.cs.helsinki.fi/u/jjaakkol/sgrep.html) (последний выглядит более мощным, но под Windows мне его запустить не удалось)
no subject
Date: 2009-02-20 04:30 am (UTC)Ну вот уж Витуса это врядли опечалит. ;)
no subject
Date: 2009-03-01 10:14 pm (UTC)<root> <is> <i t="a"/> <i t="a"/> <i t="a"/> <i t="b"/> <i t="b"/> <i t="a"/> <i t="c"/> </is> <es> <e x="a" y="111"/> <e x="b" y="222"/> <e x="c" y="333"/> </es> </root> превращается в 111 111 111 222 222 111 333xml sel -t -m //is/i -m //es/e[@x=/@t] -v @y -n lookup.xml
не знаю, что ставить на месте ???
Если не два вложеных xsl:for-each ( вложенных -m ), а просто //es/e[@x=//is/i/@t], то кажется //is/i/@t воспринимается как множество, а не как список, поэтому игнорируется порядок дубликатов.
PS. в XSLT и XPath сильно плаваю, знаю только самые-самые верха. Пробовал поискать в гугле, но испльзуются некие xsl:variable которые тут из командной строки недоступны.
Кстати, у меня сложилось впечатление, что проще писать циклы в скрипте по DOM-дереву, с выборкой по xpath, чем XSLT, хотя и это наверное и не оптимально. Есть ли какой-то общепризнанный синтаксический сахар над XSLT?
no subject
Date: 2009-03-02 08:19 am (UTC)no subject
Date: 2009-03-02 10:53 pm (UTC)xml sel -t -m //is/i/@t -v //es/e[@x=current()]/@y -n test.xml
PS. Когда искал синтаксический сахар, нашёл SLAX, обсуждение (http://www.mail-archive.com/xslt@gnome.org/msg00674.html), код (http://code.google.com/p/libslax/), дока (http://www.juniper.net/techpubs/software/junos/junos83/swconfig83-automation/download/slax-overview.pdf). Попробовал скомпилировать, но запустить реальные примеры пока не получилось.