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

Question

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

Пример, который я придумал, по сути, что-то вроде:

<INVENTORY>
   <ITEM serialNumber="something" location="something" barcode="something">
      <TYPE modelNumber="something" vendor="something"/> 
   </ITEM>
</INVENTORY>

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

<INVENTORY>
   <ITEM>
      <SERIALNUMBER>something</SERIALNUMBER>
      <LOCATION>something</LOCATION>
      <BARCODE>something</BARCODE>
      <TYPE>
         <MODELNUMBER>something</MODELNUMBER>
         <VENDOR>something</VENDOR>
      </TYPE>
   </ITEM>
</INVENTORY>

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

После длинного объяснения (извините), как вы определяете, что такое метаданные, и когда вы разрабатываете структуру XML-документа, как вы должны решить, когда использовать атрибут или элемент?

Answer 1

Я использую это правило:

1. Атрибут - это нечто автономное, то есть цвет, идентификатор, имя.
2. Элемент - это то, что имеет или может иметь собственные атрибуты или содержать другие элементы.

Так что ваш близок. Я бы сделал что-то вроде:

РЕДАКТИРОВАТЬ : Обновлен оригинальный пример на основе обратной связи ниже.

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

Answer 2

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

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

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

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

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

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

Answer 3

«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).

Answer 4

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

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

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

<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>

Answer 5

Это может зависеть от вашего использования. 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 наиболее полезен, когда его можно согнуть, не нарушая при этом существующий код.

Answer 6

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

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

Предпочтение отдается атрибутам:

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

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

Если схема XML начинает разрешать ограничение или расширение модели содержимого «все», то я, вероятно, отбросил бы ее

Answer 7

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

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

<foo title="bar"/>;

или

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

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

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

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

Answer 8

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

Answer 9

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

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

Answer 10

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

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

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