Атрибуты XML и элементы

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

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

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

редактировать - С сайта:

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

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

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

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

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

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

Хорошим примером являются даты: дата имеет фиксированную структуру и обычно действует как отдельный токен, поэтому имеет смысл в качестве атрибута (предпочтительно выраженного в ISO-8601). С другой стороны, представление личных имен - это тот случай, когда я видел, как этот принцип удивляет дизайнеров. Я часто вижу имена в атрибутах, но я всегда утверждал, что личные имена должны быть в содержании элемента. Личное имя имеет удивительно изменчивую структуру (в некоторых культурах вы можете вызвать путаницу или оскорбление, опуская почетные знаки или предполагая порядок частей имен). Личное имя также редко бывает атомным токеном. Например, иногда вам может потребоваться поиск или сортировка по имени, а иногда и по фамилии. Я должен отметить, что втиснуть полное имя в содержание отдельного элемента так же проблематично, как и поместить его в атрибут.

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

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

Один из наиболее продуманных аргументов «элемент против атрибута» - это Руководство UK GovTalk. Это определяет методы моделирования, используемые для правительственного обмена XML, но он стоит сам по себе и заслуживает рассмотрения.

Схемы ДОЛЖНЫ быть разработаны таким образом, чтобы элементы были основными держателями информационного содержимого в экземплярах XML. Атрибуты больше подходят для хранения вспомогательных метаданных - простых элементов, дающих больше информации о содержимом элемента. Атрибуты НЕ ДОЛЖНЫ использоваться для определения других атрибутов, если это может вызвать двусмысленность.

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

Дата рождения может быть представлена ​​в сообщении как:

 <DateOfBirth>1975-06-03</DateOfBirth> 

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

<DateOfBirth VerifiedBy="View of Birth Certificate">1975-06-03</DateOfBirth> 

Следующее было бы неуместным:

<DateOfBirth VerifiedBy="View of Birth Certificate" ValueSet="ISO 8601" Code="2">1975-06-03</DateOfBirth>   

Здесь неясно, квалифицирует ли Код атрибут VerifiedBy или ValueSet. Более подходящее исполнение было бы:

 <DateOfBirth>    
   <VerifiedBy Code="2">View of Birth Certificate</VerifiedBy>     
   <Value ValueSet="ISO 8601">1975-06-03</Value>
 </DateOfBirth>

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

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

<?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. То, что сегодня является единственной ценностью, завтра может стать списком ценностей.

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

Ознакомьтесь с Элементами и атрибутами Неда Батчелдера.

Хорошее объяснение и хороший список преимуществ и недостатков элементов и атрибутов.

Он сводит это к следующему:

Рекомендация: используйте элементы для данных, которые будут создаваться или потребляться бизнес-приложением, и атрибуты для метаданных.

Важно: см. Комментарий @ maryisdead ниже для дальнейших разъяснений.

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

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

Мое личное эмпирическое правило: если элемент может содержать только одно из этих элементов и его атомарные данные (идентификатор, имя, возраст, тип и т. Д.), Он должен быть атрибутом, иначе - элементом.

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

Вот еще одна стратегия, которая может помочь отличить элементы от атрибутов: думать об объектах и ​​помнить о MVC.

Объекты могут иметь члены (объектные переменные) и свойства (члены с установщиками и получателями). Свойства очень полезны в дизайне MVC, обеспечивая механизм уведомления об изменениях.

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

Таким образом, следующее будет иметь смысл, учитывая, что библиотекарь сначала добавляет элемент книги (или журнал), а затем может редактировать его имя ISBN автора и т. Д.:

<?xml version="1.0" encoding="utf-8"?>
<item id="69" type="book">
    <authors count="1">
        <author>
            <name>John Smith</name>
        <author>
    </authors>
    <ISBN>123456790</ISBN>
</item>