Когда вы должны использовать атрибуты XML и когда вы должны использовать XML-элементы?
например.
<customData>
<records>
<record name="foo" description="bar" />
</records>
</customData>
или
<customData>
<records>
<record>
<name>foo</name>
<description>bar</description>
</record>
</records>
</customData>
Существует статья под названием "" Принципы XML-дизайна: когда использовать элементы и атрибуты" на веб-сайте IBM.
Несмотря на то, что не существует много жестких и быстрых правил, есть несколько хороших рекомендаций, упомянутых в публикации. Например, одна из рекомендаций состоит в том, чтобы использовать элементы, когда ваши данные не должны быть нормализованы для белого пространства, поскольку XML-процессоры могут нормализовать данные внутри атрибута, тем самым изменяя исходный текст.
Я нахожусь со ссылкой на эту статью время от времени, когда я разрабатываю различные структуры XML. Надеюсь, это будет полезно и для других.
Изменить - С сайта:
Принцип основного содержимого
Если вы считаете данную информацию частью основного материала, который выражается или передается в XML, помещаем его в элемент. Для человекочитаемых документов это обычно означает основной контент, который доводится до читателя. Для форматов форматов, ориентированных на машины, это обычно означает данные, которые поступают непосредственно из проблемного домена. Если вы считаете, что информация является периферийной или случайной для основного сообщения или предназначена исключительно для того, чтобы приложения обрабатывали основное сообщение, используйте атрибуты. Это позволяет избежать загромождения основного содержимого вспомогательным материалом. Для форматов форматов, ориентированных на машины, это обычно означает нотации приложений для основных данных из проблемной области.
В качестве примера я видел много форматов XML, обычно домашних, на предприятиях, где названия документов были помещены в атрибут. Я думаю, что титул является такой фундаментальной частью сообщения документа, что он всегда должен быть в содержании элементов. С другой стороны, я часто видел случаи, когда внутренние идентификаторы продуктов были выбраны как элементы в описательные записи продукта. В некоторых из этих случаев атрибуты были более уместными, потому что конкретный код внутреннего продукта не представлял первостепенного интереса для большинства читателей или процессоров документа, особенно если идентификатор был очень длинным или непостижимым.
Возможно, вы слышали, что основные данные передаются в элементах, метаданных в атрибутах. Вышеупомянутые два параграфа действительно выражают тот же принцип, но более преднамеренным и менее нечетким языком.
Принцип структурированной информации
Если информация выражается в структурированной форме, особенно если структура может быть расширяемой, используйте элементы. С другой стороны: если информация выражается как атомный токен, используйте атрибуты. Элементы - это расширяемый движок для выражения структуры в XML. Практически все инструменты обработки XML разработаны вокруг этого факта, и если вы правильно разбиваете структурированную информацию на элементы, вы обнаружите, что ваши инструменты обработки дополняют ваш дизайн и тем самым повышают производительность и ремонтопригодность. Атрибуты предназначены для выражения простых свойств информации, представленной в элементе. Если вы работаете с базовой архитектурой XML, создавая структурированную информацию в атрибуты, вы можете получить некоторую осторожность и удобство, но вы, вероятно, оплатите расходы на обслуживание.
Даты являются хорошим примером: дата имеет фиксированную структуру и, как правило, действует как единый токен, поэтому она имеет смысл как атрибут (предпочтительно, выраженный в ISO-8601). С другой стороны, представление личных имен - это случай, когда я видел этот принцип, удивляющий дизайнеров. Я вижу имена в атрибутах много, но я всегда утверждал, что личные имена должны быть в содержании элементов. Личное имя имеет удивительно переменную структуру (в некоторых культурах вы можете вызвать путаницу или оскорбление, опуская почтение или принимая порядок частей имен). Личное имя также редко является атомным токеном. Например, иногда вы можете искать или сортировать по имени, а иногда по фамилии. Я должен указать, что столь же проблематично, чтобы вызывать полное имя в содержимом одного элемента, поскольку оно должно помещать его в атрибут.
Один из наиболее продуманных элементов с атрибутами атрибутов приведен в правилах UK GovTalk. Это определяет методы моделирования, используемые для XML-обменов, связанных с правительством, но он стоит на своих собственных достоинствах и заслуживает рассмотрения.
Схемы ДОЛЖНЫ быть разработаны таким образом, чтобы элементы являются основными держателями информационный контент в XML экземпляров. Атрибуты более подходят для хранения вспомогательных метаданных - простой предметы, содержащие дополнительную информацию о содержимое элемента. Атрибуты ДОЛЖНЫ НЕ использовать для квалификации других атрибуты, в которых это могло бы вызвать неоднозначность.
В отличие от элементов атрибуты не могут хранить структурированные данные. По этой причине, элементы являются предпочтительными, поскольку основные держатели информации содержание. Однако, позволяя использовать атрибуты для хранения метаданных о содержимого элемента (например, формат даты, единицы измерения или идентификация набора значений) может сделать документ экземпляра проще и легче понять.
Может быть представлена дата рождения в сообщении:
<DateOfBirth>1975-06-03</DateOfBirth>
Однако может быть больше информации требуется, например, как эта дата рождение было подтверждено. Это должно быть определяется как атрибут, что делает Элемент в сообщении выглядит следующим образом:
<DateOfBirth VerifiedBy="View of Birth Certificate">1975-06-03</DateOfBirth>
Неправильное следующее:
<DateOfBirth VerifiedBy="View of Birth Certificate" ValueSet="ISO 8601" Code="2">1975-06-03</DateOfBirth>
Здесь неясно, является ли Кодекс имеет квалификацию VerifiedBy или Атрибут ValueSet. Более подходящий будет:
<DateOfBirth>
<VerifiedBy Code="2">View of Birth Certificate</VerifiedBy>
<Value ValueSet="ISO 8601">1975-06-03</Value>
</DateOfBirth>
Лично мне нравится использовать атрибуты для простых однозначных свойств. Элементы (очевидно) более подходят для сложных типов или повторяющихся значений.
Для однозначных свойств атрибуты приводят к более компактному XML и более простой адресации в большинстве API-интерфейсов.
В основном это вопрос предпочтения. Я использую Elements для группировки и атрибуты для данных, где это возможно, поскольку я считаю это более компактным, чем альтернатива.
Например, я предпочитаю.....
<?xml version="1.0" encoding="utf-8"?>
<data>
<people>
<person name="Rory" surname="Becker" age="30" />
<person name="Travis" surname="Illig" age="32" />
<person name="Scott" surname="Hanselman" age="34" />
</people>
</data>
... Вместо....
<?xml version="1.0" encoding="utf-8"?>
<data>
<people>
<person>
<name>Rory</name>
<surname>Becker</surname>
<age>30</age>
</person>
<person>
<name>Travis</name>
<surname>Illig</surname>
<age>32</age>
</person>
<person>
<name>Scott</name>
<surname>Hanselman</surname>
<age>34</age>
</person>
</people>
</data>
Однако, если у меня есть данные, которые не могут легко отображаться внутри, например, 20-30 символов или содержат много кавычек или других символов, которые нужно экранировать, я бы сказал, что это время, чтобы разбить элементы... возможно, с блоками CData.
<?xml version="1.0" encoding="utf-8"?>
<data>
<people>
<person name="Rory" surname="Becker" age="30" >
<comment>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</comment>
</person>
<person name="Travis" surname="Illig" age="32" >
<comment>A cool guy for who has helped me out with all sorts of SVn information</comment>
</person>
<person name="Scott" surname="Hanselman" age="34" >
<comment>Scott works for MS and has a great podcast available at http://www.hanselminutes.com </comment>
</person>
</people>
</data>
Как правило, я вообще избегаю атрибутов. Да, атрибуты более компактны, но элементы более гибкие, а гибкость - одно из важнейших преимуществ использования формата данных, такого как XML. Сегодня одно значение может стать завтрашним списком значений.
Кроме того, если все элемент, вы никогда не должны помнить, как вы моделировали какой-либо конкретный бит информации. Не использовать атрибуты означает, что вам нужно меньше думать.
Отметьте Элементы против атрибутов от Ned Batchelder.
Хорошее объяснение и хороший список преимуществ и недостатков элементов и атрибутов.
Он сводит его до:
Рекомендация: Используйте элементы для данных, которые будут созданы или использованы бизнес-приложением, и атрибуты для метаданных.
Важно: см. комментарий @maryisdead ниже для дальнейшего уточнения.
Ограничения на атрибуты говорят вам, где вы можете и не можете их использовать: имена атрибутов должны быть уникальными, их порядок не может быть значительным, и как имя, так и значение могут содержать только текст. Элементы, напротив, могут иметь неповторимые имена, иметь значительный порядок и могут иметь смешанный контент.
Атрибуты можно использовать в доменах, где они отображаются на структуры данных, которые следуют этим правилам: имена и значения свойств объекта, столбцов в строке таблицы, записей в словаре. (Но не если свойства не все типы значений, или записи в словаре не являются строками.)
Мое личное эмпирическое правило: если элемент может содержать только одну из этих вещей, а его атомные данные (id, name, age, type и т.д.), он должен быть атрибутом, иначе элементом.
Я имею тенденцию использовать элементы, когда это данные, которые человеческий читатель должен знать и атрибуты, когда он только для обработки (например, идентификаторы). Это означает, что я редко использую атрибуты, так как большинство данных имеет отношение к моделируемой модели домена.
Вот еще одна стратегия, которая может помочь выделить элементы из атрибутов: подумайте об объектах и помните о MVC.
Объекты могут иметь элементы (объектные переменные) и свойства (члены с сеттерами и геттерами). Свойства очень полезны с дизайном MVC, что позволяет использовать механизм уведомления об изменениях.
Если это принятое направление, атрибуты будут использоваться для внутренних данных приложения, которые пользователь не может изменить; Классическими примерами будут ID или DATE_MODIFIED. Поэтому элементы будут использоваться для данных, которые могут быть изменены пользователями.
Итак, следующее будет иметь смысл, учитывая, что библиотекарь сначала добавляет книгу (или журнал), а затем может редактировать ее имя автора ISBN и т.д.:
<?xml version="1.0" encoding="utf-8"?>
<item id="69" type="book">
<authors count="1">
<author>
<name>John Smith</name>
<author>
</authors>
<ISBN>123456790</ISBN>
</item>