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

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

сравнить

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

против

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

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

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

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

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

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

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

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

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

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

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

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

принцип читабельности

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

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

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

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

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

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

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

attribute="1 2 3 7 20"

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

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

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

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

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

базы данных называются по их атрибуту 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>

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

Это зависит от вас.

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

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

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

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

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

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

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

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