XSLT и CSS для отображения XML. Не используйте специальные символы


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

Применение стилей CSS ;

Применение XSL ;

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

Без использования CSS или XSL XML-документ отображается как простой текст в большинстве веб-браузеров. Некоторые браузеры, такие как Internet Explorer и Mozilla Firefox отображают структуру документа в виде дерева, позволяя сворачивать и разворачивать узлы с помощью нажатий клавиши мыши.

Применение стилей css.

Процесс аналогичен применению CSS к HTML -документу для отображения.

Для применения CSS при отображении в браузере, XML-документ должен содержать специальную ссылку на таблицу стилей. Например:

Это отличается от подхода HTML, где используется элемент .

Применение xsl.

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

Для задания XSL трансформации (XSLT ) на стороне клиента требуется наличие в XML инструкции следующего вида:

Словари xml

Так как XML является достаточно абстрактным языком, были разработаны словари XML.

Словарь позволяет разработчикам договориться о некотором конечном наборе имен тегов и атрибутов этих тегов. Одним из первых словарей является XHTML , который понимают большинство браузеров. XHTML часто используют для хранения и редактирования контента в CMS .

Были созданы более специализированные словари, например протокол передачи данных SOAP , который не является человеко-ориентированным и достаточно трудно читаем. Есть коммерческие словари, такие как CommerceML , xCBL и cXML которые используются для передачи данных, ориентированных на торговую деятельность, эти словари включают в себя описание системы заказов, поставщиков, продуктов и прочее.

Обычно, описывая какой-либо документ, человек для себя придумывает некоторый словарь, который потом описывается посредством DTD или просто объясняется «на пальцах» заинтересованным лицам.

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

Как выглядит xml-документ?

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

Структура документа

Простейший XML- документ может выглядеть так, как это показано в Примере 1

Первый

Второй подпункт 1

Третий

Последний

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

Тело документа XML состоит из элементов разметки (markup) и непосредственно содержимого документа - данных (content). XML - тэги предназначены для определения элементов документа, их атрибутов и других конструкций языка. Более подробно о типах применяемой в документах разметки мы поговорим чуть позже.

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

Как правильно использовать XML

XML как инструментальное средствоЧасто используемые сокращения
  • CDATA: Character Data (символьные данные)
  • DOM: Document Object Model (объектная модель документа)
  • E4X: ECMAScript for XML (ECMAScript для XML)
  • IDE: Integrated Development Environment (интегрированная среда разработки)
  • W3C: World Wide Web Consortium (консорциум WWW)
  • XML: Extensible Markup Language (расширяемый язык разметки)
  • XSLT: Extensible Stylesheet Language Transformations (расширяемый язык преобразований таблиц стилей)

В настоящее время XML воспринимается как нечто само собой разумеющееся. Он повсюду! Но если посмотреть со стороны, то можно увидеть, что это мощная технология. Есть интегрированные среды разработки, которые помогают строить XML-деревья. Есть целый ряд технологий проверки корректности XML-кода. Есть XSLT – специальный язык преобразования XML. Поддержка XML встроена даже непосредственно в синтаксис некоторых языков (как, например, E4X в ActionScript).

Но у XML есть и обратная сторона. Его можно использовать неправильно. Его можно использовать плохо. Он может быть чрезмерно сложным. Он может быть недоопределенным. С ним может быть трудно работать. Что нужно сделать для более эффективного использования этой мощной технологии? В своей статье я дам 10 советов, которые помогут ответить на этот вопрос.

Не используйте XML в качестве имени файла или корневого тега

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

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

Не переопределяйте обобщенные или специфичные для языка конструкции

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

Этим я хочу сказать, что специфичные для языка конструкции нужно хранить вне XML. Как часто вы встречали 07-18-2010 ? Что такое NSDate? Ага, это имя класса для работы с датами на прикладной платформе. Что произойдет при смене платформы или языка? Потребуется преобразование тегов NSDate во что-то другое, что используется на новой платформе.

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

Еще одно важное правило – избегайте использования в XML излишних обобщений. Взгляните на следующий пример ():

Листинг 1. Обобщенное дерево узлов jack

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

Листинг 2. Более эффективное дерево узлов jack

Разве так не лучше? Код говорит то, что означает, и означает то, что говорит. Его легче читать и анализировать. Его легче проверять и преобразовывать при помощи XSLT. Он даже меньше по размеру.

Не делайте файлы слишком большими

Знаю, что вы скажете: "Дисковая память стоит дешево. За десять центов я куплю еще один терабайт". Это верно. Вы действительно можете создавать гигабайтные XML-файлы. Но программирование – это постоянные компромиссы. Приходится менять дисковое пространство на время или память на время. А при работе с огромным XML-файлом вы получаете худшие стороны и того, и другого. Файл занимает много места на диске, а на его анализ и проверку уходит много времени. Кроме того, большой файл исключает использование DOM-анализатора, поскольку построение дерева требует бесконечного времени и огромного количества памяти.

Какова же альтернатива? Можно создать несколько файлов. Один выступает в качестве индекса, а другие содержат большие ресурсы, которые, возможно, будут нужны не всем пользователям этого XML. Другой вариант– вынос всех больших фрагментов CDATA из XML-файла и помещение их в свои собственные файлы с собственными форматами. Если вы хотите хранить все данные вместе, запакуйте все файлы в новый файл с новым расширением. Любой популярный язык программирования имеет модули, облегчающие быструю упаковку и распаковку файлов.

Не используйте пространства имен, если в этом нет острой необходимости

Пространства имен (namespace) – это мощная составляющая XML-лексикона. Они облегчают реализацию расширяемых форматов файлов. Вы можете определить базовый набор тегов для всех потребностей вашего приложения, а затем разрешить пользователям добавлять свои собственные данные в свое собственное пространство имен в файле, не затрагивая ваше дерево объектов.

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

Поэтому используйте пространства имен XML, только если это действительно необходимо. Не используйте их просто потому, что "XML позволяет это делать". XML прекрасно работает и без пространств имен.

Не используйте специальные символы

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

Используйте XML Schema

Синтаксический анализ XML является непростой задачей. Для точного анализа необходимо проделать большую работу по защите кода от возможного отсутствия и некорректного использования тегов или атрибутов. Это дополнительная работа по написанию кода, дополнительная сложность, а также затенение реальной бизнес-логики, являющейся вашей главной заботой. Как избежать этого? Проверяйте XML перед его использованием. Для этого можно использовать несколько стандартов. Можно указать Document Type Definition (DTD) или XML Schema (ссылки на информацию о DTD и XML Schema приведены в разделе ). Лично я нахожу XML Schema намного более простой в работе, но если вы новичок в этом деле, попробуйте различные системы проверки корректности.

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

Нумеруйте версии

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

Сочетайте узлы и атрибуты

Инженеры довольно ленивый народ. Я могу это утверждать, поскольку сам такой. Не спорьте, все мы такие. Если интегрированная среда разработки предложит выполнить экспорт XML вместо нас, мы наверняка согласимся. Но обычно интегрированная среда создает очень плохой XML-код. Вероятно, вы уже встречались с чем-то похожим на :

Листинг 3. Список пользователей 1 jack

Должен ли быть тегом? Я утверждаю, что он должен быть атрибутом. Код становится более коротким и осмысленным, появляется возможность искать пользователя по идентификатору при помощи простого XPath-выражения (/users/user[@id=1]).

Чтобы код был читабелен, несомненно лучше использовать атрибуты, как показано в .

Листинг 4. Более удобный список пользователей jack

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

Используйте CDATA, но не злоупотребляйте этим

XML налагает множество ограничений на использование определенных символов: кавычек, амперсандов, знаков "меньше" и "больше" и т.д. Однако на практике эти символы используются очень часто. Поэтому приходится либо преобразовывать все в безопасный для XML формат, либо помещать большие фрагменты текста, кода или еще чего-нибудь в блоки CDATA . Мне кажется, что разработчики избегают использования CDATA , поскольку думают, что это затруднит синтаксический анализ. Но разделы CDATA анализировать не труднее, чем что-либо другое – большинство DOM-анализаторов обрабатывает их самостоятельно, поэтому вам даже не нужно думать об этом.

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

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

Храните необязательные данные в отдельной области

До сих пор я рассказывал об XML-документах с жестким форматом. Я даже рекомендовал использовать технологию проверки корректности, (например, XML Schema), гарантирующую жесткую структуру. Тому есть веская причина: структурированные данные легче анализировать. А если нужна определенная гибкость? Я рекомендую размещать необязательные данные в отдельном блоке в своем собственном узле. Взгляните, например, на .

Листинг 5. Неупорядоченная запись о пользователе jack d herrington 8:00

Эта запись содержит все ожидаемые данные о пользователе. Я согласен с first, middle, last, но зачем здесь runningpace? Это необходимо? Будете ли у вас много таких полей? Будут ли они расширяемыми? Если ответ на все эти вопросы утвердителен, я порекомендовал бы сделать так (см. ):

Листинг 6. Хорошо структурированная запись о пользователе jack d herrington 8:00

При таком подходе вы можете иметь сколько угодно полей, не загромождая пространство имен родительского элемента . Вы даже можете проверить корректность этого документа, а также обратиться к определенному полю при помощи XPath-выражения (//user/userdata/field[@name="runningpace").

Заключение

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

Стандартом определены два уровня правильности документа XML:

  • Правильно построенный (Well-formed). Правильно построенный документ соответствует всем общим правилам синтаксиса XML, применимым к любому XML-документу. И если, например, начальный тег не имеет соответствующего ему конечного тега, то это неправильно построенный документ XML. Документ, который неправильно построен, не может считаться документом XML; XML-процессор (парсер) не должен обрабатывать его обычным образом и обязан классифицировать ситуацию как фатальная ошибка .
  • Действительный (Valid). Действительный документ дополнительно соответствует некоторым семантическим правилам. Это более строгая дополнительная проверка корректности документа на соответствие заранее определённым, но уже внешним правилам, в целях минимизации количества ошибок, например, структуры и состава данного, конкретного документа или семейства документов. Эти правила могут быть разработаны как самим пользователем, так и сторонними разработчиками, например, разработчиками словарей или стандартов обмена данными. Обычно такие правила хранятся в специальных файлах - схемах, где самым подробным образом описана структура документа, все допустимые названия элементов, атрибутов и многое другое. И если документ, например, содержит не определённое заранее в схемах название элемента, то XML-документ считается недействительным ; проверяющий XML-процессор (валидатор) при проверке на соответствие правилам и схемам обязан (по выбору пользователя) сообщить об ошибке.

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

Синтаксис XML

В этом разделе рассматривается лишь правильное построение документов XML, то есть их синтаксис.

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

Следующий простейший пример - правильно построенный документ XML: Это книга: "Книжечка" Первая строка XML-документа называется объявлением XML (XML declaration) - это необязательная строка, указывающая версию стандарта XML (обычно это 1.0), также здесь может быть указана кодировка символов и внешние зависимости. Спецификация требует, чтобы процессоры XML обязательно поддерживали Юникод -кодировки UTF-8 и UTF-16 (UTF-32 не обязателен). Признаются допустимыми, поддерживаются и широко используются (но не обязательны) другие кодировки, основанные на стандарте ISO/IEC 8859 , также допустимы другие кодировки, например, русские Windows-1251 , KOI-8 .

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

Ниже приведён пример простого кулинарного рецепта, размеченного с помощью XML:

Простой хлеб Мука Дрожжи Тёплая вода Соль

Структура

Остальная часть этого XML-документа состоит из вложенных элементов , некоторые из которых имеют атрибуты и содержимое . Элемент обычно состоит из открывающего и закрывающего тегов, обрамляющих текст и другие элементы. Открывающий тег состоит из имени элемента в угловых скобках, например, « »; закрывающий тег состоит из того же имени в угловых скобках, но перед именем ещё добавляется косая черта, например, « ». Содержимым элемента (content) называется всё, что расположено между открывающим и закрывающим тегами, включая текст и другие (вложенные) элементы. Ниже приведён пример XML-элемента, который содержит открывающий тег, закрывающий тег и содержимое элемента:

Замесить ещё раз, положить на противень и поставить в духовку.

Мука

В приведённом примере у элемента « ingredient » есть два атрибута: « amount », имеющий значение «3», и « unit », имеющий значение «стакан». С точки зрения XML-разметки, приведённые атрибуты не несут никакого смысла, а являются просто набором символов.

Кроме текста, элемент может содержать другие элементы:

Смешать все ингредиенты и тщательно замесить. Закрыть тканью и оставить на один час в тёплом помещении. Замесить ещё раз, положить на противень и поставить в духовку.

В данном случае элемент « Instructions » содержит три элемента « step ». XML не допускает перекрывающихся элементов. Например, приведённый ниже фрагмент некорректен, так как элементы « em » и « strong » перекрываются.

Обычный акцентированный выделенный и акцентированный выделенный

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

Сущность №1 Сущность №2

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

В XML определены два метода записи специальных символов: ссылка на сущность и ссылка по номеру символа. Сущностью (entity) в XML называются именованные данные, обычно текстовые, в частности, спецсимволы. Ссылка на сущность (entity references) указывается в том месте, где должна быть сущность и состоит из амперсанда (« & »), имени сущности и точки с запятой (« ; »). В XML есть несколько предопределённых сущностей, таких как « lt » (ссылаться на неё можно написав « < ») для левой угловой скобки и « amp » (ссылка - « & ») для амперсанда, возможно также определять собственные сущности. Помимо записи с помощью сущностей отдельных символов, их можно использовать для записи часто встречающихся текстовых блоков. Ниже приведён пример использования предопределённой сущности для избежания использования знака амперсанда в названии:

AT&T

Полный список предопределённых сущностей состоит из & («&»), < (« («>»), " («"»), и " («"») - последние две полезны для записи разделителей внутри значений атрибутов. Определить свои сущности можно в DTD -документе.

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

Ссылка по номеру символа (numeric character reference) выглядит как ссылка на сущность, но вместо имени сущности указывается символ # и число (в десятичной или шестнадцатеричной записи), являющееся номером символа в кодовой таблице Юникод . Это обычно символы, которые невозможно закодировать напрямую, например, буква арабского алфавита в ASCII -кодированном документе. Амперсанд может быть представлен следующим образом:

AT&T

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

История

Годом рождения XML можно считать 1996 год , в конце которого появился черновой вариант спецификации языка, или , когда эта спецификация была утверждена. А началось всё с появления в 1986 году языка SGML.

SGML (Standard Generalized Markup Language - стандартный обобщённый язык разметки) заявил о себе как гибкий, комплексный и всеохватывающий мета-язык для создания языков разметки. Несмотря на то, что понятие гипертекста появилось в 1965 году (а основопологающие принципы сформулированы в 1945 году ), SGML не имеет гипертекстовой модели. Создание SGML можно с уверенностью назвать попыткой объять необъятное, так как он объединяет в себе такие возможности, которые крайне редко используются все вместе. В этом и состоит его главный недостаток - сложность и, как следствие, дороговизна этого языка ограничивает его использование только крупными компаниями, которые могут позволить себе купить соответствующее программное обеспечение и нанять высокооплачиваемых специалистов. Кроме того, у небольших компаний редко возникают настолько сложные задачи, чтобы привлекать к их решению SGML.

Наиболее широко SGML применяется для создания других языков разметки, именно с его помощью был создан язык разметки гипертекстовых документов - HTML , спецификация которого была утверждена в 1992 году . Его появление было связано с необходимостью организации стремительно увеличивающегося массива документов в сети Интернет. Бурный рост количества подключений к Интернету и, соответственно, Web -серверов повлек за собой такую потребность в кодировке электронных документов, с которой не мог справиться SGML вследствие высокой трудности освоения. Появление HTML - очень простого языка разметки - быстро решило эту проблему: лёгкость в изучении и богатство средств оформления документов сделали его самым популярным языком для пользователей Интернет. Но, по мере роста количества и изменения качества документов в Сети, росли и предъявляемые к ним требования, и простота HTML превратилась в его главный недостаток. Ограниченность количества тегов и полное безразличие к структуре документа побудили разработчиков в лице консорциума W3C к созданию такого языка разметки, который был бы не столь сложен, как SGML, и не настолько примитивен, как HTML. В результате, сочетая в себе простоту HTML, логику разметки SGML и удовлетворяя требованиям Интернет, появился на свет язык XML.

Сильные и слабые стороны Достоинства Недостатки
  • Неоднозначность моделирования.
  • XML не содержит встроенной в язык поддержки типов данных . В нём нет строгой типизации, то есть понятий «целых чисел», «строк», «дат», «булевых значений» и т. д.
  • Иерархическая модель данных , предлагаемая XML, ограничена по сравнению с реляционной моделью и объектно-ориентированными графами и сетевой моделью данных.
Отображение XML во Всемирной паутине

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

  • Применение стилей CSS ;
  • Применение преобразования XSLT ;
  • Написание на каком-либо языке программирования обработчика XML-документа.

    • Без использования CSS или XSL XML-документ отображается как простой текст в большинстве Web-браузеров. Некоторые браузеры, такие как Internet Explorer , Mozilla и Mozilla Firefox отображают структуру документа в виде дерева, позволяя сворачивать и разворачивать узлы с помощью нажатий клавиши мыши.

    Применение стилей CSS

    Процесс аналогичен применению CSS к HTML документу для отображения.

    Для применения CSS при отображении в браузере, XML документ должен содержать специальную ссылку на таблицу стилей. Например:

    Это отличается от подхода HTML, где используется элемент .

    Применение преобразования XSLT

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

    Для того, чтобы автоматом преобразовывать содержимое xml-файлов в удобочитаемый вид/формат (html, rtf, pdf, txt, vrml, svg, java и т.д.) - следует воспользоваться XSLT, вместо того, чтобы стараться применить CSS.

    Недостатки CSS:
    1. CSS не может изменить порядок следования элементов в xml-документе. Если вы захотите отсортировать некоторые элементы или отфильтровать их по некоторому свойству, то CSS вам в этом однозначно не помощник.
    2. CSS не выполняет вычисления. Если вы захотите вычислить и вывести значение(например, просуммировать числовые значения всех элементов в xml-документе), CSS вам не подойдёт.
    3. CSS не может объединять документы. Если вы захотите объединить пару десятков xml-документов с заказами на покупку и напечатать сводку всех заказанных товаров, то CSS вам опять же не поможет.

    Маленький пример использования XSL

    Имеется некоторый xml-файл настроек плагина:


    Плагин контролирует настройки слоёв чертежей AutoCAD. Ниже представлена таблица, в которой перечислены проверяемые позиции.

    Проверка имени слоя
    true
    Проверка имени слоя на соответствие правилу построения имён

    Проверка цвета слоя
    true
    Проверка на то, чтобы слою назначались цвета из палитры "Index Color"

    Проверка типа линии
    true
    Проверка на то, чтобы слоям назначались типы линий только из определённого набора

    Проверка толщин линий
    true
    Проверка на то, чтобы слоям назначались толщины линий только из определённого набора

    Проверка наличия примечания
    true
    Каждый слой должен иметь примечание, расшифровывающее его назначение

    Фиксированный набор слоёв
    false
    Следует ли запретить пользователям создавать дополнительные слои, по установленным в Стандарте правилам

    Плагин должен считывать с него настройки и работать в соответствии с ними. В то же время должна присутствовать некая документация, которую бы юзер мог прочитать и понять. Причём материал, изложенный в документации должен соответствовать тем настройками, которые установлены в текущий момент. Для того, чтобы не держать в голове, что после того, как подправишь настройки, нужно лезть и править документацию, можно всё это представить в виде одного xml-файла. Плагин будет читать из него настройки, а юзер - открывать его в браузере и... видеть его в "человеческом" виде... Для этого создаём файл styleSheet.xsl с таким содержимым:

    Настройки плагина

    Параметр Значение Примечание

    Теперь, если юзер в браузере откроет наш xml-файл, то он увидит не запутанный (с его точки зрения), неудобный xml-текст, а это:

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

    5 ответов

    То, что ваше сердце говорит вам, является правильным. Хотя можно использовать CSS для XML, сам XML не имеет семантики. CSS предназначен для Интернета, для HTML и для предоставления семантических данных (хорошего) вида.

    XML более общий, чем это. XSLT был изобретен для преобразования одного формата данных в другой (XSLT 1.0 только XML, XSLT 2.0 - любой формат данных Unicode), то есть XML в HTML или XML в XSL-FO или другой формат XML или текста. XSL-FO был изобретен для размещения XML на бумаге или экране и гораздо более подробный, чем CSS.

    Некоторые плюсы и минусы в CSS + XML

    В основном, минусы, особенно. в свете использования XML в браузере. Пропустите общий совет ниже, если вы не хотите, чтобы все мои болтовня; -)

    CSS минус 1: нет CSS + XML для Интернета

    Против: это сильно зависит от контекста, но если вы хотите использовать XML для отображения в Интернете, подумайте еще раз: не используйте XML, а преобразовывайте его в HTML. Затем используйте CSS + HTML для отображения ваших данных. Если вы используете XML в Интернете, никакой поисковой системы или искателя, не понимаете разницу между и , но они поймут разницу между и .

    Это само по себе является достаточным основанием для использования XSLT для преобразования в HTML + CSS и исключения XML самостоятельно.

    CSS cons 2: CSS означает много больше работы

    Другая чрезвычайно важная причина, которую вы можете использовать: XML + CSS означает определение каждого элемента в CSS. Использование HTML + CSS означает, что пользовательские агенты уже знают свойства макета по умолчанию для всех элементов. Использование XML + XSLT означает, что вы обычно создаете HTML + CSS. Вы должны сделать это на стороне сервера, поскольку клиентская XSLT не очень надежна и совместима с кросс-браузером.

    CSS cons 3: доступность

    (извините, я не могу найти профи). Если XML не имеет семантики (SVG, как упоминается другим пользователем), нет смысла использовать CSS для макета. Если макет предположительно семантически понимается пользовательским агентом, XML + CSS не работает. Чтение текста в речь не имеет понятия, что делать, достоверность WAI (доступность) будет невозможна и т.д.

    CSS cons 4: ремонтопригодность, понятность, сценарии, проблемы

    Использование XML затрудняет выполнение любых сценариев на стороне клиента (да, DOM доступен, но как вы скажете браузеру, что такое script -tag? Но, возможно, он отреагирует на , но эй, вам нужен XSLT, чтобы получить там этот тег) и затрудняет его кроссбраузер (некоторые браузеры с трудом используют XML как таковой). Все, что HTML (например, мета, название, тело, script) не будет доступно. Невозможно добавить атрибуты заголовка или сообщить браузеру, что изображение (afaik).

    Без script будет работать на вас только для XML-страницы (prototype.js? jquery.js? ajax? no no и no).

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

    Преимущества CSS 1: для домена

    Если ваш домен SVG, SMIL, OD или что-то еще, вы, вероятно, уже знаете это: CSS является неотъемлемой частью спецификации и должен использоваться. Это полностью отличается от чистого, возможно неструктурированного XML-данных.

    AJAX думал

    Просто для сравнения: любой асинхронный вызов AJAX (должен) возвращает XML. Но любая библиотека, работающая с ней, будет либо интерпретировать ее как HTML, либо использовать XSLT или другое средство для ее трансформации до ее ввода на существующей странице.

    Основываясь на замечании от OP, мы смотрим на XML данных (а не на SVG или OpenDocument), и его нужно отображать в браузерах. Доступность и индексируемость не важны. Но это не имеет особого значения: вы не должны использовать только XML + CSS, если вы действительно не входите в какое-то приключение и не хотите узнать все недостатки XML в браузерах, хотите снова придумать каждый тег HTML и определить каждый и все, только чтобы отказаться от времени и вернуться к HTML (XML + XSLT == HTML + CSS ).

    Обновление: добавлено cons 2
    Обновление: добавлено cons 3 и профи 1
    Обновление: добавлено cons 4, примечание AJAX и заключение

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

    Нет ничего по своей сути неправильного использования CSS для стилей XML, это просто не очень часто (хотя я делал это в прошлом как эксперимент).

    Исходный документ

    Документ, к которому применяется одна или несколько таблиц стилей. Это закодировано на некотором языке, который представляет документ как дерево элементов. Каждый элемент состоит из имени, которое идентифицирует тип элемента, необязательно количество атрибутов и (возможно, пустое) содержимое. Например, исходный документ может быть экземпляром XML или SGML.

    Язык документа

    Язык кодирования исходного документа (например, HTML, XHTML или SVG ). CSS используется для описания представления языков документа, а CSS не изменяет основную семантику языков документа.

    (Мой акцент).

    Основные возможности, которые следует учитывать при принятии решения о том, следует ли использовать CSS в отличие от XSLT, выглядят следующим образом:

      Имеет ли смысл преобразовать XML-документ в другую структуру (например, XHTML), чтобы лучше представить семантику документа?

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

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

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

    2024 © gtavrl.ru.