Атрибут XML по сравнению с элементом XML

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

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

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

Оба метода для хранения свойств объекта совершенно действительны. Необходимо отступить от прагматических соображений. Попытайтесь ответить на следующий вопрос:

1. , Какое представление приводит к более быстрым данным parsing\generation?
2. , Какое представление приводит к более быстрой передаче данных?

3. удобочитаемость имеет значение?

   ...

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

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

Другая точка для поддержки положения - то, что, в то время как другая команда спорит о стиле (в этом большинство инструментов XML обработает документ все-атрибута так же легко как all-#PCDATA документ) Вы обсуждаете практичность. В то время как стиль не может быть полностью проигнорирован, технические достоинства должны нести больше веса.

Используйте элементы для данных и атрибуты для метаданных (данные о данных элемента).

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

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

самый трудный вопрос!

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

более конкретно, можно сделать модель содержания элемента более сложной, но более трудно расширить атрибут.

Когда в сомнении, KISS - почему атрибуты соединения и элементы, когда у Вас нет ясной причины использовать атрибуты. Если Вы позже решаете определить XSD, который закончит тем, что был инструментом для очистки также. Тогда, если Вы еще позже решаете генерировать структуру класса от своего XSD, который будет более простым также.

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

Однако XML использовала, как транспорт сообщения будет часто лучше использовать больше элементов.

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

<INVENTORY>
   <ITEM serialNumber="something" barcode="something">
      <Location>XYX</LOCATION>
      <TYPE modelNumber="something">
         <VENDOR>YYZ</VENDOR>
      </TYPE>
    </ITEM>
</INVENTORY>

Теперь, мы хотим отправить элемент ОБЪЕКТА на устройство для печати его штрихкод однако существует выбор типов кодировки. Как мы представляем требуемый тип кодировки? Внезапно мы понимаем, несколько запоздало, что штрихкод не был единственным значением автомикрометра, а скорее он может быть квалифицирован с кодированием, требуемым, когда распечатано.

   <ITEM serialNumber="something">
      <barcode encoding="Code39">something</barcode>
      <Location>XYX</LOCATION>
      <TYPE modelNumber="something">
         <VENDOR>YYZ</VENDOR>
      </TYPE>
   </ITEM>

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

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

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

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

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

не заканчиваются как это (это не то, как XML должен использоваться):

<note day="12" month="11" year="2002" 
      to="Tove" to2="John" from="Jani" heading="Reminder"  
      body="Don't forget me this weekend!"> 
</note>

Источник: http://www.w3schools.com/xml/xml_dtd_el_vs_attr.asp

Я соглашаюсь с feenster. Держитесь подальше от атрибутов, если Вы можете. Элементы являются эволюцией, дружественной и более совместимой между инструментариями веб-сервиса. Вы никогда не находили бы эти инструментарии, сериализирующие Ваш запрос/ответные сообщения с помощью атрибутов. Это также имеет смысл, так как наши сообщения являются данными (не метаданные) для инструментария веб-сервиса.

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

XHTML - это одна из областей, где атрибуты имеют естественное использование (например, в class = 'foo'). Атрибуты не имеют порядка, и это может облегчить некоторым людям разработку инструментов. Атрибуты OTOH сложнее ввести без схемы. Я также считаю, что атрибуты в пространстве имен (foo: bar = "zork") часто сложнее управлять в различных наборах инструментов. Но взгляните на некоторые языки W3C, чтобы увидеть общую смесь. SVG, XSLT, XSD, MathML - это некоторые примеры хорошо известных языков, и все они имеют богатый набор атрибутов и элементов. Некоторые языки даже позволяют делать это более чем одним способом, например

<foo title="bar"/>;

или

<foo>
  <title>bar</title>;
</foo>;

. Обратите внимание, что они НЕ эквивалентны синтаксически и требуют явной поддержки в инструментах обработки.)

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

Наконец, убедитесь, что вы отличаетесь пространства имен от атрибутов. Некоторые системы XML (например, Linq) представляют пространства имен как атрибуты в API. ИМО, это уродливо и потенциально сбивает с толку.

<foo title="bar"/>;

или

<foo>
  <title>bar</title>;
</foo>;

. Обратите внимание, что они НЕ эквивалентны синтаксически и требуют явной поддержки в инструментах обработки.)

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

Наконец, убедитесь, что вы отличаетесь пространства имен от атрибутов. Некоторые системы XML (например, Linq) представляют пространства имен как атрибуты в API. ИМО, это уродливо и потенциально сбивает с толку.

<foo title="bar"/>;

или

<foo>
  <title>bar</title>;
</foo>;

. Обратите внимание, что они НЕ эквивалентны синтаксически и требуют явной поддержки в инструментах обработки.)

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

Наконец, убедитесь, что вы отличаетесь пространства имен от атрибутов. Некоторые системы XML (например, Linq) представляют пространства имен как атрибуты в API. ИМО, это уродливо и потенциально сбивает с толку.

<foo title="bar"/>;

или

<foo>
  <title>bar</title>;
</foo>;

Обратите внимание, что они НЕ эквивалентны синтаксически и требуют явной поддержки в инструментах обработки)

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

Наконец, убедитесь, что вы отличаете пространства имен от атрибутов. Некоторые системы XML (например, Linq) представляют пространства имен как атрибуты в API. ИМО, это уродливо и потенциально сбивает с толку.

<foo title="bar"/>;

или

<foo>
  <title>bar</title>;
</foo>;

Обратите внимание, что они НЕ эквивалентны синтаксически и требуют явной поддержки в инструментах обработки)

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

Наконец, убедитесь, что вы отличаете пространства имен от атрибутов. Некоторые системы XML (например, Linq) представляют пространства имен как атрибуты в API. ИМО, это уродливо и потенциально сбивает с толку.

Вот пара исправлений некорректной информации:

@John Ballinger: Атрибуты могут содержать любые символьные данные. <> & "'нужно преобразовать в & lt; & gt; & amp; & quot; и & apos; соответственно. Если вы используете XML-библиотеку, она позаботится об этом за вас.

Черт, атрибут может содержать двоичный данные, такие как изображение, если вы действительно хотите, просто закодировав его в base64 и сделав data: URL.

@feenster: Атрибуты могут содержать несколько элементов, разделенных пробелами, в случае IDS или NAMES, которые будут включать Неприятно, но это может привести к экономии места.

Использование атрибутов может сохранить конкуренцию XML с JSON. См. Жирная разметка: миф о сокращении жирной разметки по одной калории за раз .

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

XML не разработан, чтобы быть компактным, но быть переносимым и читаемым человеком. Если вы хотите уменьшить размер передаваемых данных, используйте что-нибудь еще (например, буферы протокола Google ).

«XML» означает «расширяемый язык разметки ». Язык разметки подразумевает, что данные представляют собой текст , размеченный метаданными о структуре или форматировании.

XHTML - это пример XML, используемого таким образом, как он был задуман:

<p><span lang="es">El Jefe</span> insists that you
    <em class="urgent">MUST</em> complete your project by Friday.</p>

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

Путаница возникает, когда XML используется не как язык разметки, а как язык сериализации данных , в котором различие между «данными» и «метаданными» более расплывчато. Таким образом, выбор между элементами и атрибутами является более или менее произвольным, за исключением вещей, которые не могут быть представлены атрибутами (см. Ответ Feenster).