Основы XML. Преобразование XML-HTML. Использование JavaScript. Не переопределяйте обобщенные или специфичные для языка конструкции. Применение стилей css

Для того, чтобы автоматом преобразовывать содержимое 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.

Как правильно использовать 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-документа в отображаемый пользователю вид:

Применение стилей 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- документ должен всегда начинаться с инструкции , внутри которой также можно задавать номер версии языка, номер кодовой страницы и другие параметры, необходимые программе-анализатору в процессе разбора документа

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), поэтому нет оснований не использовать его, когда это имеет смысл.