Должен ли я использовать элементы или атрибуты в XML?

Я узнаю Атрибуты XML из W3Schools.

Автор упоминает следующее (основное внимание):

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

<person sex="female">
  <firstname>Anna</firstname>
  <lastname>Smith</lastname>
</person>

<person>
  <sex>female</sex>
  <firstname>Anna</firstname>
  <lastname>Smith</lastname>
</person>

В первом примере секс является атрибутом. В последнем случае секс является элементом. Оба примера предоставляют ту же информацию.

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

Избегать атрибутов XML?

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

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

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

Итак, мнение автора является известным, или это лучшая практика в XML?

Следует ли избегать атрибутов в XML?

W3Schools также упомянули следующее (выделение мое):

Атрибуты XML для метаданных

Иногда идентификационные ссылки присваиваются элементам. Эти идентификаторы могут использоваться для идентификации элементов XML во многом аналогично атрибуту ID в HTML. Этот пример демонстрирует это:

<messages>
  <note id="501">
    <to>Tove</to>
    <from>Jani</from>
    <heading>Reminder</heading>
    <body>Don't forget me this weekend!</body>
  </note>
  <note id="502">
    <to>Jani</to>
    <from>Tove</from>
    <heading>Re: Reminder</heading>
    <body>I will not</body>
  </note>
</messages>

Идентификатор выше - это просто идентификатор для идентификации различных заметок. Это не часть самой заметки.

Я хочу сказать, что метаданные (данные о данных) должны храниться как атрибуты, а сами данные должны храниться как элементы.

Ответ 1

Использование атрибутов или элементов обычно определяется данными, которые вы пытаетесь моделировать.

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

Теперь, если вы хотите передать METADATA данные (что-то, что предоставляет дополнительную информацию о данных), но на самом деле не является частью данных, тогда лучше сделать его атрибутом. Например, можно сказать, что у каждого сотрудника есть GUID, необходимый для обработки задним концом, а затем лучше сделать его атрибутом (GUID - это не то, что передает действительно полезную информацию кому-то, кто смотрит на xml, но может быть необходим для других целей)

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

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

Ответ 2

Не менее важно то, что вложение атрибутов в атрибуты делает менее подробный XML.

Сравнение

<person name="John" age="23" sex="m"/>

против

<person>
    <name>
        John
    </name>
    <age>
        <years>
            23
        </years>
    </age>
    <sex>
        m
    </sex>
</person>

Да, это было немного предвзято и преувеличено, но вы поняли, что

Ответ 3

Мои 0.02 через пять лет после OP - это полная противоположность. Позволь мне объяснить.

  • Используйте элементы, когда вы группируете подобные данные, и атрибуты это данные.
  • Не используйте элементы для всего.
  • Если данные повторяются (от 1 до многих), это, вероятно, элемент
  • Если данные никогда не повторяются и имеют смысл только при корреляции с что-то еще, это атрибут.
  • Если данные не имеют других атрибутов (например, имя), то это атрибут
  • Групповые элементы вместе для поддержки анализа парсеров (например,/xml/character)
  • Повторно использовать похожие имена элементов для поддержки анализа данных
  • Никогда, никогда, используйте номера в именах элементов для отображения позиции. (т.е. character1, character2). Эта практика очень усложняет процесс синтаксического анализа (см. № 6, код синтаксического анализа must/character1,/character2 и т.д. не просто/символ.

С другой стороны:

  • Начните с определения всех ваших данных как атрибута.
  • Логически группировать атрибуты в элементы. Если вы знаете свои данные, вам редко нужно преобразовать атрибут в элемент. Вероятно, вы уже знаете, когда необходим элемент (сбор или повторные данные)
  • Элементы группы вместе логически
  • Когда вы сталкиваетесь с ситуацией, вам нужно развернуть, добавить новые элементы/атрибуты на основе логической структуры, описанный выше. Добавление новой коллекции дочерних элементов не "сломает" ваш дизайн, а со временем будет легче читать.

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

    <book title='Hitchhiker&apos;s Guide to the Galaxy' author='Douglas Adams'>
        <character name='Zaphod Beeblebrox' age='100'/>
        <character name='Arthur Dent' age='42'/>
        <character name='Ford Prefect' age='182'/>
    </book>

    <book title='On the Road' author='Jack Kerouac'>
        <character name='Dean Moriarty' age='30'/>
        <character name='Old Bull Lee' age='42'/>
        <character name='Sal Paradise' age='42'/>
    </book>

Можно утверждать, что книга может иметь несколько авторов. ОК, просто добавьте новые элементы автора (необязательно удалите оригинальный @author). Конечно, вы нарушили первоначальную структуру, но на практике это довольно редко и легко работать. Любой пользователь вашего исходного XML, который принял одного автора, все равно должен измениться (они, скорее всего, меняют свою БД, чтобы переместить автора из столбца в таблице "книга" в таблицу "автора" ).

<book title='Hitchhiker&apos;s Guide to the Galaxy'>
    <author name='Douglas Adams'/>
    <author name='Some Other Guy'/>
    <character name='Zaphod Beeblebrox' age='100'/>
    <character name='Arthur Dent' age='42'>
    <character name='Ford Prefect' age='182'/>
</book>

Ответ 4

Я использовал Google для поиска точного вопроса. Сначала я приземлился на эту статью, http://www.ibm.com/developerworks/library/x-eleatt/index.html. Хотя, это было слишком долго для простого вопроса как такового. Во всяком случае, я прочитал все ответы на эту тему и не нашел удовлетворительного резюме. Таким образом, я вернулся к последней статье. Вот резюме:

Когда я использую элементы и когда я использую атрибуты для представления бит информации?

  • Если информация, о которой идет речь, сама может быть помечена элементами, поместите ее в элемент.
  • Если информация подходит для формы атрибута, но может оказаться как несколько атрибутов одного и того же имени в одном и том же элементе, вместо этого используйте дочерние элементы.
  • Если информация должна быть в стандартном типе типа DTD-типа, таком как ID, IDREF или ENTITY, используйте атрибут.
  • Если информация не должна быть нормализована для пробела, используйте элементы. (Процессоры XML нормализуют атрибуты способами, которые могут изменить исходный текст значения атрибута.)

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

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

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

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

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

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

Принцип привязки элемента/атрибута

Используйте элемент, если вам нужно его значение для изменения другим атрибут. [..] почти всегда ужасная идея, чтобы один атрибут изменил другой.

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

Ответ 5

Отображение модели атрибутов. Набор атрибутов элемента изоморфен непосредственно на карте имени/значения, в которой значения представляют собой текст или любой тип сериализуемого значения. В С#, например, любой объект Dictionary<string, string> может быть представлен как список атрибутов XML и наоборот.

Это не относится к элементам. Хотя вы всегда можете преобразовать карту имени/значения в набор элементов, обратное не так, например:

<map>
   <key1>value</key1>
   <key1>another value</key1>
   <key2>a third value</key2>
</map>

Если вы преобразуете это в карту, вы потеряете две вещи: несколько значений, связанных с key1, и тот факт, что key1 появляется перед key2.

Значение этого становится намного яснее, если вы посмотрите на код DOM, который использовался для обновления информации в таком формате. Например, тривиально написать это:

foreach (string key in map.Keys)
{
   mapElement.SetAttribute(key, map[key]);
}

Этот код является кратким и недвусмысленным. Контрастируйте это, скажем:

foreach (string key in map.Keys)
{
   keyElement = mapElement.SelectSingleNode(key);
   if (keyElement == null)
   {
      keyElement = mapElement.OwnerDocument.CreateElement(key);
      mapElement.AppendChild(keyElement);
   }
   keyElement.InnerText = value;
}

Ответ 6

Все зависит от того, для чего используется XML. Когда он в основном взаимодействует между программным обеспечением и машинами (например, веб-службами), проще всего использовать все элементы, если только для согласованности (а также некоторые структуры предпочитают его таким образом, например WCF). Если он предназначен для потребления человеком, то есть в первую очередь создан и/или читается людьми, то разумное использование атрибутов может улучшить удобочитаемость довольно много; XHTML - разумный пример этого, а также XSLT и XML Schema.

Ответ 7

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

attribute="1 2 3 7 20"

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

Один сценарий, в котором вы можете запрограммировать предпочтение атрибутов, - это скорость обработки с помощью анализатора SAX. Используя синтаксический анализатор SAX, вы получите обратный вызов элемента, содержащий имя элемента и список атрибутов. Если вы использовали несколько элементов вместо этого, вы получите несколько обратных вызовов (по одному для каждого элемента). Сколько из бремени, разумеется, это для дискуссий, конечно, но, возможно, стоит рассмотреть.

Ответ 8

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

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

Ответ 9

Это пример, где атрибуты - данные о данных.

Базы данных называются их атрибутом ID.

Атрибут "type" базы данных означает, что ожидается в теге базы данных.

  <databases>

      <database id='human_resources' type='mysql'>
        <host>localhost</host>
        <user>usrhr</user>
        <pass>jobby</pass>
        <name>consol_hr</name>
      </database>

      <database id='products' type='my_bespoke'>
        <filename>/home/anthony/products.adb</filename>
      </database>

  </databases>

Ответ 10

Пункты автора верны (за исключением того, что атрибуты могут содержать список значений). Вопрос в том, заботитесь ли вы о его пунктах.

Это вам.

Ответ 11

Вероятно, вы можете увидеть проблему семантическим способом.

Если данные более тесно связаны с элементом, это будет атрибут.

i.e: идентификатор элемента, я бы поставил его как атрибут элемента.

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

Все зависит от вас и от того, как вы разрабатываете свою схему.

Ответ 12

Это из-за такого мусора, что вам следует избегать w3schools. Во всяком случае, это еще хуже, чем ужасные вещи, которые у них есть о JavaScript.

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

Ответ 13

Здесь еще одна вещь, которую следует учитывать при выборе формата XML: если я правильно помню, значения атрибутов "id" не должны быть все числовыми, они должны соответствовать правилам имен в XML. И, конечно, ценности должны быть уникальными. У меня есть проект, который должен обрабатывать файлы, которые не соответствуют этим требованиям (хотя они являются чистым XML в других отношениях), что сделало обработку файлов более запутанной.