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), поэтому нет оснований не использовать его, когда это имеет смысл.
Как правильно использовать XML
XML как инструментальное средствоЧасто используемые сокращенияВ настоящее время 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- документ должен всегда начинаться с инструкции , внутри которой также можно задавать номер версии языка, номер кодовой страницы и другие параметры, необходимые программе-анализатору в процессе разбора документа
Цель занятия
Знакомство с технологией XML. Изучение возможности представления документов XML в HTML. Использование скриптов JavaScript для навигации по таблице XML и организации поиска данных по условию. Рекомендуемая литература .
Краткие теоретические сведения
Технология XML (eXtensible Markup Language) была создана в конце 90-х годов прошлого столетия. Основные достоинства текста XML:
□ имеет структуру базы данных, доступен ЭВМ и человеку;
□ удобно обрабатывается средствами современных языков программирования;
□ легко переводится в HTML.
Рассмотрим следующий пример текстовой базы данных, написанной на XML:
Three men in the boat
Jerom-K-Jerom
12000
Notre Domme de Paris
V.Hugo
15000
А War and Peace
L.Tolstoy
16500
Angelika - the misstress of ghosts А and S. Gallen
9000
Это пример правильно составленного документа XML, элементами которого являются теги , , , , ,
Элементы в тексте расположены по типу дерева с головным элементом . Каждьтй элемент имеет сопряженный с ним закрывающий элемент. Область действия каждого элемента ограничена открывающим и закрывающим элементами. Не допускается пересечения области действия элементов, т. e. области либо вложены одна в другую, либо вовсе не пересекаются. Элемент , область действия которого содержит области действия всех других элементов, называется корневым. XML-документ можно рассматривать как текстовую базу данных. Значением элемента является информация, помещенная между тегами, определяющими данный элемент. Так, значением первого элемента является строка
Three men in the boat.
Наберите этот текст в любом редакторе и сохраните его как простой текстовый файл с расширением xml - например, дайте этому файлу имя textbd.xml. Можно просмотреть этот файл браузером Internet Explorer так же, как вы просматривали HTML-файлы. В случае ошибки интерпретатор XML выдаст подробную информацию о дислокации и сути ошибки.
Теперь покажем, как перевести этот вывод в табличную форму HTML, что выполняется средствами HTML. Создадим следующий файл HTML (листинг 2.12).
Листинг 2.12. HTML-документ для отображения таблицы XML
