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

https://stackoverflow.com/questions/33746

09-06-2019
|

Вопрос

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

Решение

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

<Ол>

Атрибут - это нечто автономное, то есть цвет, идентификатор, имя.

Элемент - это то, что имеет или может иметь собственные атрибуты или содержать другие элементы.

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

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

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

Другие советы

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

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

"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 используется не как язык разметки, а как сериализация данных язык, в котором различие между "данными" и "метаданными" более расплывчатое.Таким образом, выбор между элементами и атрибутами более или менее произволен, за исключением вещей, которые не могу быть представленным атрибутами (см. Ответ финстера).

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

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

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

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

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

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

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

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

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

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

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

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

<foo title="bar"/>;

или

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Оба метода хранения свойств объекта абсолютно корректны.Вам следует исходить из прагматических соображений.Попробуйте ответить на следующий вопрос:

Какое представление приводит к более быстрому анализу \ генерации данных?
Какое представление приводит к более быстрой передаче данных?
Имеет ли значение удобочитаемость?

...

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

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

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

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

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

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

Всего несколько исправлений для плохой информации:

@John Ballinger: атрибуты могут содержать любые символьные данные. л &; GT &; & Усилитель; & Quot; 'необходимо экранировать в & amp; lt; & Усилитель, GT; & Усилитель, усилитель; & Amp; Quot; и & amp; соответственно. Если вы используете библиотеку XML, она позаботится об этом за вас.

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

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

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

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

Так, например, текст без разметки всегда принадлежит атрибутам. Всегда.

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

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

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

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

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

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

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

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

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

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

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

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

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

Единственный раз, когда я их использовал, было определение расширения файла URL ресурса:

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

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

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

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow