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

Синтаксис

Атрибут XML имеет следующий синтаксис:

....content.. < /element-name>

где attribute1 и attribute2 имеют следующее сформировать:

Name = "value"

значение должно находиться в двойном ("") или определиться ("") цитаты. Здесь, attribute1 и attribute2 уникально ярлыки атрибута.

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

]>

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

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

Вы можете также наблюдать что мы объявляли этот атрибут в начале XML.

Типы атрибута

Следовать таблица перечисляет тип атрибутов:

Правила атрибута элемента

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

Имя атрибута не должно появляться больше чем раз в такую же бирку старт-бирки или пуст-элемента.

Атрибут необходимо объявить в определении типа документа (DTD) используя объявление Атрибут-Списка.

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

Текст замены любой реальности сослался к сразу или косвенно в атрибуте со значением содержать также чем знак <

Элементы или атрибуты?

Вопросы проектирования XML-форматов

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

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

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

Важен ли порядок следования данных

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

Рассмотрим, например, список контактов (контактной информации), каждый из которых должен включать имя, возраст и номер телефона. Разумеется, с точки зрения логики, данные о возрасте не должны обязательно предшествовать номеру телефона. Поэтому, атрибуты и неупорядочены, и потому являются более интуитивным выбором. Сравните два небольших XML-документа, приведенные в Листингах 1 и 2:

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

DTD для документа, иллюстрирующего использование вложенных элементов, мог бы иметь следующий вид:

Очевидный недостаток DTD, приведенного в Листинге 4, состоит в том, что этот простой пример (Листинг 2) является недопустимым согласно этому DTD. Дело в том, что порядок вложенных элементов нарушен. В таблице показано, как можно использовать неупорядоченные вложенные элементы с DTD, хотя, если не имеется иных непреодолимых причин, лучший выбор - воспользоваться заданием атрибутов для передачи неупорядоченных данных.

Возможность нахождения многочисленных данных на одном уровне

Если одни и те же данные неоднократно повторяются в пределах объекта, вложенные элементы несомненно предпочтительней. Например, в рассмотренном выше примере объект contacts содержит множество объектов contact . Понятно, что в этом случае каждый контакт должен быть описан в элементе-потомке элемента contacts .

Однако, в реальной жизни при внесении изменений разработчики часто уходят от этого принципа проектирования. Рассмотрим, как это может происходить: сначала вы определяете, что у каждого Flazbar имеется прикрепленный к нему flizbam (а flizbam описывается одной величиной). Кажется вполне разумным сберечь дополнительное наполнение вложенных элементов и создать атрибут flizbam для тега Flazbar . Однако, затем - после того, как вы уже написали великолепный рабочий код для обработки несколькими Flazbar - вы узнаете, что в некоторых случаях у Flazbar могут быть два flizbam. Но это не проблема: вы вносите незначительные изменения в установленный код и просто переписываете DTD:

После исправления кода ваши старые XML-документы по-прежнему допустимы, и новые работоспособны. Немного погодя вы обнаруживаете, что у Flazbar может быть третий flizbam...

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

Обязательность сохранения свободного места

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

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

Важность удобочитаемости

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

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

Заключение

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

Ресурсы

• Все, что действительно необходимо знать о XML, это Рекомендация W3C "Расширяемый язык разметки (XML) 1.0" (Extensible Markup Language (XML) 1.0). Разумеется, чтобы понять, какое она имеет значение, требуется немного проницательности.
• В рубрике XML Cover Pages приводятся рекомендации по "Использованию элементов и атрибутов" (Using elements and attributes). На этой странице также можно найти ссылки на ряд статей, в которых предлагаются взаимопротиворечащие рассуждения о том, что выбрать атрибуты или элементы. Именно по этой причине мы, программисты, и "получаем наш длинный доллар"!
• Еще один способ понять различие между атрибутами и элементами - это изучить материалы "Форматы, основанные на документах, или форматы, основанные на данных" (" ").
• Познакомьтесь с другими статьями колонки "Советы о XML" (XML tips), публикуемыми в разделе developerWorks XML.

Об авторе

Дэвид Мертц использует абсолютно неструктурированный интеллект, чтобы писать о форматах структурированных документов. Дэвид доступен по адресу: [email protected] , а жизнь его описана на http://gnosis.cx/publish/ .

По всей видимости, это опечатка (в оригинале стоит Listing 2): и вместо Листинга 2 должен быть Листинг 1 (прим. пер.)

Элементы и атрибуты в XML Схеме

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

– Простое содержимое. Элемент содержит только текст (хотя, как говорилось в предыдущем параграфе, текст можно ограничить данными отдельного типа, такими как дата или числовое значение). Содержимое этого типа определяет­ся при помощи элемента simpleContent.

– Толькоэлементы. Элемент содержит только вложенные элементы. Содержи­мое этого типа определяется при помощи элемента complexType.

– Смешанноесодержимое. Элемент может содержать и текстовое содержимое, и вложенные элементы. XML Schema требует, чтобы последовательность элементов и текстового со­дер­жимого была строго определена, и допустимые документы должны соот­ветствовать этой последовательности.

– Пустоесодержимое. Элемент содержит только атрибуты, и никакого тексто­вого содержимого. XML Schema интерпретирует такие элементы как особый случай содержимого типа «только элементы» без объявленных элементов.

– Любоесодержимое. Элемент может быть пустым, содержать вложенные эле­менты и/или текст. Содержимое этого типа определяется при помощи эле­мента anyТуре.

Эти базовые типы элементов могут задаваться в объявлениях элементов схемы. Кроме того, можно указать, что элемент может встречаться в документе несколько раз, и задать минимальное и максимальное количество вхождений. Подобно SQL, XML Schema поддерживает значение элементов NULL, указывающее, что содержи­мое элемента неизвестно. В терминологии XML это значение называется nil, но смысл его тот же самый. Поддержка этого значения упрощает перенос данных ме­жду XML и столбцами баз данных, которые могут содержать значения NULL.

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

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

Как и в HTML, XML элементы могут иметь атрибуты. При этом значение атрибутов в XML и правило их создания во многом похожи на .

Атрибуты предоставляют дополнительную информацию об элементе.

XML атрибуты

В HTML атрибуты предоставляют некоторую дополнительную информацию об элементе:

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

computer.gif

XML атрибуты должны заключаться в кавычки

Вначале не беспокойтесь о производительности. вы будете удивлены тому, как быстро оптимизированный синтаксический анализатор xml будет копировать ваш XML файл. что более важно, каков ваш дизайн на будущее: по мере развития XML, как вы будете поддерживать свободную связь и функциональную совместимость?

более конкретно, вы можете сделать контентную модель элемента более сложной, но сложнее расширить атрибут.

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

Например, я предпочитаю.....

Вместо....

Rory Becker 30 Travis Illig 32 Scott Hanselman 34

Однако, если у меня есть данные, которые не могут легко отображаться внутри, например, 20-30 символов или содержат много кавычек или других символов, которые нужно экранировать, я бы сказал, что это время, чтобы разбить элементы... возможно, с блоками CData.

A programmer whose interested in all sorts of misc stuff. His Blog can be found at http://rorybecker.blogspot.com and he on twitter as @RoryBecker A cool guy for who has helped me out with all sorts of SVn information Scott works for MS and has a great podcast available at http://www.hanselminutes.com