Який вибрати: атрибут XML або підвузл?


15

Ми хочемо експортувати деякі дані з нашої бази даних у вигляді XML. Наприклад, Personможе бути age, nameі деякі інші властивості.

У нас є два варіанти визначення формату XML.

Вибір №1:

<Persons>
   <Person>
       <Age>16</Age>
       <Name>Richard</Name>
   </Person>
   <Person>
       <Age>34</Age>
       <Name>Eric</Name>
   </Person>
   ...
</Persons>

Вибір №2:

<Persons>
   <Person Age="16" Name="Richard"/>
   <Person Age="34" Name="Eric"/>
   ...
</Persons>

То яка різниця між визначенням підвузла чи атрибута? І яка користь від кожного вибору?



2
Хоча це було запитано на Stack Overflow у 2008 році , це, здається, є дизайнерським рішенням і тут є темою.
Томас Оуенс

Відповіді:


9

Для цього немає чіткої документації / найкращої практики, але врахуйте альтернативи, як у вас є:

Як текст елемента:

  • може бути простіше відображати дані як xhtml тощо, де текстовий вміст вважається текстовим, а не розміткою чи метаданими.
  • їх може бути більше одного. Якщо вам потрібен вміст для дітей із кількома рядами віків чи імен, атрибути цього не дозволять
  • якщо вам потрібні метадані на рівні рядків, у вас є можливість використовувати атрибути <name>або <age>для цієї мети

Як атрибути:

  • XML є більш компактним
  • XSLT і DocTypes простіші у визначенні
  • вам не потрібно турбуватися про пробіли (оббивка, відступ, розриви рядків) або інші елементи, які можна вводити (коментарі, ІР) в області PCDATA (текст елемента)
  • може бути лише один! вам не доведеться турбуватися про дочірній вміст, що містить кілька ageатрибутів.

Я витратив багато часу на роботу з XML, і, на мою думку, для чистого зв’язку даних, атрибути слід використовувати, коли це можливо. Якщо XML, ймовірно, буде використовуватися для презентації (XSLT, xhtml тощо), то він може бути кращим як текстовий вміст (але не обов'язково).


2
Нічого не варто: якщо ви збираєтесь використовувати XSLT, буквально немає причин НЕ використовувати атрибути. Можливо, якщо ви збираєтеся робити якусь річ XML + CSS, або збираєтесь використовувати чужий XSLT ...
DougM

Я додав деякі моменти, щоб зробити вашу гарну відповідь трохи більш врівноваженою, сподіваюся, ви згодні, що це покращує її.
Док Браун

9

Принципи дизайну XML: Коли використовувати елементи проти атрибутів Uche Ogbuji від IBM, мабуть, один з найкращих ресурсів у цьому питанні.

В основі рішення лежить те, що атрибути - це "зроблені" речі. Ви не можете їх змінити чи змінити чи вкласти. Вони впорядковані незалежно і відрізняються всередині елемента (у вас не може бути двох однакових речей).

Якщо будь-яке з цих обмежень може змінитись, зробіть дані дочірнім вузлом XML.

У вашому прикладі є людина, яка має ім’я та вік. У мене є ім’я, середнє та прізвище ... і прізвисько. А деякі люди мають дівочі імена, численні середні імена або почесні імена - як би ви включили Джона Рональда Реуеля Толкіна до такої структури?

І тому у нас є хтось, хто має два прізвища, які мають наказ на них. Це має чітко показувати, що ні, атрибут не найкращий вибір для цього.

Зараз я не можу його знайти, але у вищезгаданому зв'язаному документі є твердження, що імена - це речі, які потребують трохи роздумів, що призводить до "Я сподіваюсь розширити питання щодо імен людей у ​​розмітці в майбутній статті". Якщо хтось має на це посилання, залиште коментар або відредагуйте його у цьому місці.

З іншого боку, вік - це щось, що має досить фіксовану структуру (я б запропонував день народження, а не ціле число). Таким чином, представлення цієї інформації у відомому та зрозумілому форматі має сенс в атрибуті. У людини є один, і лише один день народження, і немає «замовлення», яке ви хочете зберегти.

Uche Ogbuji визначає три основні принципи при правильному проектуванні формату xml. Далі наведені скорочені цитати з вищезгаданого зв'язаного документа.

  • Принцип структурованої інформації
    Якщо інформація виражена в структурованій формі, особливо якщо структура може бути розширюваною, використовуйте елементи. З іншого боку: Якщо інформація виражається як атомний маркер, використовуйте атрибути
  • Принцип читабельності
    Якщо інформація призначена для прочитання та розуміння людиною, використовуйте елементи. Якщо інформація найбільш зрозуміла і засвоюється машиною, використовуйте атрибути.
  • Принцип зв’язування елемента / атрибута
    Використовуйте елемент, якщо вам потрібно змінити його значення іншим атрибутом

І так, імена мають бути елементами - це структуровані дані, які не є атомним маркером, вони швидше читаються людиною, ніж комп'ютер, і вони можуть бути змінені іншим атрибутом самого імені.

Дати повинні бути атрибутами - це дані, що є атомним маркером, вони швидше за все читаються комп'ютером, ніж людиною (а потім перетворюються у бажаний для людини формат, якщо потрібно ), і нарешті, навряд чи вони будуть змінені іншими атрибути на них.


2

Ще один розгляд між ролльф - це кількість полів.
Більше невеликої кількості атрибутів стає безладом і важко читати (це передбачає, що ви хочете, щоб ваш xml був читабельним для людей, але як програміст ви хочете зробити це для тестування хоча б).

Крім того, якщо ви очікуєте, що структура даних одного з полів зміниться з часом, не робіть це атрибутом.
Наприклад, поле вашого імені. Можливо, у майбутньому це стане

<name>
  <firstName>George</firstName>
  <lastName>Orwell</lastName>
  <maidenName></maidenName>
  <nickName>Robert</nickName>
</name>

Якщо ви очікуєте, що щось подібне відбудеться, перетворення його на атрибут означатиме пізніше код рефакторингу.


дякую за цей гарний момент. І чому "зробити його атрибутом означає пізніше рефакторинг код"?
ZijingWu

2

Для тегів Persons нормально мати більше тегів Person, це має сенс, у списку Persons є деякі сутності, а не атрибути.

Історія для людини та її складових різна. Особа не містить імені, це атрибут Особи, тому я б дотримувався атрибутів замість нових тегів. Теги корисні, коли у вас є повторювані речі, такі як адреси, ви не можете робити це з атрибутами.

Якщо ми думаємо в контексті HTML, у вас немає вводу з тегом імені зі значенням, чи не так?

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.