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

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

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

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

 Anna Smith  

  female Anna Smith  

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

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

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

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

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

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

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

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

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

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

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

   Tove Jani Reminder Don't forget me this weekend!   Jani Tove Re: Reminder I will not   

Идентификатор выше – это просто идентификатор, чтобы идентифицировать разные заметки. Это не часть самой заметки.

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

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

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

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

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

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

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

    сравнить

      

    против

       John    23    m   

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

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

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

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

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

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

                

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

            

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      value another value a third value  

    Если вы преобразуете это в карту, вы потеряете две вещи: несколько значений, связанных с 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 Schema.

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

     attribute="1 2 3 7 20" 

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

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

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

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

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

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

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

        localhost usrhr jobby consol_hr   /home/anthony/products.adb   

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

    Тебе решать.

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

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

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

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

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

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

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

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

    Interesting Posts

    Как настроить чувствительность к регистру папок в Windows 7?

    Как сделать условную автоматическую проводку весной?

    Как настроить SSH, чтобы он не пытался автоматически загружать все файлы удостоверений?

    Как запустить 2 SSD-накопителя в RAID-0?

    Команды Unix для получения последней измененной даты и размера файла / папки (NOT LS)

    Остановить DropBox для синхронизации рабочего стола Windows при использовании беспроводного соединения

    Как resize шрифта JLabel, чтобы взять максимальный размер

    Объект или сложный тип ” не могут быть сконструированы в запросе LINQ to Entities

    Могу ли я запускать функцию VBA всякий раз, когда вычисляется excel, даже если я не нажимаю F9?

    как программно подделывать событие касания к UIButton?

    Получение идентификатора streamа из streamа

    Можно ли обнаружить предыдущую позицию байта на жестком диске после того, как она была перезаписана?

    Построение объемных данных в MATLAB

    Корневые файлы Rsync между системами без указания пароля

    Добавление файлов в отдельные объекты в Xcode 4

    Давайте будем гением компьютера.