xml создание - Стоит ли XSLT?




шаблонов tutorial (25)

Некоторое время назад я начал проект, где я разработал XML-схему html-esque, чтобы авторы могли писать свой контент (учебный материал курса) в упрощенном формате, который затем был бы преобразован в HTML через XSLT. Я некоторое время играл с ним (боролся) и получил его на очень базовом уровне, но потом был слишком раздражен ограничениями, с которыми я сталкивался (что вполне могло быть ограничением моих знаний), и когда я читал блог, предлагающий канаву XSLT и просто напишите свой собственный XML-to-whatever парсер на выбранном вами языке, я с готовностью подскочил на него, и это получилось блестяще.

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

Я знаю, что XSLT имеет свое место, поскольку он является общепринятым стандартом, и что, если все пишут собственные интерпретаторы, 90% из них попадут на TheDailyWTF . Но учитывая, что это язык функционального стиля, а не процедурный стиль, с которым знакомы большинство программистов, для кого-то, кто приступает к осуществлению проекта, такого как мой собственный, вы бы рекомендовали им пойти по тому пути, который я сделал, или придерживаться его с помощью XSLT ?


Answers

Я должен признать предубеждение здесь, потому что я учу XSLT для жизни. Но, возможно, стоит покрыть области, в которых я вижу своих учеников. Они разделились на три группы: публикацию, банковское дело и Интернет.

Многие из ответов до сих пор можно было обобщить как «это не полезно для создания веб-сайтов» или «это не что-то вроде языка X». Многие технические люди проходят свою карьеру без участия функциональных / декларативных языков. Когда я преподаю, опытные люди Java / VB / C / etc - это те, у кого проблемы с языком (переменные - переменные в смысле алгебры, а не процедурное программирование, например). Это многие из людей, которые отвечают здесь - я никогда не встречался с Java, но из-за этого я не собираюсь критиковать язык.

Во многих случаях это неприемлемый инструмент для создания веб-сайтов - может быть лучше язык программирования общего назначения. Мне часто приходится брать очень большие XML-документы и представлять их в Интернете; XSLT делает это тривиальным. Студенты, которых я вижу в этом пространстве, как правило, занимаются обработкой наборов данных и представлением их в Интернете. XSLT, безусловно, не единственный применимый инструмент в этом пространстве. Однако многие из них используют DOM для этого, и XSLT, безусловно, менее болезненна.

Ученики банковского сектора, которых я вижу, используют коробку DataPower в целом. Это устройство XML, и оно используется для сидения между «говорящими» различными диалектами XML. Трансформация с одного языка XML на другой почти тривиальна в XSLT, и число студентов, посещающих мои курсы, увеличивается.

Окончательный набор учеников, которых я вижу, исходит из публикации (например, я). Эти люди, как правило, имеют огромные документы в XML (поверьте мне, публикация, поскольку индустрия очень сильно вписывается в XML), в течение многих лет существует техническая публикация, и сейчас публикуется публикация в области торговли. Эти документы должны обрабатываться (здесь приходит в голову вопрос о DocBook для ePub).

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

Это, конечно, не умирающий язык (объем работы, который я мне рассказываю, говорит мне об этом). Прямо сейчас, это немного «застряло», пока Microsoft не закончит свою (очень позднюю) реализацию XSLT 2. Но она все еще существует и, похоже, сильно зависит от моей точки зрения.


Я нашел XSLT довольно сложно работать.

У меня был опыт работы над системой, несколько подобной той, которую вы описываете. Моя компания отметила, что данные, которые мы возвращали из «среднего уровня», были в XML и что страницы должны отображаться в HTML, что также может быть XHTML, и они слышали, что XSL является стандартом для преобразования между XML форматы. Таким образом, «архитекторы» (под которыми я имею в виду людей, которые думают о глубоких дизайнерских мыслях, но, по-видимому, никогда не кодируют), решили, что наш передний уровень будет реализован путем написания сценариев XSLT, которые преобразуют данные в XHTML для отображения.

Выбор оказался катастрофическим. XSLT, оказывается, это боль, чтобы писать. И поэтому все наши страницы трудно писать и поддерживать. Мы бы намного лучше использовали JSP (это было на Java) или какой-то подобный подход, который использовал один вид разметки (угловые скобки) для формата вывода (HTML) и другой вид разметки (например, <% ... %>) для метаданных. Самая запутанная вещь в XSLT заключается в том, что она написана в XML, и она переводится с XML на XML ... довольно сложно держать все 3 разных XML-документа прямо в уме.

Ваша ситуация немного отличается: вместо написания каждой страницы в XSLT, как и я, вам нужно всего лишь написать один бит кода в XSLT (код для преобразования из шаблонов для отображения). Но похоже, что вы столкнулись с теми же трудностями, что и я. Я бы сказал, что попытка интерпретировать простой XML-язык DSL (специфичный для домена язык), как вы делаете, НЕ является одной из сильных сторон XSLT. (Хотя он МОЖЕТ выполнить эту работу ... ведь это Тьюринг завершен!)

Однако, если то, что у вас было, было проще: у вас есть данные в одном формате XML и вы хотите сделать для него простые изменения - не полное описание DSL-страниц, а некоторые простые простые изменения, тогда XSLT - отличный инструмент для этой цели. Это декларативный (не процедурный) характер на самом деле является преимуществом для этой цели.

- Майкл Чермсайд


Лично я использовал XSLT в совершенно другом контексте. Компьютерная игра, над которой я работал, в то время использовала тонны страниц пользовательского интерфейса, определенных с помощью XML. Во время крупного рефакторинга вскоре после релиза мы хотели изменить структуру этих XML-документов. Мы внесли формат ввода игры в гораздо более совершенную структуру и структуру схемы.

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

Кроме того, исходя из фона C ++, это был очень интересный и интересный язык для освоения.

Я считаю, что это инструмент для перевода XML из одного формата в другой, это фантастика. Однако это не единственный способ определить алгоритм, который принимает XML как входной сигнал и выводит что-то . Если ваш алгоритм достаточно сложный, то тот факт, что ввод XML становится неактуальным по вашему выбору инструмента - т. Е. Сворачивать свой собственный в C ++ / Python / что угодно.

Конкретный для вашего примера, я бы предположил, что наилучшей идеей было бы создать собственный XML-> XML-конвертер, который следует вашей бизнес-логике. Затем напишите переводчик XSLT, который просто знает о форматировании и не делает ничего умного. Это может быть хорошей средой, но это полностью зависит от того, что вы делаете. Наличие переводчика XSLT на выходе упрощает создание альтернативных форматов вывода - для печати, для мобильных телефонов и т. Д.


XSLT является примером en.wikipedia.org/wiki/Declarative_programming языка en.wikipedia.org/wiki/Declarative_programming .

Другие примеры декларативных языков программирования включают регулярные выражения, Prolog и SQL. Все они очень выразительны и компактны и, как правило, очень хорошо разработаны и мощны для задачи, для которой они разработаны.

Однако разработчики программного обеспечения обычно ненавидят такие языки, потому что они настолько отличаются от более распространенных ОО или процедурных языков, которые им трудно изучить и отлаживать. Их компактный характер, как правило, позволяет очень легко наносить много повреждений непреднамеренно.

Таким образом, хотя XSLT является эффективным механизмом для объединения данных в презентацию, он не работает в отделе простоты использования. Я верю, что именно поэтому он действительно не поймал.


Я провел много времени в XSLT и обнаружил, что, хотя это полезный инструмент в некоторых ситуациях, он определенно не исправляет все. Он отлично работает для целей B2B, когда он используется для перевода данных для машиночитаемого ввода / вывода XML. Я не думаю, что вы ошибаетесь в своем заявлении о своих ограничениях. Одной из вещей, которые разочаровали меня больше всего, были нюансы в реализации XSLT.

Возможно, вам стоит взглянуть на некоторые другие доступные языки разметки. Я считаю, что Джефф сделал статью об этой самой теме, касающейся переполнения стека.

Является ли HTML гуманным языком разметки?

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


XSLT не является окончательным преобразованием xml. Тем не менее, очень сложно судить, основываясь на приведенной информации, если бы это было наилучшим решением вашей проблемы или были другие более эффективные и поддерживаемые подходы. Вы говорите, что авторы могли ввести свой контент в упрощенном формате - в каком формате? Текстовые поля? В какой html вы его конвертировали? Чтобы судить о том, является ли XSLT правильным инструментом для работы, это поможет более подробно узнать особенности этого преобразования.


Если вы можете использовать XSLT в декларативном стиле (хотя я не совсем согласен с тем, что это декларативный язык), то я считаю полезным и выразительным.

Я написал веб-приложения, которые используют язык OO (C # в моем случае) для обработки уровня данных / обработки, но выводят XML, а не HTML. Затем это может быть использовано непосредственно клиентами как API данных или отображено как HTML с помощью XSLT. Поскольку C # выводил XML, который был структурно совместим с этим использованием, все было очень гладко, а логика представления оставалась декларативной. Легче было следить и изменять, чем отправлять теги из C #.

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

Конечно, в эти дни я бы, наверное, написал эти веб-приложения, используя интерфейс RESTful, и я думаю, что данные «языки», такие как JSON, набирают обороты в областях, которые XML традиционно трансформировал XSLT. Но пока XSLT по-прежнему остается важной и полезной технологией.


В настоящее время мне поручено соскабливать данные с общедоступного сайта (да, я знаю). К счастью, он соответствует xhtml, поэтому я могу использовать xslt для сбора необходимых мне данных. Полученное решение является читаемым, чистым и легко меняющимся в случае необходимости. Отлично!


Я использовал XML, XSD и XSLT в проекте интеграции между очень диссонированными системами БД в 2004 году. Мне пришлось изучать XSD и XSLT с нуля, но это было непросто. Самое замечательное в этих инструментах было то, что он позволил мне написать независимый от C ++ код, полагающийся на XSD и XSLT для проверки / проверки, а затем преобразования XML-документов. Измените формат данных, измените документы XSD и XSLT, а не код на C ++, который использовал библиотеки Xerces.

Для интереса: основной XSD составлял 150 КБ, а средний размер XSLT составлял <5 КБ IIRC.

Другим большим преимуществом является то, что XSD является спецификационным документом, на котором основан XSLT. Они работают в гармонии. И спецификации в наши дни редко встречаются в разработке программного обеспечения.

Хотя у меня не было слишком много проблем с изучением декларативного характера XSD и XSLT, я обнаружил, что другие программисты на C / C ++ испытывали большие трудности в адаптации к декларативному пути. Когда они увидели, что это так, а процедурные они пробормотали, теперь, когда я понимаю! И они продолжили (каламбур?), Чтобы написать процедурный XSLT! Дело в том, что вам нужно изучить XPath и понять оси XML. Напоминает мне о программистах старого времени, которые настраиваются на использование OO при написании C ++.

Я использовал эти инструменты, поскольку они позволили мне написать небольшую базу кода на C ++, которая была изолирована от всех, кроме самых фундаментальных модификаций структуры данных, и эти последние были изменениями структуры базы данных. Несмотря на то, что я предпочитаю C ++ для любого другого языка, я буду использовать то, что считаю полезным, чтобы извлечь выгоду из долгосрочной жизнеспособности программного проекта.


Раньше я думал, что XSLT - отличная идея. Я имею в виду, что это отличная идея.

Там, где это не удается, это исполнение.

Проблема, которую я обнаружил с течением времени, заключалась в том, что языки программирования в XML - всего лишь плохая идея. Это делает все непроницаемое. В частности, я считаю, что XSLT очень усердно изучает, кодирует и понимает. XML в дополнение к функциональным аспектам просто делает все это слишком запутанным. Я пытался узнать его примерно 5 раз в моей карьере, и он просто не придерживается.

Хорошо, вы могли бы «использовать» его - я думаю, что это отчасти было связано с его дизайном, но это вторая неудача: все инструменты XSLT на рынке - это просто ... дерьмо!


Это сводится к тому, что вам нужно. Его основная сила - легкая ремонтопригодность преобразования, и написание собственного анализатора, как правило, стирает это. С учетом сказанного, иногда система небольшая и простая и на самом деле не нуждается в «причудливом» решении. До тех пор, пока ваш основанный на кодах строитель заменяется без изменения другого кода, не имеет большого значения.

Что касается уродства XSL, да, это уродливо. Да, к этому нужно привыкнуть. Но как только вы получите зависание (не должно длиться долгое время IMO), на самом деле это плавное плавание. Скомпилированные преобразования выполняются довольно быстро в моем опыте, и вы можете, конечно, отлаживать их.


Раньше я использовал XSLT. Группа из 6 файлов .xslt (реорганизована из одного большого) составляла около 2750 строк, прежде чем я переписал ее на C #. В настоящее время код C # содержит 4000 строк, содержащих много логики; Я даже не хочу думать о том, что было бы написано в XSLT.

То, что я сдался, - это когда я понял, что XPATH 2.0 существенно не мешает моему прогрессу.


Мне лично нравится XSLT, и вы можете захотеть упростить синтаксис (без явных шаблонов, просто обычный старый HTML-файл с несколькими тегами XSLT, чтобы вставлять в него значения), но это не для всех.

Возможно, вы просто хотите предложить своим авторам простой интерфейс Wiki или Markdown. Для этого есть библиотеки, и если XSLT не работает для вас, возможно, XML тоже не работает для них.


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

Да, это боль, когда вы учитесь, но большая часть боли связана с знакомством. Когда вы изучаете язык, боль уменьшается.

У W3schools есть две статьи, которые особенно ценны: http://www.w3schools.com/xpath/xpath_functions.asp http://www.w3schools.com/xsl/xsl_functions.asp


Мне нравится использовать XSLT только для изменения древовидной структуры XML-документов. Я считаю громоздким сделать что-либо, связанное с обработкой текста, и отменить его на собственный скрипт, который я могу выполнить до или после применения XSLT в XML-документе.

XSLT 2.0 включал в себя гораздо больше строковых функций, но я думаю, что это не подходит для языка, и не так много реализаций XSLT 2.0.


Мы широко используем XSLT для таких вещей, как документация, и сделаем некоторые сложные параметры конфигурации доступными для пользователя.

Для документации мы используем много DocBook, который представляет собой формат на основе XML. Это позволяет нам хранить и управлять нашей документацией со всем исходным кодом, так как файлы являются простым текстом. С XSLT мы можем легко создавать собственные форматы документации, позволяя нам как автогенерировать контент в общем виде, так и делать контент более читаемым. Например, когда мы публикуем заметки о выпуске, мы можем создать XML, который выглядит примерно так:

<ReleaseNotes>
    <FixedBugs>
        <Bug id="123" component="Admin">Error when clicking the Foo button</Bug>
        <Bug id="125" component="Core">Crash at startup when configuration is missing</Bug>
        <Bug id="127" component="Admin">Error when clicking the Bar button</Bug>
    </FixedBugs>
</ReleaseNotes>

И затем, используя XSLT (который преобразует вышеуказанное в DocBook), мы получаем замечательные примечания к выпуску (обычно PDF или HTML), где идентификаторы ошибок автоматически связаны с нашим трекером ошибок, ошибки группируются по компонентам, а формат всего абсолютно согласован , И вышеупомянутый XML может быть сгенерирован автоматически, запросив наш трекер ошибок для того, что изменилось между версиями.

Другое место, где мы нашли XSLT полезным, действительно находится в нашем основном продукте. Иногда при взаимодействии с сторонними системами нам нужно как-то обрабатывать данные на сложной HTML-странице. Анализ HTML является уродливым, поэтому мы передаем данные через нечто вроде TagSoup (который генерирует надлежащие события SAX XML, по сути, позволяя нам иметь дело с HTML, как если бы он был правильно написан XML), а затем мы можем запустить некоторый XSLT против него, чтобы включить данных в «известный стабильный» формат, с которым мы можем работать. Разделив это преобразование на XSLT-файл, это означает, что если и когда формат HTML изменяется, само приложение не нуждается в обновлении, вместо этого конечный пользователь может просто отредактировать сам файл XSLT, или мы можем отправить по электронной почте им обновлен XSLT-файл без всей системы, нуждающейся в обновлении.

Я бы сказал, что для веб-проектов есть лучшие способы обработки стороны представления, чем XSLT сегодня, но как технология, определенная для XSLT. Это не самый простой язык в мире, но он определенно не мертв, и с моей точки зрения все еще есть много хороших применений.


Чтобы ответить на три вопроса:

  1. Я использовал XSLT несколько лет назад.
  2. Я считаю, что XSLT может быть правильным решением при определенных обстоятельствах. (Никогда не говори никогда)
  3. Я склонен согласиться с вашей оценкой, что он в основном полезен для «простых» преобразований. Но я думаю, что до тех пор, пока вы хорошо понимаете XSLT, есть случай, когда нужно использовать его для более крупных задач, таких как публикация веб-сайта с преобразованием XML в HTML.

Я считаю, что многие разработчики не любят XSLT, потому что они не понимают принципиально иной парадигмы, на которой она основана. Но с недавним интересом к функциональному программированию мы могли бы увидеть, что XSLT делает возвращение ...


В предыдущей компании мы много работали с XML и XSLT. И XML, и XSLT большие.

Да, есть кривая обучения, но тогда у вас есть мощный инструмент для обработки XML. И вы даже можете использовать XSLT на XSLT (что иногда может быть полезно).

Производительность также является проблемой (с очень большим XML), но вы можете решить это с помощью смарт-XSLT и выполнить некоторую предварительную обработку с помощью (сгенерированного) XML.

Любой, кто знает XSLT, может изменить внешний вид готового продукта, потому что он не скомпилирован.


С XSLT работать сложно, но как только вы его победите, вы получите очень глубокое понимание DOM и схемы. Если вы также XPath, то вы на пути к изучению функционального программирования, и это откроет новые методы и способы решения проблем. В некоторых случаях последовательная трансформация более эффективна, чем процедурные решения.


Столько негатива!

Я использую XSLT в течение нескольких лет и искренне люблю его. Главное, что вы должны понять, это то, что это не язык программирования, это язык шаблонов (и в этом отношении я считаю его неописуемо превосходящим asp.net / spit).

XML - это фактический формат данных веб-разработки сегодня, будь то файлы конфигурации, исходные данные или репрезентация памяти. XSLT и XPath предоставляют вам чрезвычайно мощный и очень эффективный способ преобразования этих данных в любой выходной формат, который вам может понравиться, мгновенно предоставляя вам этот MVC-аспект разделения презентации на данные.

Тогда есть утилиты: вымывание пространств имен, распознавание разрозненных определений схем, объединение документов.

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

Случай использования в реальном мире: я просто написал приложение, которое обрабатывает XML-документы в памяти во всей системе и преобразуется в JSON, HTML или XML по просьбе конечного пользователя. У меня был случайный запрос предоставить данные Excel. Бывший коллега сделал что-то подобное программно, но ему нужен модуль из нескольких файлов классов и что на сервере установлен MS Office! Оказывается, в Excel есть XSD: новая функциональность с минимальным эффектом базового кода за 3 часа.

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

Очевидно, я твердо верю, что это «стоит того».


Я по-прежнему считаю, что XSLT может быть полезен, но это уродливый язык и может привести к ужасному нечитаемому, неудержимому беспорядку. Отчасти потому, что XML недостаточно читабельен для того, чтобы составлять «язык», а отчасти потому, что XSLT где-то застрял между декларативными и процедурными. Сказав это, и я думаю, что сравнение может быть проведено с помощью регулярных выражений, оно использует его, когда дело касается простых четко определенных проблем.

Использование альтернативного подхода и анализ XML в коде могут быть одинаково неприятными, и вы действительно хотите использовать какую-либо технологию XML-маршаллинга / привязки (например, JiBX в Java), которая преобразует ваш XML прямо в объект.


Я использую XSLT (из-за отсутствия лучшей альтернативы), но не для презентации, просто для преобразования:

  1. Я пишу короткие преобразования XSLT, чтобы делать массовые изменения в наших файлах maven pom.xml.

  2. Я написал конвейер преобразований для создания XML-схем из XMI (UML Diagram). Он работал некоторое время, но он, наконец, стал слишком сложным, и нам пришлось вытащить его за сарай.

  3. Я использовал преобразования для реорганизации XML-схем.

  4. Я работал над некоторыми ограничениями в XSLT, используя его для генерации XSLT для выполнения реальной работы. (Когда-либо пытались написать XSLT, который производит вывод с использованием пространств имен, которые неизвестны до выполнения?)

Я продолжаю возвращаться к нему, потому что он лучше справляется с работой над обработкой XML, чем другие подходы, которые я пробовал, которые казались бесполезными или просто неправильно понимали XML. XSLT неприятен, но я считаю, что использование Oxygen делает его приемлемым.

Тем не менее, я изучаю использование Clojure (lisp) для выполнения преобразований XML, но я еще недостаточно далеко, чтобы узнать, принесет ли мне этот подход.


Я помню всю шумиху вокруг XSLT, когда стандарт был недавно выпущен. Все волнение вокруг возможности создания всего HTML-интерфейса с «простым» преобразованием.

Посмотрим правде в глаза, это трудно использовать, почти невозможно отлаживать, часто невыносимо медленно. Конечный результат почти всегда причудливый и менее идеальный.

Я скорее буду грызть свою ногу, чем использовать XSLT, тогда как есть лучшие способы сделать что-то. Тем не менее у него есть свои места, это хорошо для простых задач преобразования.


Да, я использую это много. Используя разные файлы xslt, я могу использовать один и тот же источник XML для создания нескольких HTML-файлов polyglot (X) (представляющих одни и те же данные по-разному), RSS-фида, фида Atom, файла дескриптора RDF и фрагмента карты сайта ,

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


Это очень легко сделать с помощью XSLT ( нет необходимости записывать результаты в переменную или использовать специальные именованные шаблоны ):

I. XSLT 1.0 :

<xsl:stylesheet version="1.0"
 xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
 <xsl:output method="text"/>

    <xsl:template match="/*/*">
      <xsl:for-each select=
      "Locality/text() | CollectorAndNumber/text()
     | Institution/text() | Distribution/text()
     | Note/text()
      "
      >
        <xsl:value-of select="."/>
        <xsl:if test="not(position() = last())">,</xsl:if>
      </xsl:for-each>
    </xsl:template>
</xsl:stylesheet>

когда это преобразование применяется к следующему XML-документу:

<root>
    <record>
        <Locality>Locality</Locality>
        <CollectorAndNumber>CollectorAndNumber</CollectorAndNumber>
        <Institution>Institution</Institution>
        <Distribution>Distribution</Distribution>
        <Note></Note>
        <OtherStuff>Unimportant</OtherStuff>
    </record>
</root>

получается желаемый результат :

Locality,CollectorAndNumber,Institution,Distribution

Если требуемые элементы должны быть созданы не в порядке документа (что-то не требуется в вопросе, но поднято Tomalak), все же довольно легко и элегантно добиться этого:

<xsl:stylesheet version="1.0"
 xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    <xsl:output method="text"/>

    <xsl:param name="porderedNames"
     select="' CollectorAndNumber Locality Distribution Institution Note '"/>

    <xsl:template match="/*/*">
        <xsl:for-each select=
         "*[contains($porderedNames, concat(' ',name(), ' '))]">

         <xsl:sort data-type="number"
          select="string-length(
                     substring-before($porderedNames,
                                      concat(' ',name(), ' ')
                                      )
                                )"/>

            <xsl:value-of select="."/>
            <xsl:if test="not(position() = last())">,</xsl:if>
        </xsl:for-each>
    </xsl:template>
</xsl:stylesheet>

Здесь имена $porderedNames элементов и их требуемый порядок указаны в $porderedNames параметре $porderedNames , который содержит список всех $porderedNames , $porderedNames .

Когда указанное преобразование применяется к одному и тому же XML-документу, создается желаемый результат :

CollectorAndNumber,Locality,Distribution,Institution

II. XSLT 2.0 :

В XSLT эта задача еще проще ( опять же, никакой специальной функции не требуется ):

<xsl:stylesheet version="2.0"
 xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
 <xsl:output method="text"/>

    <xsl:template match="/*/*">
    <xsl:value-of separator="," select=
    "(Locality, CollectorAndNumber,
     Institution, Distribution,
     Note)[text()]" />
    </xsl:template>
</xsl:stylesheet>

Когда это преобразование применяется к одному и тому же XML-документу, получается тот же самый правильный результат :

Locality,CollectorAndNumber,Institution,Distribution

Обратите внимание, что нужные элементы будут создаваться в любом желаемом порядке, потому что мы используем тип последовательности XPath 2.0 (vs объединение в решении XSLT 1.0), которое по определению содержит элементы в любом желаемом (указанном) порядке.





xml xslt