XML Mapping - XSLT или код?

Question

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

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

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

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

Спасибо

Answer 1

Во-первых, для ясности, XSLT - это код . ;) Это полный, функциональный язык программирования Тьюринга.

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

Тем не менее, действительная проблема заключается в том, доступны ли в команде навыки чтения и поддержки программы XSLT. Если люди не привыкли к функциональной парадигме, изучение XSLT может оказаться сложной задачей (то есть не произойдет во время проекта / компании), и часто решение должно быть сразу же доступно для чтения другим разработчикам / сопровождающим проекта. В этом случае, я бы (неохотно;) пошел на решение языка общего назначения.

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

Answer 2

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

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

Answer 3

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

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

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

Answer 4

Другие ответы достаточно хорошо объясняют причины использования XSLT; Я хочу ответить на ваш вопрос о поиске в базе данных.

Поиск в базе данных действительно выходит за рамки преобразования. То есть вы больше не преобразуете один формат XML в другой; вы включаете информацию из внешнего источника, которая не является частью вашего ввода. (Я предполагаю, что ваша база данных является большой и / или достаточно изменчивой, чтобы ее нельзя было представить XML-документом, который считывается в преобразование с помощью функции document, которая является самым простым способом сделать это.)

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

Может также стоить предварительно обработать исходный XML для обработки ситуаций, которые XSLT плохо обрабатывает. Например, если XML содержит строковые данные, которые по какой-то причине не были проанализированы в удобную для использования XML-форму, возможно, стоит проанализировать данные в препроцессоре и обновить XML, прежде чем передать его в преобразование. Хорошим примером является случай, когда исходный формат был разработан кем-то, кто считал, что даты должны быть представлены как MM/DD/YYYY или логические значения как Y и N. Вы можете обойти это в XSLT, конечно, но это часто упрощает вещи, если вы массируете ввод, чтобы преобразовать значения в канонические представления, прежде чем передать его в XSLT.