Атрибут XML против элемента XML

Некоторые из проблем с атрибутами:

• атрибуты не могут содержать несколько значений (дочерние элементы могут)
• атрибуты не просто расширяемы (для будущих изменений)
• атрибуты не могут описывать структуры (дочерние элементы могут)
• атрибуты сложнее манипулировать программным кодом Значения атрибутов
• нелегко протестировать против DTD

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

Не заканчивайте так (это не то, как следует использовать XML):

<note day="12" month="11" year="2002" 
      to="Tove" from="Jani" heading="Reminder"  
      body="Don't forget me this weekend!"> 
</note>

Источник: http://www.w3schools.com/xml/xml_dtd_el_vs_attr.asp

"XML" означает "расширяемый язык разметки". Язык разметки подразумевает, что данные представляют собой текст, помеченный метаданными о структуре или форматировании.

XHTML - пример XML, используемый так, как он был предназначен:

<p><span lang="es">El Jefe</span> insists that you
    <em class="urgent">MUST</em> complete your project by Friday.</p>

Здесь различается различие между элементами и атрибутами. Текстовые элементы отображаются в браузере, а атрибуты - инструкции о том, как их отображать (хотя есть несколько тегов, которые не работают таким образом).

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

XML Element vs XML Attribute

XML - это соглашение. Сначала отложите все существующие схемы XML или установленные соглашения в рамках вашего сообщества или отрасли.

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

<versus>
  <element attribute="Meta content">
    Content
  </element>
  <element attribute="Flat">
    <parent>
      <child>Hierarchical</child>
    </parent>
  </element>
  <element attribute="Unordered">
    <ol>
      <li>Has</li>
      <li>order</li>
    </ol>
  </element>
  <element attribute="Must copy to reuse">
    Can reference to re-use
  </element>
  <element attribute="For software">
    For humans
  </element>
  <element attribute="Extreme use leads to micro-parsing">
    Extreme use leads to document bloat
  </element>
  <element attribute="Unique names">
    Unique or non-unique names
  </element>
  <element attribute="SAX parse: read first">
    SAX parse: read later
  </element>
  <element attribute="DTD: default value">
    DTD: no default value
  </element>
</versus>

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

Однако XML, используемый в качестве транспорта сообщений, часто лучше использовать большее количество элементов.

Например, скажем, что у нас был этот XML, как предлагается в ответе: -

<INVENTORY>
   <ITEM serialNumber="something" barcode="something">
      <Location>XYX</LOCATION>
      <TYPE modelNumber="something">
         <VENDOR>YYZ</VENDOR>
      </TYPE>
    </ITEM>
</INVENTORY>

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

   <ITEM serialNumber="something">
      <barcode encoding="Code39">something</barcode>
      <Location>XYX</LOCATION>
      <TYPE modelNumber="something">
         <VENDOR>YYZ</VENDOR>
      </TYPE>
   </ITEM>

Дело в том, что если вы не строите какой-либо XSD или DTD вместе с пространством имен, чтобы исправить структуру в камне, вам может быть лучше всего оставить свои варианты открытыми.

IMO XML наиболее полезен, когда его можно сгибать, не нарушая при этом существующий код.

В моей схеме я использую следующие рекомендации в отношении атрибутов и элементов:

• Использовать элементы для длинного текста (обычно это строки или normalizedString)
• Не используйте атрибут, если есть группировка из двух значений (например, eventStartDate и eventEndDate) для элемента. В предыдущем примере, должен быть новый элемент для "события", который может содержать startDate и endDate.
• Дата, дата и время (например, подсчеты, сумма и ставка) должны быть элементы.
• Элементы, не относящиеся к бизнес-периодам, такие как последнее обновление, атрибуты.
• Некоммерческие номера, такие как хэш-коды и индексы, должны быть атрибутами. * Используйте элементы, если тип будет сложным.
• Использовать атрибуты, если значение является простым типом и не повторяется.
• xml: id и xml: lang должны быть атрибутами, ссылающимися на схему XML
• При необходимости технически возможны атрибуты.

Предпочтение атрибутов заключается в следующем:

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

Я добавил, когда технически возможно, потому что бывают случаи, когда использование атрибутов невозможно. Например, выбор набора атрибутов. Например использование (startDate и endDate) xor (startTS и endTS) невозможно с текущим языком схемы

Если XML Schema начинает разрешать ограниченную или расширенную модель контента "все", я бы, вероятно, сбросил ее

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

XHTML - это одна область, где атрибуты имеют естественное использование (например, в class= 'foo'). Атрибуты не имеют порядка, и это может облегчить для некоторых людей разработку инструментов. Атрибуты OTOH сложнее вводить без схемы. Я также нахожу атрибуты с именами (foo: bar = "zork" ), которые зачастую сложнее управлять в различных наборах инструментов. Но посмотрите на некоторые из языков W3C, чтобы увидеть смесь, которая является общей. SVG, XSLT, XSD, MathML - некоторые примеры хорошо известных языков, и все они имеют богатый запас атрибутов и элементов. Некоторые языки даже допускают больше, чем один способ, например,

<foo title="bar"/>;

или

<foo>
  <title>bar</title>;
</foo>;

Обратите внимание, что они НЕ эквивалентны синтаксически и требуют явной поддержки в инструментах обработки)

Моим советом было бы взглянуть на обычную практику в ближайшей к вашей области, а также рассмотреть, какие инструменты вы можете применить.

Наконец, убедитесь, что вы различаете пространства имен из атрибутов. Некоторые XML-системы (например, Linq) представляют пространства имен в качестве атрибутов API. ИМО это уродливое и потенциально запутанное.

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

Как насчет того, чтобы использовать нашу интуицию, ориентированную на твердую заработную плату? Обычно я считаю, что прямо думать о том, что является объектом и является атрибутом объекта или объекта, на который он ссылается.

Каким бы интуитивно не было смысла, поскольку объекты должны вписываться в элементы. Его атрибуты (или свойства) будут атрибутами для этих элементов в xml или дочернем элементе с атрибутом.

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

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

XML не предназначен для компактности, но для переносимости и чтения человеком. Если вы хотите уменьшить размер данных в пути, используйте другое (например, буферы протокола Google).

Использовать элементы для данных и атрибутов для метаданных (данные о данных элемента).

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

Помните, что XML должен быть машиносчитываемым, не читаемым человеком, а для больших документов XML сжимается очень хорошо.

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

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

Еще один момент, чтобы укрепить вашу позицию, заключается в том, что в то время как другая команда спорит о стиле (в том, что большинство инструментов XML будут обрабатывать полностью атрибутный документ так же просто, как и документ all-# PCDATA), вы утверждаете практичность. Хотя стиль не может быть полностью проигнорирован, технические достоинства должны нести больше веса.

вопрос в миллион долларов!

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

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

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

XML-схема, написанная таким образом, краткая.

Всякий раз, когда я вижу такие случаи, как <car><make>Ford</make><color>Red</color></car>, я думаю себе: "Неужели автор подумал, что в элементе make будут элементы?" <car make="Ford" color="Red" /> значительно читаем, нет вопросов о том, как обрабатывать пробелы и т.д.

Учитывая только правила обработки пробелов, я считаю, что это было четкое намерение разработчиков XML.

Это очень ясно в HTML, где различия между атрибутами и разметкой можно четко увидеть:

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

Если у вас есть только чистые данные в виде XML, то есть менее четкое различие. Данные могут стоять между разметкой или атрибутами.

= > Большинство данных должны стоять между разметкой.

Если вы хотите использовать атрибуты здесь: вы можете разделить данные на две категории: данные и "метаданные", где метаданные не являются частью записи, которую вы хотите представить, но такие вещи, как "формат версии", дата создания "и т.д.

<customer format="">
     <name></name>
     ...
</customer>

Можно также сказать: "Использовать атрибуты для характеристики тега, использовать теги для предоставления самих данных".

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

Только время, которое я когда-либо использовал, это определить расширение файла URL-адреса ресурса:

<image type="gif">wank.jpg</image> ...etc etc

Я думаю, если вы знаете 100%, атрибут не нужно будет расширять, вы можете их использовать, но сколько раз вы это знаете.

<image>
  <url>wank.jpg</url>
  <fileType>gif</fileType>
</image>

Всего несколько поправок на какую-то плохую информацию:

@John Ballinger: Attributies могут содержать любые символьные данные. < > и "" должны быть экранированы соответственно && "". Если вы используете библиотеку XML, это позаботится об этом для вас.

Ад, атрибут может содержать двоичные данные, такие как изображение, если вы действительно хотите, просто с помощью base64-кодирования и создания его URL-адреса данных.

@feenster: Атрибуты могут содержать отдельные элементы, разделенные пробелами, в случае IDS или NAMES, которые будут включать числа. Nitpicky, но это может привести к экономии места.

Использование атрибутов может поддерживать совместимость XML с JSON. См. Толстая разметка: обрезка толщины размножения мифа одной калорией за раз.

Я согласен с feenster. Держитесь подальше от атрибутов, если сможете. Элементы являются дружественными к эволюции и более совместимыми между инструментариями веб-сервисов. Вы никогда не найдете эти инструментальные средства для сериализации ваших сообщений запроса/ответа с использованием атрибутов. Это также имеет смысл, поскольку наши сообщения - это данные (а не метаданные) для инструментария веб-сервисов.