XML-атрибуты vs Элементы

Question

Когда вы должны использовать атрибуты XML и когда использовать XML-элементы?

например.

<customData> 
    <records> 
    <record name="foo" description="bar" /> 
    </records> 
</customData> 

или

<customData> 
    <records> 
    <record> 
     <name>foo</name> 
     <description>bar</description> 
    </record> 
    </records> 
</customData> 

Answer 1

Лично мне нравится, используя атрибуты для простых однозначных свойств. Элементы (очевидно) более подходят для сложных типов или повторяющихся значений.

Для однозначных свойств атрибуты приводят к более компактному XML и более простой адресации в большинстве API.

Answer 2

В основном это вопрос предпочтения. Я использую 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's 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> 

Answer 3

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

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

Answer 4

Один из лучших продуманных элементов против аргументов атрибутов поступает из UK GovTalk guidelines. Это определяет методы моделирования, используемые для правительственных обменов XML, но он стоит на своих собственных достоинствах и заслуживает рассмотрения.

ДОЛЖЕН быть Schemas сконструирован таким образом, что элементов являются основными держателями информационного контента в 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> 

Answer 5

Существует статья под названием «Principles of XML design: When to use elements versus attributes» на веб-сайте IBM.

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

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

редактировать - С сайта:

Принцип основного содержания

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

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

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

Принцип структурированной информации

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

Даты являются хорошим примером: дата имеет фиксированную структуру и, как правило, действует как единый токен, поэтому имеет смысл как атрибут (предпочтительно, выраженный в ISO-8601). С другой стороны, представление личных имен - это случай, когда я видел этот принцип, удивляющий дизайнеров. Я вижу имена в атрибутах много, но я всегда утверждал, что личные имена должны быть в содержании элементов. Личное имя имеет удивительно переменную структуру (в некоторых культурах вы можете вызвать путаницу или оскорбление, опуская почтение или принимая порядок частей имен). Личное имя также редко является атомным токеном. Например, иногда вы можете искать или сортировать по имени, а иногда по фамилии. Я должен указать, что столь же проблематично, чтобы вызывать полное имя в содержимом одного элемента, как и в атрибуте.

Answer 6

Отъезд Elements vs. attributes от Ned Batchelder.

Хорошее объяснение и хороший список преимуществ и недостатков элементов и атрибутов.

Он кипятит его вниз:

Рекомендация: Используйте элементы данных, которые будут производиться или потребленных бизнес-приложения, а также атрибуты метаданных.

Важно: Пожалуйста, см. Комментарий @ maryisdead ниже для уточнения.

Answer 7

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

Answer 8

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

Answer 9

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

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

Answer 10

Мое личное эмпирическое правило: если элемент может содержать только одну из этих вещей, а его атомные данные (id, name, age, type и т. Д.), Он должен быть атрибутом в противном случае элементом.