Описание XML и XSLT


Содержание

Простая таблица / XML-XSLT

Первый шаг — это, как всегда, добавление шаблона преобразования. Модифицируем наш файл, добавив в него ссылку на шаблон. В результате получим файл ex03-1.xml.

В этот файл добавлен шаблон преобразования ex03-1.xsl.

Рассмотрим этот шаблон подробнее. Вот его текст.

Первая строка — новая для вас в XSL-файле (но не в XML-файлах!). Она говорит о том, что в XSL-файле нужно нормально воспринимать русские буквы. Без этой строки браузер не сможет корректно обработать русский текст в XSL-файле. Следующие две строки шаблона являются уже привычными. Следующие шесть строк — это строка, содержащая заголовки столбцов таблицы. Конструкция для извлечения текста заголовков таблицы вам уже знакома. А вот десятая строка тоже является новой:

Этот элемент шаблона позволяет выбрать и просмотреть все группы информации, полный путь к которым задается списком тегов «tutorial/enimals/dogs/dog». Обратите внимание — путь задается полностью, ни один из тегов опустить нельзя. Далее в ячейки таблицы помещается информация о наших собаках. В отличие от первых примеров путь к соответствующей информации тоже задается полностью. Попробуем, например, разместить информацию о кличке чуть-чуть иначе ex03-2.xml:

Если мы в соответствующем XSL-файле поставим ссылку , то в соответствующем столбце никакой клички мы не увидим. Ссылка должна быть полной — . Вы можете самостоятельно поэкспериментировать с файлом ex03-2.xsl. Правильный результат приведен ниже.

Стилевые таблицы XSL

В предыдущем разделе для вывода элементов XML-документа на экран броузера мы применяли Java Script-сценарии Однако, как уже отмечалось, для этих целей предпочтительней использование специально предназначенного для этого средства — стилевых таблиц XSL (Extensible Stylesheet Language).

Стилевыми таблицами (стилевыми листами) принято называть специальные инструкции, управляющие процессом отображения элемента в окне программы-клиента(например, в окне броузера). Предложенные в качестве рекомендация W3C, каскадные стилевые таблицы (CSS-Cascading Style Sheets) уже больше года используются Web-разработчиками для оформления Web-страниц.

Поддержка CSS наиболее известными на сегодняшний день броузерами Opera и Microsoft Internet Explorer (начиная с версии 3.0) и Mozilla Firefox позволила использовать стилевые таблицы для решения самого широкого спектра задач — от оформления домашней странички до создания крупного корпоративного Web-узла. Слово каскадные в определении CSS означает возможность объединения отдельных элементов форматирования путем вложенных описаний стиля. Например, атрибуты текста, заданные в тэге , будут распространяться на вложенные тэги до тех пор, пока в них не встретятся стилевые описания, отменяющие или дополняющие текущие параметры. Таким образом, использование таблиц CSS в HTML было весьма эффективно — отпадала необходимость явного задания тэгов форматирования для каждого из элементов документа.

Являясь очень мощным средством оформления HTML-страниц, CSS-таблицы, тем не менее, не могут применяться в XML-документах, т.к. набор тэгов в этом языке не ограничен и использование статических ссылок на форматируемые объекты документа в этом случае невозможно.

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

Некоторые его отличия от CSS:

Во-первых, стилевые таблицы XSL позволяют определять оформление элемента в зависимости от его месторасположения внутри документа, т.е. к двум элементам с одинаковым названием могут применяться различные правила форматирования.
Во-вторых, языком, лежащем в основе XSL, является XML, а это означает, что XSL более гибок, универсален и у разработчиков появляется возможность использования средства для контроля за корректностью составления таких стилевых списков(используя DTD или схемы данных)
В-третьих, таблицы XSL не являются каскадными, подобно CSS, т.к. чрезвычайно сложно обеспечить «каскадируемость» стилевых описаний, или, другими словами, возможность объединения отдельных элементов форматирования путем вложенных описаний стиля, в ситуации, когда структура выходного документа заранее неизвестна и он создается в процессе самого разбора. Однако в XSL существует возможность задавать правила для стилей, при помощи которых можно изменять свойства стилевого оформления, что позволяет использовать довольно сложные приемы форматирования

В настоящий момент язык XSL находится на стадии разработки в W3C[3] и в будущем, видимо, станет частью стандарта XML. Это означает, что использование этого механизма является наиболее перспективным способом оформления XML-документов. В текущем рабочем варианте W3C, XSL рассматривается не только как язык разметки, определяющий стилевые таблицы — в него заложены средства, необходимые для выполнения действий по фильтрации информации, выводимой в окно клиента, поиска элементов, сложного поиска, основанного на зависимостях между элементами и т.д.

На сегодняшний день единственным броузером, поддерживающим некоторые из этих возможностей, является бэта-версия Internet Explorer 5.0, однако в самом ближайшем будущем, безусловно, XSL будет использоваться также широко, как сегодня стандартные тэги HTML

В этом разделе мы рассмотрим упрощенную объектную модель XSL-документа, используемую в текущей версии XSL-конвертора Microsoft msxsl, и поэтому информацию, изложенную далее, нельзя считать описанием стандарта языка. Полный рабочий вариант спецификации XSL в последней его редакции доступен на сервере.

Все примеры, приводимые далее, могут быть проверены при помощи XSL-конвертора, свободно доступного на странице Mcrosoft (www.microsoft.com/xml/xsl/)

С чего начать

Принцип обработки XML-документов стилевыми таблицами заключается в следующем: при разборе XSL-документа программа-анализатор обрабатывает инструкции этого языка и каждому элементу, найденному в XML-дереве ставит в соответствие набор тэгов, определяющих форматирование этого элемента. Другими словами, мы задаем шаблон форматирования для XML-элементов, причем сам этот шаблон может иметь структуру соответствующего фрагмента XML-документа. Инструкции XSL определяют точное месторасположение элемента XML в дереве, поэтому существует возможность применять различные стили оформления к одинаковым элементам, в зависимости от контекста их использования.

В общем случае, XSL позволяет автору задавать параметры отображения элемента XML, используя любые языки, предназначенные для форматирования — HTML, RTF и т.д. В этом разделе мы будем использовать в качестве такого языка HTML, т.к. документы, созданные при помощи этого языка разметки могут просматриваться любой подходящей программой просмотра Web-страниц
Структура XSL-таблиц

Рассмотрим основные структурные элементы XSL, используемые, в частности, в конверторе msxsl, для создания оформления XML-документов.

Правила XSL

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

Элементы XML, к которым будет применяться форматирование, обозначаются в XSL дескриптором ;. Для указания элемента с конкретным названием (название элемента определяется тэгами, его обозначающими), т.е. определения класса элемента, можно использовать атрибут type=» «

Вот пример простейшего XSL-документа, определяющего форматирование для фрагмента rose :

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

Инструкция указывает на то, что данное правило определяет элемент. Параметром type=»flower» задается название XML-элемента, для которого будет использоваться это правило. Программа-конвертор будет использовать HTML-тэги, помещенные внутри блока для форматирования XML-элемента, которому «предназначался» текущий блок. В том случае, если для какого-то элемента XML шаблон не определяется, в выходной документ будут добавлены тэги форматирования по умолчанию (например,

Процесс разбора XSL-правил является рекурсивным, т.е. если у элемента есть дочерние элементы, то программа будет искать определения этих элементов, расположенных «глубже» в дереве документа. Указанием на то, что необходимо повторить процесс разбора XML документа, теперь уже для дочерних элементов, является инструкция . Дойдя до нее, анализатор выберет из иерархического дерева XML-элементов нужную ветвь и найдет в XSL-шаблонах правила, определяющие форматирование этих нижележащих элементов. В том случае, если вместо мы укажем инструкцию ;, программа закончит движение по данной ветви и возвратится назад, в родительское правило. При этом текущее правило никакой информации в выходном HTML-документе изменять не будет, т.к. в данном случае означает, что содержимое элемента отсутствует.

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

Ниже приведен пример более сложного XSL-описания, некоторые фрагменты которого будут пояснены позже.

Корневое правило

Разбор любого XSL-документа всегда начинается с правила для корневого элемента, в котором определяется область всего разбираемого XML документа и поэтому тэги форматирования, помещенные сюда, будут действовать на весь документ в целом. Для обозначения корневого правила необходимо включить в него элемент ;. Например, для того, чтобы задать тэг для формируемой нами выходной HTML-страницы, мы можем использовать следующий фрагмент:

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

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

Отношения между элементами

Дочерние элементы в XML-документе всегда находятся внутри области, определяемой тэгами родительского по отношению к ним элемента. Для того, чтобы точно указать месторасположение обрабатываемого элемента в дереве XML, в XSL используется дополнительный тэг ;. При помощи него можно указать, какие элементы должны предшествовать текущему, а какие — следовать после него. Например, в следующем фрагменте определяется, что форматирование элемента будет зависеть от его месторасположения внутри XML-документа:

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

Приоритеты правил

В том случае, если внутри XSL-документа встречается несколько правил для одного и того же элемента, то msxsl будет использовать то из них, которое более точно определяет позицию данного элемента. Т.е. если XSL-документ содержит следующие правила:

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

В общем случае приоритет правил определяется следующим образом (в порядке убывания приоритета):

* правила, помеченные специальным тэгом
* правила с наибольшим значением атрибута id, если он определен
* правила с наибольшим значением атрибута class, если он определен
* правила, имеющие наибольшую вложенность, определяемую тэгом
* правила, использующие атрибут type совместно с
* правила, в которых отсутствует атрибут type в или
* правила с более высоким приоритетом, задаваемым атрибутом priority тэга
* правила с наибольшим значением квалификаторов ,

Использование атрибутов элементов

Фильтрация элементов

Одним из самых мощных средств XSL является возможность сортировки и выборки элементов, выделяемых из общего дерева элементов документа. Для этого используется элемент ;, который заменяет в правилах, определяя те элементы, которые следует обработать в процессе рекурсивного обхода. Например, в следующем примере будут обработаны только элементы :

Элемент сам по себе не определяет шаблон форматирования, он лишь управляет работой анализатора, обозначая, подобно , «нижележащие» элементы. В приведенном примере элемент должен быть расположен внутри элемента

Для того, чтобы в шаблоне выделить не только собственные дочерние элементы, но и дочерние элементы потомков, т.е. использовать несколько уровней вложенности, необходимо задать параметр from = «descendants». Если параметр имеет значение «children», что указывает на то, что выбор должен производится из списка собственных дочерних элементов, то атрибут from может опускаться, т.к. «children» является значением по умолчанию.
Правила стилей

В отличие от CSS, в XSL невозможно использование каскадных стилевых определений(т.е. нельзя использовать несколько правил для определения стиля одного того же элемента), т.к. такие ограничения вводит рекурсивный алгоритм работы программы — анализатора. Однако использование правил определения стиля(Style Rules) элемента позволяет каким-то образом скомпенсировать этот недостаток.

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

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

Также надо учитывать, что XSL-анализатор использует CSS для определения задаваемого правилами стиля в выходном HTML-документе, тем самым предоставляя нам возможность использования этого мощного средства при оформлении HTML-страниц После обработки приведенного в примере фрагмента в выходной документ будут помещены следующие элементы:

Еще один пример:

Стили в формате CSS:

Фрагмент XSL-документа, позволяющего использовать подобные стилевые определения:

Сценарии

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

Для написания сценариев XSL использует специальный скриптовый язык — ECMAScript. Однако в msxsl для этих целей можно применять Microsoft JavaScript — язык, который объединил в себе некоторые элементы стандартного JavaScript и ECMAScript.
Вычисление выражений

Наиболее простым примером использования сценариев в XSL -документе является вычисление значений параметров описываемых элементов. Для этого надо просто поставить знак равенства в качестве первого символа параметра, что заставит XSL-процессор вычислить значение выражения(синтаксис этого выражения должен отвечать требованиям JavaScript). Например, после разбора этого правила:

в выходном документе окажутся следующие инструкции:

Очень часто в правилах XSL необходимо использовать атрибуты описываемого в них элемента. Для этого мы должны воспользоваться методом getAttribute(), описанным в объектной модели XML (мы рассматриваем объектную модель XML-документов, предложенную Microsoft, список этих функций приведен в конце раздела). Т.к. каждому элементу XSL доступен указатель на соответствующий ему объект, сценарий может обращаться к внутренним функциям и свойствам этих элементов, при помощи которых и осуществляются необходимые действия.

Для того, чтобы использовать этот атрибут в выходном HTML-документе, необходимо определить следующее правило:

После обработки этого фрагмента в выходной документ будет помещен элемент:

Другим способом помещения в выходной HTML-документ информации, являющейся результатом выполнения каких-либо операций JavaScript – сценариев является использовнаие инструкции ;:

Метод childNumber в данном случае возвращает текущий номер дочернего элемента.
Определение функций и глобальных переменных

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

то в результате мы получим такой HTML-файл:

Все XML-технологии за 5 минут. XML, XML-NS, Fast Infoset, XPATH, XSLT, XSD, DTD, XML schema, SOAP, WSDL, MTOM, SAAJ, DOM, SAX, STAX, JAXB, dom4J, jdom, xerces, xalan, xsteam, JAX-WS, JAX-RT, SOA, ESB.

В текущем состоянии развелось множество buzz-words связанных с различными фреймворками и обработкой XML. Местами они ничего не значат. Местами суть концепции очень простая – но всё размазано по куче книжек и FAQ-ов. Описание не претендует на 100% верное – это лишь сжатая абстракция, которая сложилась у меня в голове после разработки интеграционного проекта на базе ESB\SOA\ XML \Web Services\BPEL в течение 2х лет. Если где-то сильну вру – поправьте

суть текстовый формат хранения структурированных данных,

  • структурированный, хорошо мапится на объектные модели
  • Читабелен в редакторе, умеет Unicode
  • Хорошая обратная совместимость, решает проблемы по части интеграции систем на различных ОС\платформах итп, является W3C стандартом.
  • Поддерживает ссылки между сущностями
  • Поддерживает типы данных и валидацию
  • Плохая производительность в сравнении с бинарными форматами
  • Большая избыточность данных
  • Нельзя хранить бинарные данные без перекодировки в BASE64 (+30% места на диске)

Well-formed XML

XML который удовлетворяет ограничениям

  • есть корневой элемент
  • все теги правильно вложены друг в друга и закрыты
  • шапка и заголовок файла валидные
  • все спец. символы правильно закодированы с использованием xml entites (всякие ‘&’ итп…) или использована секций CDATA
  • важно понимать что далеко не любые данные можно написать в xml без перекодирования во что-то вроде BASE64

т.е. Well formed = такой XML уже можно парсить парсером.

Valid XML

Формулировка означает что данные файла соответствуют некоторой структуре документа или правилам; правила задаются через cпециальный синтаксис – XML Schema или DTD. Val >

Это старый формат валидации XML, чем-то напоминает BNF-нотацию объявления синтаксиса. Выглядит примерно так

  • Не имеет нормальных встроенных типов данных
  • Не позволяет делать сложную валидацию
  • Можно втыкать прямо внутрь самого документа (не ссылаясь на внешний ресурс)

XML Schema / XSD

Более новый вариант валидации

  • объявляет простые и сложные типы данных, каждый тип может включать в себя другие
  • за счет этого позволяет более формально маппить объекты на xml и валидировать их
  • поддерживает примитивы и ограничения по значению
  • втыкать внутрь документа (embedded) нельзя

Relax NG

Альтернативный способ описания струкутры xml, считается более простым чем xml schema. Бывает в 2х видах – XML и compact. Пример compact синтаксиса

XML Namespaces

Пространства имен, фича которая появилась в xml позднее и поэтому местами продумана довольно плохо и костыльно. Основная идея в том что любой элемент можен объявить префикс namespace и проассоциировать этот префикс с URL. URL используется просто как уникальный идентификатор Это позволяет в теории не бояться что частям xml не хватит имен в названиях, это активно используется в Xpath и при валидации.

  • элементы из разных namespace’ов с одним названием воспринимаются как разные.
  • у каждого элемента есть default namespace который ему достается по наследству от родительского элемента, при этом уже ничего не нужно указывать – все автоматом получит нужный префикс

Xpath

Язык для выполнения запросов к XML DOM дереву. Достаточно гибкий, но движок запросов, как правило, не очень быстрый. Пример: выбрать все элементы BBB в дереве с атрибутом name равным bbb:

выбрать все элементы, являющиеся прямыми потомками /AAA/CCC/DDD

Язык для работы с XML шаблонами – позволяет выбирать данные, преобразовывать и мержить с другими xml. Чаще всего используется для отделения разметки веб страницы (xhtml) и данных (например таблиц выгруженных в xml) или для процессинга\конвертации xml-файлов. Побочным эффектом такой универсальности является мозго-взрывной синтаксис и совершенно отвратный и нечитаемый результат (имхо). Хотя при должном упорстве язычок поддается изучению, в совершенстве его знают только избранные и некоторые верстальщики. Пример

Илон Маск рекомендует:  Почему при изменении цвета букв statusbar'а ничего не происходит

Binary XML

Поскольку XML так плох по части производительности и избыточности хранения, регулярно предпринимаются попытки изобрести более нативное представление \ замену Fast Infoset — цель формата сокращение места и ускорение парсинга. Vtd xml – отличный формат обработки гигабайтный DOM- деревьев.

JAVA + XML

JDK хорошо поддерживает все что есть в XML мире. По дефолту включаются почти все парсеры – SAX, StaX, DOM. С версии 1.4+ JDK поддерживает динамическую регистрацию XML-парсеров. Такие парсеры вызываются внутри JDK при использовании его XMl API. Раньше нужно было добавлять парсер как доп. библиотеку, теперь с 1.4 по дефолту используется XERCES, который переписывают от версии к версии. Важно : из за смены JDK могут меняться\ломаться и сами парсеры – от этого переносимость приложения между разными JDK не такая легкая, как того бы хотелось java-разработчикам.

Типы парсеров

  • Event-driven парсинг
  • код обрабатывает события такие как: найден начальный тег, найден атрибут, найден конечный тег.
  • Быстрый по производительности, и простой по реализации
  • Тяжело написать сложную логику
  • формируется дерево объектов из элементов с атрибутами;
  • дерево хранится в памяти, его можно крутить и изменять как угодно, удобно работать со сложными структурами
  • удобно вычислять XPATH функции
  • в целях оптимизации некоторые узлы могут не разбираться, пока к ним не обратятся
  • Среднее между DOM и SAX, парсинг управляется кодом, т.е. ему говорят в какую сторону парсить документ и что вытаскивать.
  • Хорошая производительность.
  • Код выходит проще, чем для SAX модели.

Вот такая табличка хорошо сравнивает их по фичам.

Feature StAX SAX DOM TrAX
API Type Pull, streaming Push, streaming In memory tree XSLT Rule
Ease of Use High Medium High Medium
XPath Capability No No Yes Yes
CPU and Memory Efficiency Good Good Varies Varies
Forward Only Yes Yes No No
Read XML Yes Yes Yes Yes
Write XML Yes No Yes Yes
Create, Read, Update, Delete No No Yes No

XML фреймворки и парсеры

Dom4j – лучшее что есть для DOM-парсинга, используется в Intellij IDEA. Сейчас уже дорос до поддержки DOM, SAX , JAXP (встраивается в JDK как парсер по умолчанию), XPATH, XSLT.

Jdom – чуть устаревший предшественник dom4j, хорошая библиотека т.к. всё есть.

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

vtd-xml – супер быстрый движок для обработки гигабайтных DOM-деревьев, использует собственный бинарный формат для хранения дерева объектов, есть нативные реализации. Один из самых интересных фреймворков из того что я видел.

xerces-j – парсер по умолчанию в JDK1.4+

xalan – популярный XSLT движок, используется в куче разных фреймворков.

Beans-to-XML mapping

JAXB – мощная система, входит в JAXP ( в JDK);

  • позволяет задать аннотации на объекте и смаппить его на xml
  • по аннотациям может генерится xsd
  • позволяет грузить из\сохранять в xml инстансы такого объекта
  • используется в стеке вебсервисов JavaEE, поэтому производительность должна быть на уровне
  • богатый функционал и непростое API, поэтому требует время на освоение

Xstream – легкий быстрый и удобный фреймворк для маппинга xml в java-бины

  • практически нулевая сложность настройки
  • чистый xml на выходе, без спец. полей итп мусора
  • must-have для парсинга конфигурационных xml файлов.
  • все что нельзя сделать по умолчанию конфигурируется чз аннотации.
  • умеет сериализовать графы

WEB SERVICES

SOAP & WSDL

SOAP – протокол для пересылки сообщений.

  • Определяет 2 основных поля – header и body.
  • Обычно используется в стеке вебсервисов поверх HTTP.

WSDL –язык описания веб-сервисов WSDL определяет

  • какие типы данных у нас есть (комплексные типы, на базе xsd-типов),
  • какие сообщения (состоящие из полей нужных типов) могут передаваться\приниматься,
  • какие есть сервисы,
  • какие есть в них порты (endpoints),
  • какие методы есть у каждого из портов.
  • soap 1.1 -> wsdl 1.1 (текущие версии связки – используется повсеместно)
  • soap 1.2 -> wsdl 2.0 (используется редко, плохо поддерживается фреймворками)
  • Soap 1.1 vs Soap 1.2 (раз, два, три) , wsdl 1.1 vs wsdl 2.0

Есть много разных способов отображения объектов на SOAP сообщения (SOAP-binding). Различают вот такие варианты:

  1. RPC/encoded
  2. RPC/literal
  3. Document/encoded
  4. Document/literal
  5. Document/literal wrapped

Биндинг по сути определяет что попадет в xml-сообщение: имена параметров? Типы параметров? Имя вызванной процедуры? Итп. Про биндинг детально можно прочитать тут

Передача бинарных данных

SAAJ – один из стандартов который так и не прижился. MTOM — активно используется, есть во всех популярных JAVA-фреймворках; идея аналогична добавлению вложений в email: после soap сообщения добавляется специальная секция в которую пишутся raw бинарные данные. Прим:

  • mtom не является спекой, ноды м-ду собой должны знать что оба поддерживают mtom и одинаково это понимают.
  • Некоторые реализации могут делать все так как будто mtom корректно поддерживается, но в реальности в конец добавлять xop:include с Base64 данными (+33% размер аттача)…

Совместимость

Разные SOAP версии\биндинги не совместимы, например эти связки НЕ будут работать по дефолту:

  • Axis + weblogic
  • Jaxws + ms sharepoint

Разные производители (Microsoft, Sun) в своих веб-сервисах полагаются на различные дефолты.. поэтому иногда бывает непросто дернуть даже обычный веб-сервис.

JAVA + WEB SERVICES

JAXWS/METRO

Стек веб-сервисов в JavaEE сделан на базе проекта METRO, туда входят JAXB, JAXWS, MTOM, STAX итп.. сама реализация хорошая, быстрая и стабильная. Простой пример: Скачиваем JAXWS RI, добавляем немного аннотаций , получаем веб-сервис который можно запускать прямо из main метода.

Запускать можно вот таким кодом

Apache AXIS

Популярный и хороший фреймвок, текущая весия 2+, кое-где еще распространен Axis1.x но он не так удобен в использовании.. http://axis.apache.org/axis2/java/core/

Apache CXF

Фреймворк рабочий и полноценный, по попользовав его остался крайне недоволен кривой поддержкой некоторых вещей и глючностью. http://cxf.apache.org/

Spring WS

Кошерная реализация от SpringSource. Не использовал, но все хвалят. http://static.springsource.org/spring-ws/sites/2.0/

SOA / ESB / BPM

Все слышали слова SOA , BPM , ESB .. но на самом деле мало кто из заказчиков\PM-ов\руководителей ИТ на самом деле понимает что это всё такое..

Sales рисуют абстрактные картинки.. на которых все хорошо, гибко и чудесно. Но в головах — туман.. и желание потратить немного денег на всё это.. и с этим приходят чтобы “интегрироваться”. Вот хорошая статья как введение в наши проблемы — SOA и BPM

SOA — это очень простая концепция

  • каждая служба это сервис..
  • “давайте сделаем” общий orchestration который свяжет все эти службы между собой в некий сервис..
  • который будет предоставляться конечным пользователям с некоторым качеством (SLA?).
  • всё

Что SOA не делает:

  • SOA это не только +1 к business value: еще есть толстая техническая составляющая которая даст отдачу только чз большой промежуток времени
  • SOA не требует BPM
  • SOA не обязательно требует несколько хостов
  • SOA не обязывает пользоваться messaging или обработкой событий
  • SOA никак не относится к веб-сервисам, REST, XML, RMI итп. это всего лишь протоколы конкретных реализаций.

Почему SOA это трудно

  • тяжело выделить хорошую, ре-юзабельную службу в отдельный сервис и потом везде использовать
  • повторное использование очень тяжело предусмотреть, особенно если бизнес процессами рулят не-технические люди
  • маркетинг – сам термин SOA завален дурной рекламой от ведущих вендоров.. до такой степени что разобраться в терминах становится очень сложно. Каждый кому не лень переделал свой унылый и кроивой интеграционыый тул (или MOM-сервер) как SOA compatible и продает его..
  • мало внедрений
  • это единая архитектура интеграционной шины сделанная в соотв-ии с SOA подходом
  • чаще всего используют веб-сервисы для транспорта
  • чаще всего на шину втыкают движок для исполнения long-running бизнес процессов
  • для общения с внешним миром для каждой внешней системы пишутся адаптеры
  • самая важная функциональность это messaging (отправка сообщений через некоторую общую среду) и routing (управление доставкой сообщений подписанным компонентам) , поверх всего этого у самых крупных вендоров навернуто еще 10 слоев абстракций , но суть от этого не меняется.

Примеры ESB продуктов:

  • MS BizTalk
  • Oracle ESB
  • IBM WebSphere ESB
  • Open ESB
  • Mule
  • Tibco
  • Apache ServiceMix

ESB — Задачка из жизни

Недавно моим мнением поинтересовались вот в таком кейсе:
Задача: у кастомера есть более 40 приложений (и/или интерфейсов к другим системам) для автоматизации своего бизнеса. Приложения вида: вебпортал / десктоп / мобильные / SAP и т.п., написанные на разных языках / платформах. Примерно 10тыс. пользователей этих приложений в стационарных офисах и 1,5тыс. пользователй в мобильных офисах. Постепенно приложения переписываются под технологию .NET (C# / WCF / EF / Silverlight / ASP.NET / MSSQL / etc.). В качестве платформы для обмена данными между приложениями кастомер предлагает (но не настаивает) на BizTalk-е.

Нужно оценить применимость BizTalk и конкурирующих продуктов с точки зрения:
легкости интеграции с разными приложениями (написанных на Silverlight / ASP.NET / mobile apps)
скорости обучения девелоперов
стоимости деплоймента в энтерпрайз виде
безопасности
надежности
скорости работы
устойчивости к нагрузкам и т.д.

Напишите, если у Вас был опыт работы с BizTalk или его аналогами. В чем принципиальная выгода от использования BizTalk, по сравнению, например, с «самописной» системой обмена данными между приложениями?
Имхо, есть как минимум 3 «самописные» замены BizTalk:

1) написать свой сервер приложений. Т.е. это будет постоянно работающие в режиме 24/7 приложение на выделенном сервере, которое будет уведомлять об изменениях все подписанные на это клиентские приложения.
2) т.к. каждое приложение результаты своей работы складывает в БД (как правило, в MSSQL) или в виде файлов на ftp сервер, то можно чтобы каждое приложение перодически (раз в несколько минут) опрашивало через вебсервис БД / ftp сервер на предмент наличия важных для него данных.
3) на уровне БД MSSQL в триггере при появлении новых данных в таблице, послать сообщение через .NET CLR stored procedure (WCF + MSMQ?). Для случая с файлами на ftp сервере — написать приложение которое будет периодически проверять каталог и рассылать уведомления при появлении новых файлов (WCF + MSMQ?).

Моё имхо: Плюсы применения BizTalk

  • сколько лет это проживет после того как этот проект завершится, и насколько тяжело будет разбираться потомкам в том что останется
  • вроде как есть графический редактор для orchestrations и готовая модель вида — пишем адаптер для каждой системы в biztalk, внутри biztalk’a ходят наши же сообщения
  • это легче продать, компании верят в коробочные решения, даже если они утыканы костылями как ёлка опилками. плюс есть туманная вера что они смогут найти другого вендора на поддержку (не вас).
  • если biztalk медленно работает или чего-то не умеет — проект обрастет костылями, будет медленно работать, будет тяжел в деплойменте итп.
  • не сможете писать юнит тесты, и вообще какие-либо тесты.. это большой «-»
  • если столкнетесь с багами которые MS откажется исправлять — будете плакать но пользоваться.
  • если будете пользоваться рисовалкой «процессов» — рано или поздно модель станет очень сложна в поддержке, т.е. только опытные ассы рискнут ее править, плюс уткнетесь в ограничения самого тула; (вообще это происходит с любым визуальным инструментом при разработке чего-либо сложного).
  • заюзать любой messaging framework с которым вы а) знакомы б) доверяете его производительности и надежности г) уверены что он проживет 10-20лет (или вы сможете его поддерживать сами)
  • слать через него xml-сообщения или бинарные с оговоренным форматом (или количество и вид этих форматов должен быть как-то декларативно описан)
  • стараться смотреть в сторону open source, не читать буклеты Oracle & Microsoft
  • в итоге вы получите 20% функционала biztalk который покроет 80% хотелок, остальное можно дописать по ходу дела..

Утилиты для xml

Intellij IDEA , Intellij WebStorm , Eclipse – тут всё ясно, прозрачная валидация и автоподстановка имен элементов, редактирование XML.

XMLPAD – править, смотреть, считать XPATH, валидировать итп

Xml Notepad – смотреть 1Gb+ файлы

Notepad++ — есть достаточно хороший plugin xml tools для работы с XML

SOAP UI – для работы с веб-сервисами: вызов, генерация тестовых сервисов по wsdl, отладка, авто-тесты.

TcpTrace – прозрачный port редиректор\сниффер для просмотра TCP-трафика

Altova, Oxygen – крутые и навороченные XML IDE, в них можно делать практически всё, но необходимость в их использовании довольно сомнительна

XML и XSLT в примерах для начинающих (стр. 1 )

Из за большого объема этот материал размещен на нескольких страницах:
1 2 3 4

XML и XSLT в примерах для начинающих

8. XML и XSLT в примерах для начинающих

Для всех примеров ниже использован стандарт языка XSL. Широко применяется также более современная модификация этого стандарта — язык XSLT, детальнее про который можно прочитать в \xml\XSLTutorial или MSDN.

Рассмотрим простой пример XML-файла (ex01.xml). Этот и остальные примеры можно найти в папке \xml\ XSLTForBeginers на диске.

Если мы откроем этот файл в браузере Internet Explorer, то увидим тот же самый текст, который приведен выше, вместе со всеми тегами и служебной информацией. Но нам не нужны теги и служебная информация! Мы хотим видеть только ту информацию, которая относится к делу, а при помощи тегов — управлять внешним видом этой информации. Эта задача решается легко и просто: необходимо к XML-файлу добавить шаблон преобразования — XSL-файл.

Перепишем наш XML-файл в следующем виде (ex01-1.xml).

И создадим XSL-файл ex01-1.xsl. Текст файла приведен ниже.

Если мы теперь откроем файл ex01-1.xsl в браузере Internet Explorer, то мы увидим, что наша задача решена, — на экране осталась только необходимая нам информация, все теги исчезли. Результат, который вы получите на экране браузера, приведен ниже.

«Заметки об XSL»

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

Перепишем XML-файл. Информационную часть изменять не будем, а шаблон укажем другой ex01-2.xml.

Создадим XSL-файл ex01-2.xsl. Текст файла приведен ниже.

Если мы теперь откроем файл ex01-2.xsl в браузере Internet Explorer, то результат будет другим.

«Заметки об XSL»

Отметим теперь момент, который является ключевым для разработчиков баз данных. Информация в XML-странице появляется, как правило, в результате запроса к базе данных. Запрос к базе данных в многопользовательской среде — это весьма дорогостоящая операция. Предположим теперь, что у нас нет XML и мы формируем стандартные статические HTML-страницы. В этом случае для решения задачи простого преобразования внешнего представления информации, например, для изменения сортировки, у нас есть два способа решения проблемы: выполнить запрос и сохранить результаты в каком-либо временном буфере на сервере или каждый раз при изменении внешнего представления выполнять новый запрос и формировать HTML-страницу заново.

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

XML и XSL — это исчерпывающее решение описанной выше проблемы. Фактически XML-страница — это и есть временный буфер для результатов запросов. Только вместо нестандартного и трудоемкого программирования мы теперь используем стандартный механизм XSL.


Есть и еще одно соображение, которое может быть существенным для разработчиков баз данных. Большинство современных СУБД могут форматировать результаты запроса к базе данных в виде XML-файла. То есть при построении интерфейса пользователя в рамках технологии XML и XSL мы добиваемся определенной независимости от поставщика СУБД. В части организации вывода — практически полной независимости. А эта часть весьма велика в большинстве прикладных систем, ориентированных на работу с базами данных. Конечно, помимо вывода есть еще ввод и серверная обработка бизнес-логики, но здесь вам придется искать какие-то иные решения.

Первые шаги

Разберем теперь более подробно первый пример. Напомним его текст.

Первая строка информирует браузер о том, что файл имеет формат XML. Атрибут version является обязательным. Атрибут encoding не является обязательным, но если у вас в тексте есть русские буквы, то необходимо вставить этот атрибут, в противном случае XML-файл просто не будет обрабатываться, — вы получите сообщение об ошибке.

Следующие строки — это тело XML-файла. Оно состоит из элементов, которые в совокупности образуют древовидную структуру. Элементы идентифицируются тегами и могут быть вложены друг в друга.

Элементы могут иметь атрибуты, значения которых тоже могут обрабатываться в соответствии с шаблоном.

На верхнем уровне XML-файла всегда находится один элемент. То есть файл вида

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

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

Перейдем теперь к шаблону преобразования — к XSL-файлу. Задача XSL-файла — преобразовать дерево XML-файла в другое дерево, которое, например, будет соответствовать формату HTML и может быть изображено на экране браузера с учетом форматирования, выбора шрифтов и т. п.

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

Рассмотрим теперь текст XSL-файла

Первая строка файла содержит тег элемента xsl:stylesheet. Атрибуты элемента — номер версии и ссылка на пространство имен. Эти атрибуты элемента xsl:stylesheet являются обязательными. В нашем случае пространство имен — это все имена элементов и их атрибутов, которые могут использоваться в XSL-файле. Для XSL-файлов ссылка на пространство имен является стандартной.

Заметим, что XSL-файл является одной из разновидностей XML-файлов. Он не содержит пользовательских данных, но формат его тот же самый. Файл содержит элемент верхнего уровня xsl:stylesheet, а далее идет дерево правил преобразования.

В настоящем документе мы не будем подробно пояснять, что означает каждый элемент XSL-файла. Мы будем приводить различные примеры и показывать результат в каждом примере, что даст возможность самостоятельно сопоставить различные элементы XSL-файла и инициируемые этими элементами преобразования исходного XML-файла с пользовательской информацией. Заметьте также, что значение атрибута select и подобных со смыслом «выбрать» записывается на специальном языке XPath, о котором можно прочитать в кратце на диске \xml\XPathTutorial, а подробнее в MSDN.

В дальнейшем тексты XML — и XSL-файлов мы будем приводить в черно-белом варианте. Вы всегда сможете открыть реальный файл и посмотреть все в цвете. При необходимости закомментируйте ссылку на XSL-файл. Синтаксис комментария следующий — . В текст комментария нельзя вставлять символы —.

В первом примере мы посмотрели, как с помощью элемента xsl:value-of можно вывести в HTML-формате содержание элемента (текст, заключенный между тегами). Теперь мы посмотрим, как при помощи того же самого элемента можно вывести значение атрибута элемента.

XML TO XML using XSL

I have trouble trying to convert this xml format

Into this xml format

I have tried this with disasterus results. It just erases everything and gives me the raw data!

These xmls are just an example of the export(first) of a long output from a product data-table , and the second only an example of one product, but i wish this format could be applied to all the products of the first , no matter how many.

Is the XSL the correct way? Is this even possible or there is a better one? This is in a C# program Btw.

Илон Маск рекомендует:  Один обработчик на все клики

Глава 1

Добро пожаловать в мир языка преобразований расширенной таблицы стилей, XSLT (Extensible Stylesheet Language Transformations). Эта книга послужит вам путеводителем в огромном мире XSLT, который каждую минуту расширяется непредсказуемым образом. Мы хотим, чтобы этот мир стал и вашим миром. Нам нужно охватить весьма большой материал, поскольку в наши дни XSLT используется в очень интересных местах и очень интересными способами. В этой книге вы увидите, как это все работает.

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

С содержимым документов XML можно работать, написав собственную программу, реализующую интерфейс с приложениями разборщика (parser) XML, однако при этом приходится писать код программы самостоятельно. При помощи XSLT вы можете выполнять задачи подобного же рода, не прибегая к программированию. Вместо того чтобы писать код обработки содержимого документов XML на Java, Visual Basic или С++, можно просто указать при помощи XSLT, что вы хотите сделать, и процессор XSLT сделает все остальное. Именно для этих целей и предназначен XSLT, и в мире XML он выходит на ключевые позиции.

XSL = XSLT + XSL-FO

Сам XSLT в действительности является частью более крупной спецификации — расширенного языка таблиц стилей, Extensible Stylesheet Language, или XSL. XSL предназначен для задания точного, до миллиметра, формата документов.

Форматирующая часть XSL, представляющая гораздо более крупную спецификацию, чем XSLT, основана на специальных форматирующих объектах (formatting objects) — эта часть XSL часто называется XSL-FO (или XSL:FO, или XSLFO). XSL-FO — сложная тема, поскольку задание стилей документов при помощи форматирующих объектов может оказаться весьма запутанным процессом. Фактически XSLT изначально был добавлен в XSL для того, чтобы проще осуществлять преобразование документов XML в документы, основанные на форматирующих объектах XSL-FO.

Эта книга посвящена XSLT, но рассматривается также и введение в XSL-FO, в том числе способ использования XSLT для преобразования документов в форму XSL-FO; в конце концов, XSLT впервые был представлен для упрощения работы с XSL-FO. В начале данной главы будет приведен обзор как XSLT, так и XSL-FO.

Краткая историческая справка

XSL был создан консорциумом World Wide Web Consortium (W3C, www.w3.org) — объединением групп, первоначально возглавлявшимся Тимом Бернерс-Ли (Tim Berners-Lee). W3C — это комитет, выпускающий спецификации, — такие, как спецификация для XSL, используемая в данной книге. Именно спецификации делают XML и XSL тем, чем они являются.

Вы можете прочитать об истории работы комитета W3C с языками стилей по адресу www.w3.org/Style/History. Интересно посмотреть, какая объемная работа была проделана и как много языков стилей сменилось за это время.

W3C первоначально, в 1980-х, разработал «дедушку» XML, SGML (Standard Generalized Markup Language, стандартный обобщенный язык разметки), однако он был слишком сложен для того, чтобы завоевать широкую популярность, и в действительности XML (как и HTML) представляет собой упрощенную версию SGML. W3C также создал для работы совместно с SGML язык стилей DSSSL (Document Style Semantics and Specification Language, язык семантики стиля и спецификации документа) — и так же, как XML был произведен от SGML, XSL основан на исходном DSSSL. Как утверждает W3C: «Модель, используемая XSL для отображения документов на экране, базируется на многих годах работы над сложным языком стилей по стандарту ISO, который называется Document Style Semantics and Specification Language (DSSSL)».

Однако исходная часть XSL, то есть XSL-FO, все равно оказалась не настолько простой, чтобы найти широкое распространение, поэтому XSLT был представлен как средство упрощения преобразования документов XML в форму XSL-FO. Как оказалось, именно XSLT был взят на вооружение, поскольку он представляет собой законченный язык преобразований, позволяющий работать с содержимым документов XML без написания программного кода, преобразовывать эти документы в другие документы XML, формат HTML или другие основанные на текстах форматы. Большой успех XSLT удивил даже W3C.

Преобразования XSLT-XSL

XSLT позволяет работать непосредственно с содержимым документов XML. Например, у вас может быть огромный документ XML, содержащий всю бейсбольную статистику за последний сезон, однако вас может интересовать только статистика для питчеров. Чтобы извлечь только эти данные, можно написать программу на Java, Visual Basic или С++, которая будет работать с разборщиками XML. Разборщики представляют собой специальные программные пакеты, читающие документы XML и передающие все данные документа последовательно в ваш код. Затем можно создать новый документ XML, pitchers.xml, содержащий только данные о питчерах.

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

Помимо преобразования одного документа XML в другой документ XML, можно также преобразовывать документы XML в документы разных типов — таких, как HTML, документы форматированного текста (RTF), документы, использующие XSL-FO и другие. Можно также преобразовать документы XML в иные основанные на XML языки — такие, как MathML, MusicML, VML, XHTML и другие — все это можно осуществить, не прибегая к программированию.

Во многих случаях язык XSLT может работать аналогично языку баз данных, такому как SQL (Structured Query Language, язык структурированных запросов, — известный язык доступа к базам данных), поскольку он позволяет извлекать требуемые данные из документов XML во многом похоже на то, как инструкция SQL извлекает данные из базы данных. Иногда даже говорят о XSLT как о SQL в Web, и если вы знакомы с SQL, это даст вам некоторое представление о безграничных возможностях XSLT. Например, при помощи таблицы стилей XSLT можно извлечь подмножество данных из документа XML, создать оглавление для большого документа, найти все элементы, удовлетворяющие определенному условию (например, поставщиков с определенным индексом) и т.д. И все это — за один шаг!

XSL-FO: форматирующие объекты XSL

Другая часть XSL — это XSL-FO, форматирующая часть языка XSL, с которой мы также познакомимся в этой книге. При помощи XSL-FO можно определить способ представления данных в документах XML, вплоть до размера полей, шрифтов, выравнивания, размера заголовка и подзаголовка, а также ширины страницы. При форматировании документа XML приходится думать о множестве вещей, и, соответственно, XSL-FO значительно объемистее, чем XSLT.

С другой стороны, из-за излишней сложности XSL-FO не очень популярен, и его нельзя сравнивать с XSLT в этом отношении. Существует не так много программ, поддерживающих XSL-FO, и ни одна из них не реализует достаточно полное приближение к стандарту. Так же как самый распространенный способ применения XSLT — это преобразование XML в HTML, самый распространенный способ применения XSL-FO — преобразование XML в текст в формате PDF (Portable Data Format, переносимый формат данных), используемый в Adobe Acrobat. Пример такого преобразования приведен в конце этой главы, а также в главе 11.

Спецификации W3C

W3C выпускает спецификации как для XML, так и для XSL, и именно с ними мы будем работать на протяжении всей книги. Спецификации W3C не называются стандартами, поскольку, по международным соглашениям, стандарты могут создаваться только уполномоченными государством комитетами. Вместо этого W3C начинает с выпуска требований (requirements) для новой спецификации. Требования представляют собой список целей и обзоров спецификации, но сама спецификация на этот момент еще не написана. Далее W3C выпускает спецификации: сначала в виде рабочих проектов (working drafts), которые могут комментировать все заинтересованные лица, затем в виде рекомендаций-кандидатов (candidate recommendations), которые еще могут быть изменены; и, наконец, в виде окончательных рекомендаций (recommendations), которые уже нельзя изменять.

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

• полная рекомендация-кандидат XSL www.w3.org/TR/xsl/. Это большой документ, определяющий все аспекты XSL;

• рекомендация XSL Transformations 1.0 по адресу www.w3.org/TR/xslt. Предназначение XSLT состоит в преобразовании содержимого документов XML в другие документы, и именно поэтому XSL стал таким популярным;

• рабочий проект XSLT 1.1 по адресу www.w3.org/TR/xslt11. Это рабочий проект XSLT 1.1, который не будет далее разрабатываться до рекомендации — W3C планирует добавить всю функциональность XSLT 1.1 в XSLT 2.0;

• требования XSLT 2.0 по адресу www.w3.org/TR/xslt20req. W3C выпустил группу целей для XSLT 2.0, включая дополнительную поддержку схем XML;

• спецификация XPath 1.0 по адресу www.w3.org/TR/xpath. XPath используется для нахождения и указания на определенные разделы и элементы в документах XML так, чтобы можно было с ними работать;

• требования XPath 2.0 по адресу www.w3.org/TR/xpath20req. XPath в данный момент обновляется — добавляется дополнительная поддержка XSLT 2.0.

Версии XSLT

Спецификации XSLT разрабатывались значительно активнее, чем спецификации для всего XSL. Рекомендация XSLT 1.0 была окончательно принята 16 ноября 1999 г., и эта версия является сегодня основной версией XSLT.

Затем появился рабочий проект XSLT 1.1 и, хотя первоначально он рассматривался в качестве пролога новой рекомендации, ряд сотрудников W3C начал работать над XSLT 2.0 — и через некоторое время W3C решил прекратить работу над рекомендацией XSLT 1.1. Это означает, что рабочий проект XSLT 1.1 не будет развиваться далее — он навсегда останется в виде рабочего проекта и никогда не станет рекомендацией. Иными словами, не будет выпущено официальной версии 1.1 для XSLT.

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

Ниже перечислены изменения в XSLT 1.0, сделанные в рабочем проекте XSLT 1.1; заметьте, что этот список приведен здесь только в качестве справочного материала, так как большая часть материала вряд ли пока что-нибудь для вас значит:

• исключен поддерживаемый в XSLT 1.0 тип данных фрагмента результирующего дерева;

• метод вывода больше не может произвольно добавлять узлы пространства имен, поскольку процесс установки пространства имен применяется автоматически;

• была добавлена поддержка для XML Base;

• теперь поддерживаются несколько выходных документов при помощи элемента

• функции расширения теперь можно определять при помощи функции

• функции расширения теперь могут возвращать внешние объекты, не соответствующие никаким типам данных XPath.

В этой книге рассматривается рекомендация XSLT 1.0. а также рабочий проект XSLT 1.1. В развитие данной темы W3C и выпустил требования для XSLT 2.0, которые также рассматриваются в книге под именем XSLT 2.0. В следующем списке приведен обзор целей XSLT 2.0:

• добавить дополнительную поддержку для работы с содержимым схемы XML при помощи XSLT;

• упростить работу со строками;

• упростить работу с XSLT;

• улучшить поддержку различных языков;

• сохранить обратную совместимость с XSLT 1.0;

• поддерживать повышенную эффективность процессора.

Хотя XSLT 2.0 еще некоторое время не будет выпущен в окончательном варианте, я рассмотрю все, что о нем известно, при обсуждении имеющих к нему отношение тем. Например, разработанный W3C последователь HTML — это основанный на XML язык XHTML. В XSLT 1.0 и в рабочем проекте XSLT 1.1 нет прямой поддержки преобразований из XML в XHTML, поэтому нам придется создать это преобразование с нуля. Однако такая поддержка входит в состав XSLT 2.0, и я отмечу этот факт при обсуждении XHTML.

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

Документы XML

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

Введение в XSLT

XSLT представляет собой способ для XML-документов в другие XML или документы язык документа XHTML.

XPath это язык для навигации в XML-документах.

Вы должны иметь базовые знания

Перед тем, как продолжать учиться, мы должны иметь общее представление о следующем:

  • HTML / XHTML
  • XML / пространство имен XML
  • XPath

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

Что такое XSLT?

  • преобразование XSLT XSL средство (XSL Transformations)
  • XSLT является наиболее важной частью XSL
  • XSLT может преобразовать документ XML в другой документ XML
  • XSLT использует XPath для навигации в XML-документах
  • XSLT является стандартом W3C

XSLT = преобразование XSL

XSLT является наиболее важной частью XSL.

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

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

Одно общее утверждение описывает процесспреобразования, XSLT к исходному XMLдерева в результирующее дерево как XML.

XSLT использует XPath

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

Если вы хотите сначала узнать XPath, пожалуйста , посетите наш XPath учебник .

Как это работает?

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

XSLT является стандартом W3C

XSLT в 16 ноября 1999 года был создан в качестве стандартов W3C.

Для получения более подробной информации о W3C деятельности XSLT, пожалуйста , посетите наш W3C учебник .

Создание отчетов на основе xsl-трансформаций (xslt)

Опубликовано:
25 января 2020 в 07:59

XSLT (eXtensible Stylesheet Language Transformations) — язык преобразований xml-документов.

Введение

Задача генерирования отчетности в системе DIRECTUM является одной из наиболее востребованных.

В этой статье описан возможно не самый широко распространенный способ формирования html-отчетов на основе xslt-преобразований. Но несомненно заслуживающий внимания, как один из наиболее удобных и наглядных (если сравнить например с rtf-отчетом).

Если очень коротко, то xslt-преобразование заключается в трансформации xml-схемы с данными в отчет на основе предварительно подготовленного шаблона.

Для примера отчета описанного в статье будет выводится список контрагентов с их наименованием, ИНН и адресом.

Чтобы сформировать отчет понадобятся две составляющие:

— xml-данные для отчета

Данные в формате xml

Данные в формате xml можно получить прямым sql-запросом:

Описанный выше запрос вернет данные в таком формате:

Данные нужно обернуть в тег и сохранить в файл, добавив заголовок:

Вторая строка заголовка xml-файла данных важна, в ней указано, что в файле C:\Temp\template.xsl хранится шаблон отчета в который необходимо передать данные.

В итоге получится такой xml-файл:

Если открыть полученный xml-файл, браузер будет использовать указанный в заголовке шаблон и подставит данные в него.

xsl-шаблон

Далее необходимо создать шаблон, имя файла которого указано в заголовке xml-файла. xsl-шаблон отчета представляет собой обыкновенную html-страницу с особым заголовком:

В тэге указаны версия и ссылка пространства имен xsl-преобразования. В остальном шаблон — это обыкновенная html-страница.

Теперь нужно сотворить немного магии и указать какие именно данные из xml и в каком виде вставить в шаблон отчета.

Для работы с данными в xsl-шаблоне используются специальные теги.

Цикл for-each и правила выбора

Чтобы перебрать все узлы из xml-файла данных нужно использовать конструкцию:

Она позволит перебрать все дерево данных. Для того, чтобы выбрать только определенные данные из дерева используется правило выбора select=»orgs/org». Правила описаны на языке запросов XPath. В текущем примере будет последовательно отобрана каждый узел из .

Сортировка

Если необходимо, чтобы записи отображались не в порядке следования в xml-файле, а сортировались, то нужно указать это в шаблоне:

Теперь записи будут перебираться предварительно отсортированными по наименованию.

Отображение значения

Но просто перебрать не достаточно, нужно вывести в отчет нужные данные, для этого существует конструкция:

Конструкция отобразит значение тэга (наименование контрагента).

Гиперссылки

Чтобы сделать из наименования контрагента ссылку, по которой можно будет открыть запись справочника, нужно немного модифицировать код:

Сase-оператор и фильтрация

Пусть ИНН контрагента отображается в отчете не просто так. Если ИНН в карточке отсутствует, то будет выводится сообщение об отсутствии ИНН. Для этого необходимо использовать конструкцию:

В конструкции choose с помощью фильтра test проводится проверка содержимого тэга (ИНН) на пустое значение ( ). Если содержимое не пусто, то выводиться значение. В других случаях выводится сообщение «ИНН не указан».

Еще один фильтр

С помощью фильтра возможно реализовать еще одну «рюшечку», которая будет помечать контрагентов с ИНН начинающихся например с кода региона «18». Выглядеть это будет так:

Конструкция для всех записей ИНН которых начинается с «18» дополнительно выведет значок ♥ .

В конечном итоге получится такой код шаблона:

Результат

А если открыть xml-файл в браузере, то получится такой отчет:

Вывод

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

А если к отчету подключить такой мощный инструмент как javascript, то описанный отчет легко можно сделать интерактивным. Например добавить элемент, позволяющий проводить какую-либо фильтрацию. Или отображать графики по данным отчета.

Какие есть плюсы при реализации отчетов описанным способом:

— Требуется разработка относительно небольшого количества прикладных вычислений;

— Разработка шаблона наглядна и также относительно нетрудоёмка.

Всё описанное в статье легко интегрируется в аналитический отчет, ссылка на который приведена ниже.
Пример xsl отчета

Собственно отображение задач в Директум выполняется как раз таким образом.

Опять же трансформацию можно производить программно:

Не увидел в статье ответа на вопрос зачем нам выгружать данные сначала в xml-файл, а потом еще и писать xslt (который еще и изучить надо), если можно сразу выгрузить в формате html (по сути это тот же xml).
Аргументируйте, пожалуйста, и приведите примеры, применимые к отчетам Directum.
Обычно разделение данных и представления делают когда надо одни и те же данные надо по-разному отображать (отображать в нескольких представлениях динамически формируемые данные или если данные хранятся где-то и отображение может со временем меняться).
С отображением схем задач понятно почему надо использовать xslt — у нас данные уже есть, их надо только отобразить. Я не встречал никогда чтобы данные еще где-то хранились в xml и их надо было только отобразить.
К недостаткам представленного подхода еще можно отнести то, что xsl-файл еще надо где-то размещать, чтобы отчет можно было переслать по почте, например.

Илон Маск рекомендует:  Подсети, маски

Александр, статья писалась для разработчиков, которые еще не слышали (или слышали, но краем уха) про xslt. И призвана подтолкнуть их к изучению этой темы.
По поводу того «зачем нам выгружать данные сначала в xml-файл» — можно и не выгружать, а реализовать по-другому, как например выше в комментарии описал Роман.
«а потом еще и писать xslt (который еще и изучить надо)» — именно для этого статья и писалась, чтобы начать изучать xslt.
Про «сразу выгрузить в формате html» — чтобы это сделать, все равно нужно вычисления писать, которые данные «обернут» в тэги html-разметки. И такой путь не соответсвует парадигме MVC. Если отчетик небольшой и известно, что никаких изменений в нем не предвидится, то, возможно, отступить от этой парадигмы не страшно.
Но если предполагается, что периодически необходимо вносить доработки в отчет, то поддержка такого отчета станет трудоемкой задачей.
К примеру сейчас сущетсвует достаточно много государственных сервисов, которые выдают информацию в виде xml. Эти данные можно сразу отображать в удобно перевариваемом виде, в нужной форме.
А если случится так, что форма видоизменится и/или в xml добавятся новые (или удалятся старые) реквизиты, то достаточно подкорректировать xsl-шаблон, чтобы форма отчета осталась актуальной не проводя при этом доработок вычислений.
Что касается размещения xsl-файла. То размещать его можно, к примеру, в аналитическом отчете. А чтобы отправить отчет сформированный по xsl-шаблону сам шаблон уже не нужен, можно отправить html-страницу построенную на основе шаблона.

Алексей,
Если у нас уже есть xml и нам надо его отобразить пользователю, то я согласен что надо использовать xslt.
Не надо показывать незнающим разработчикам что надо сначала выгружать sql-запросом в xml, учить xsl и писать преобразование. Думаю, нужна статья, показывающая, что в большинстве случаев html можно и надо формировать прямо на sql. Отображение sql -> html частая задача, xml->html редкая. Изучать что-то новое (при этом сомнительно удобное) и делать на нем все подряд отчеты не стоит. Потому что тем, кому достанется такое наследие, тоже придется учить xslt.
Разделить данные и представление можно в рамках одного sql-запроса. Так что выгружать сначала в xml, а потом его преобразовывать в HTML xslt нет особого смысла, ведь промежуточный xml нигде использоваться не будет. Вот как выглядит sql-запрос для такого же результата:

Это я всё к тому, что статья в каком-то неправильном ключе подана. Сам по себе материал полезен, но логичнее было бы сразу указать, что такой подход стоит использовать если уже есть xml или он для чего-то нужен, а не как промежуточное звено. А лучше сначала написать статью про формирование html-отчетов с помощью for xml, про эту штуку думаю тоже мало народу знает, хотя она ну очень удобная. SQL знают все, учить почти ничего нового не надо.

Александр,
Выше я уже написал, что статья для того, чтобы подтолкнуть разработчиков к изучению xsl. И приведенный пример не является идеальным ни с технической, ни с точки зрения бизнес-процессов. Это просто демо-пример с помощью которого описаны базовые xsl-конструкции.
Отвечу на некоторые Ваши утверждения, которые кажутся мне спорными:
«Отображение sql -> html частая задача, xml->html редкая» — очень спорное утверждение. Слишком много ньюансов для решения различных задач и в каждой задаче луший вариант необходимо выбирать. Универсального нет.
«лучше сначала написать статью про формирование html-отчетов с помощью for xml» — думаю, тема тоже интересная, но эта статья именно про xsl.
«SQL знают все, учить почти ничего нового не надо» — тоже спорное утверждение.
«Разделить данные и представление можно в рамках одного sql-запроса» — можно. Но далеко не всегда нужно. Все-таки основная задача SQL-сервера не в этом. Особенно это касается крупных заказчиков, у которых SQL-сервер загружен «основной» работой. И, опять же, цель статьи была — рассказать именно про xsl.
И по результатам переписки, думаю Вам есть что рассказать по тематике отображения данных базы данных в виде html-страницы. Если бы такая статья(и) появились на клабе, то было бы очень здорово. Сам бы с удовольствием почитал.

Алексей, давайте не уходить в сторону от основного вопроса, он звучит так: зачем мне делать SQL->XML->[xslt]->HTML, если можно SQL->HTML.
1) Если у нас уже есть XML (в таком формате хранятся данные или в таком формате откуда-то приходит), то я согласен, что хорошим вариантом отображения является использование XSLT. Собственно статья об этом (а не о том, что ВООБЩЕ отчеты хорошо и удобно строить используя xslt). И это надо указать в статье, и не приводить смущающих примеров (с выгрузкой в XML с SQL) и сравнивать с rtf. Подавляющее большинство отчетов в Directum строится на основе данных из SQL-таблиц, а не XML.
2) Аргумент про то, что это не задача SQL — он смешной. SQL это делать умеет, и делает это быстро, дешево и удобно. По сравнению с «лишней» нагрузкой, которую создает работа с ОМ и говнокод, работа с XML — просто семечки. А еще напомню про существование приложений (я лично работал с WebTutor), для которых XML — чуть ли не основной тип хранимых данных и все выборки и преобразования XML производятся в БД. Ну и писать такое и в примере делать SQL->XML как-то нелогично.
3) Чтобы использовать Ваш подход, надо знать и SQL->XML и XSL. Мой же вариант проще, достаточно знать SQL->XML(HTML). Я не услышал ни одного аргумента в пользу SQL->XML->[xslt]->HTML. Сначала Вы говорите, что мой подход «не соответсвует парадигме MVC», а когда я пишу что данные и представление можно разделить и в рамках одного SQL-запроса и XML в вашем подходе ИСПОЛЬЗУЕТСЯ ТОЛЬКО КАК ПРОМЕЖУТОЧНОЕ ЗВЕНО (а не как модель), Вы пишете что разделять модель и представление «далеко не всегда нужно».

Вы можете придумать конкретный пример, когда нам гораздо удобнее и разрабатывать и поддерживать веб-отчет используя SQL->XML->[xslt]->HTML, а не SQL->HTML? Я лично изучал xsl, пытался пользоваться. Но за 5 лет реально что-то делал SQL->XML->[xslt]->HTML 1 раз и то потом переделал на SQL->HTML потому что xsl было излишеством, которое, к тому же, мало кто знал. Я видел веб-контролы в канцелярии на xslt и мое мнение — они слишком сложны для такой простой задачи. SQL->HTML я использовал раз 50 наверно уже (как для простых задач, так и для сложных 1, 2 etc). И не потому что не знаю xsl, а потому что SQL->HTML проще и удобнее. Возможно мне не попадались подходящие задачи, но такой вот у меня опыт. А Вы сколько раз делали SQL->XML->[xslt]->HTML и SQL->HTML?

ForCoder

Книги по XML и XSLT, скачать бесплатные книги, самоучители и учебники по XML и XSLT в хорошем качестве

В книге содержатся советы, алгоритмы и готовые примеры программ из различных областей: шифрование, файловые и сетевые операции, XML, ASP.NET, взаимодействие с MS Office и Internet Explorer и др. Описаны синтаксис языка С#, вопросы отладки и профилирования приложений, а также проблемы, возникающие при переходе с других языков программирования на язык С#. Рассматриваются примеры наиболее часто используемых регулярных выражений. Отдельная глава посвящена работе с аппаратурой.
Архив содержит саму книгу и CD с исходным кодом.

7,402 просмотров всего, сегодня нет просмотров

Java. Методы программирования

Пособие предназначено для программистов, начинающих и продолжающих изучение технологий Java SE, JEE и других. В его первой части рассматриваются основы языка Java и концепции объектно-ориентированного программирования. Во второй части изложены аспекты применения библиотек классов языка Java, включая файлы, коллекции, сетевые и многопоточные приложения, а также взаимодействие с ХМL. В третьей части приведены основы программирования распределенных информационных систем с применением сервлетов, JSP и собственных тегов разработчика. В четвертой части даны основы практического применения шаблонов проектирования.
В конце каждой главы даются тестовые вопросы по материалу главы и задания для выполнения.
В приложениях приведены дополнительные материалы, относящиеся к использованию UML, SQL, Ant, XML, а также краткое описание популярных технологий Log4J, JUnit, JPA и Hibernate.

7,678 просмотров всего, сегодня нет просмотров

Open XML кратко и доступно

Описание книги Open XML кратко и доступно:
В этой книге содержится подробный обзор трех основных языков разметки стандарта Open XML. Книга рассчитана на читателей, знакомых с XML или HTML. Архитекторы и разработчики ПО, создающие ориентированные на документы решения, узнают, как построить эти решения на платформе Open XML.

10,500 просмотров всего, сегодня нет просмотров

Advanced Applications and Structures in Xml Processing: Label Streams, Semantics Utilization and Data Query Technologies

Описание книги Advanced Applications and Structures in Xml Processing: Label Streams, Semantics Utilization and Data Query Technologies:
Applications and Structures in XML Processing: Label Streams, Semantics Utilization and Data Query Technologies reflects the significant research results and latest findings of scholars’ worldwide, working to explore and expand the role of XML. This collection represents an understanding of XML processing technologies in connection with both advanced applications and the latest XML processing technologies that is of primary importance. It provides the opportunity to understand topics in detail and discover XML research at a comprehensive level.

3,701 просмотров всего, сегодня нет просмотров

XML: разработка Web-приложений

Описание книги XML: разработка Web-приложений:
В книге предлагается полное описание языка XML в совокупности с языками XSLT и XPath, представленное в первой части. Вторая часть книги содержит практическое руководство по применению материала, изложенного в первой части книги. Помимо XML затрагиваются вопросы, возникающие при построении реальных Web-приложений, а именно передача параметров HTTP-запроса серверу, проектирование форм, представление данных с помощью каскадных стилевых таблиц, обработка действий пользователя с помощью JavaScript.

Содержание книги «XML: разработка Web-приложений»:

Часть I. XML от А до Я

  • Язык XML
  • Язык XSLT
  • Язык XPath
  • Комплексный пример
  • Необходимые дополнения

Часть II. Практическая разработка web-приложений

  • Средства создания Web-приложения
  • Каскадные стилевые таблицы
  • Методика обработки данных
  • Представление данных

10,355 просмотров всего, сегодня нет просмотров

Python & XML

Описание книги Python & XML:
If you are a Python programmer who wants to incorporate XML into your skill set, this is the book for you. Python has attracted a wide variety of developers, who use it either as glue to connect critical programming tasks together, or as a complete cross-platform application development language. Yet, because it is object-oriented and has powerful text manipulation abilities, Python is an ideal language for manipulating XML.

Python & XML gives you a solid foundation for using these two languages together. Loaded with practical examples, this new volume highlights common application tasks, so that you can learn by doing. The book starts with the basics then quickly progresses to complex topics, like transforming XML with XSLT, querying XML with XPath, and working with XML dialects and validation. It also explores the more advanced issues: using Python with SOAP and distributed web services, and using Python to create scalable streams between distributed applications (like databases and web servers).

The book provides effective practical applications, while referencing many of the tools involved in XML processing and Python, and highlights cross-platform issues along with tasks relevant to enterprise computing. You will find ample coverage of XML flow analysis and details on ways in which you can transport XML through your network.

Whether you are using Python as an application language, or as an administrative or middleware scripting language, you are sure to benefit from this book. If you want to use Python to manipulate XML, this is your guide.

6,180 просмотров всего, сегодня нет просмотров

XML Bible

Описание книги XML Bible:
The emergence of XML is having an enormous impact on Web development, and scaling the learning curve of this new technology is a priority for many developers. The XML Bible offers a superb introduction to the subject and the groundwork to understand XML’s future developments.

Author Elliotte Rusty Harold uses a patient, step-by-step discussion that clearly points out the potential of XML without boring his readership with tons of SGML spec-speak. Harold opens quickly with a «Hello World» example to get the reader coding early, and follows that with a simple but powerful example of XML’s data management benefits—presenting baseball statistics. Once you’ve coded your first XML documents, you’ll be hooked on the technology and motivated to learn about the more sophisticated topics.

Style sheet languages are covered comprehensively to illustrate the presentation possibilities and pitfalls. An unusually long list of real-life XML applications also shows how XML is already being used, and there is in-depth coverage of the Resource Description Framework, Channel Definition Format, and Vector Markup Language. The book wraps up with a section that helps you design your own XML application from scratch.

4,604 просмотров всего, сегодня нет просмотров

XSLT. Сборник рецептов

Описание книги XSLT. Сборник рецептов:
Язык XSLT (Extensible Stylesheet Language Transformation) стал основным инструментом обработки XML-документов, но многие разработчики все еще не освоили его в полной мере и потому считают, что проще модифицировать имеющийся код, чем писать новый с нуля. В версии 2.0 многие проблемы решены, но появился ряд новых возможностей, которые еще надо изучить. К тому же она пока недостаточно поддержана.

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

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

7,990 просмотров всего, сегодня нет просмотров

Изучаем XML

Описание книги Изучаем XML:
Данное издание посвящено расширяемому языку разметки XML — перспективному и мощному инструменту, обеспечивающему гибкий способ создания самодокументируемых документов и совместного использования как формата, так и данных в Интернете. Рассмотрены история, современное состояние и задачи XML, фундаментальные вопросы. Для начинающих разработчиков излагаются основы техники создания документов XML, понятия элементов, атрибутов, сущностей и пространств имен XML. Профессионалам адресованы сложные вопросы — трансформации, моделирование документов, тонкая настройка шаблонов, XML-программирование, использование ссылок и каскадных таблиц стилей.

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

13,888 просмотров всего, сегодня нет просмотров

XML. Справочник

Описание книги XML. Справочник:
«XML. Справочник» — это источник информации для разработчиков в быстро развивающемся мире XML. Читатели, поняв суть базового стандарта XML, смогут быстро разобраться в тонкостях DTD, пространств имен, соблюдения корректности документов XML и поддержки Unicode.

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

Обзор ключевых технологий, используемых в основном для повествовательных XML-документов, таких как веб-страницы, книги и статьи, поможет вам получить практические знания по XSLT, XPath, XLink, XPointer, CSS и XSL-FO. Наверняка многие заинтересуются применением XML для интенсивной обработки данных.

Несколько глав посвящены утилитам и API, необходимым для написания программ обработки XML, таким как SAX — простому API для XML, и DOM — объектной модели документов консорциума W3C.

В книгу также включен материал, образующий основу любого справочника издательства O’Reilly. В этих главах приведены подробные синтаксические правила (сопровождаемые примерами) основных технологий XML, в том числе DTD, XPath, XSLT, SAX и DOM. В данном справочнике описаны правила, которых должны придерживаться авторы всех XML-документов — как веб-дизайнеры, создающие анимации с помощью SMIL, так и программисты C++, применяющие SOAP для сериализации объектов в удаленную базу данных.

9,471 просмотров всего, сегодня нет просмотров

Применение XML+XSLT при создании сайта

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

Используя XML+XSLT, можно создать сайт/портал двумя путями (о других я пока не в курсе :). Первый способ заключается в посылке пользовательскому браузеру xml-файла, содержащего контент, и xslt-файла, содержащего правила отображения контента в окне браузера. Полученный xml-файл браузер трансформирует согласно правилам из xslt-файла. Минусы очевидны: пересылается избыточная информация и не все браузеры способны производить это самое преобразование. Втрой способ заключается в преобразовании xml-файла с помощью xslt-файла на стороне веб-сервера с помощью какого-либо программного скрипта и посылке клиентскому браузеру обычного html-файла. Как раз второй метод и будет рассматриваться в данной статье.

Основной принцип заключается в следующем: так называемый контент сайта (статьи, ссылки, структура и т.п.) хранятся в xml-файлах. Известно, что данными удобно управлять, когда данные представляют собой не одну большую кучу, а имеют четкую структуру, т.е. каждому элементу данных сопоставляется тип данных и его место в общей массе. XML как раз на подобные задачи и ориентирован. Оформление сайта (цвета, относительное расположение элементов) храняться в xsl файлах (шаблонах). Функция преобразования оформялет отображение контента согласно правилам шаблона, выдавая готовый html-код.

Разберем следующий пример. У нас есть некий файл, описывающий два абзаца статьи и их нам надо вывести в основное поле странички. Сначала посмотрим на xml файл, который бы мог описывать нашу статью:

Стилевая таблица (шаблон), на основе которой будет происходить преобразование основной части странички можно представить в следующем виде:

(*) убираем из получаемого результата преобразования «наглядность» в виде лишних пробелов и переводов строк

(*) формируем стандартный html-абзац с тэгом

(*) копируем текстовое содержимое

(*) отлавливаем признак списка

    (*) формируем html-тэг списка
    (*) выбираем все элементы списка, помеченные узлом
    (*) формируем html-тэг элемента списка

В изучении использования XSLT-преобразований вам поможет литература.

Итак, что мы имеем? Мы имеем описание контент статьи и правила отображения статьи в основной части окна. Теперь это все нам надо как-то оформить в полноценную страничку. Для этого используется обычный шаблон в виде описания таблицы на html-языке, центральная ячейка которой заполняется результатом преобразования.

Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL