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

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

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

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

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

Необязательно ИЗБЕГАТЬ атрибутов любой ценой. Иногда их легче моделировать, чем элементы. Это действительно зависит от данных, которые вы пытаетесь представить.

Мои 0,02 через пять лет после ОП - полная противоположность. Позволь мне объяснить.

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

Считается по-другому:

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

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

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

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

Сравнивать

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

Против

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Отображение модели атрибутов. Набор атрибутов элемента изоморфизируется непосредственно в карту имя / значение, в которой значениями являются текст или любой сериализуемый тип значения. В C #, например, любой объект 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;
}

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

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

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

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

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

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

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

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

attribute="1 2 3 7 20"

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

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

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

Тебе решать.

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

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

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

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

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

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

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

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