Który wybrać: atrybut XML lub węzeł podrzędny?

Chcemy wyeksportować niektóre dane z naszej bazy danych jako XML. Na przykład, Personmoże mieć age, namea niektóre inne właściwości.

Mamy dwie możliwości zdefiniowania formatu XML.

Wybór nr 1:

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

Wybór nr 2:

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

Jaka jest zatem różnica między definicją podwęzła lub atrybutu? A jaka jest korzyść z każdego wyboru?

Nie ma na to jasnej dokumentacji / najlepszych praktyk, ale rozważ alternatywy, ponieważ masz:

Jako tekst elementu:

• może być łatwiej wyświetlać dane jako xhtml itp., w których treść jest uważana za tekst, a nie za znaczniki lub metadane.
• może być więcej niż jeden. Jeśli potrzebujesz treści podrzędnych z wieloma wierszami wieku lub imienia, atrybuty na to nie pozwalają
• jeśli potrzebujesz metadanych na poziomie wiersza, możesz użyć atrybutów <name>lub <age>w tym celu

Jako atrybuty:

• XML jest bardziej kompaktowy
• XSLT i DocTypes są prostsze do określenia
• nie musisz się martwić o białe znaki (wypełnienie, wcięcie, podział wiersza) lub inne elementy, które można wprowadzić (komentarze, PI) w obszarach PCDATA (tekst elementu)
• może być tylko jeden! nie musisz się martwić o treści potomne zawierające wiele ageatrybutów.

Spędziłem dużo czasu pracując z XML i, moim zdaniem, do czystej komunikacji danych, atrybuty powinny być używane, gdy tylko jest to możliwe. Jeśli XML może być używany do prezentacji (XSLT, xhtml itp.), Może być lepszy jako treść tekstowa (ale niekoniecznie).

Zasady projektowania XML: kiedy używać elementów kontra atrybuty Uche Ogbuji z IBM jest prawdopodobnie jednym z najlepszych zasobów w tej sprawie.

U podstaw tej decyzji leży to, że atrybuty są „zrobione”. Nie możesz ich zmienić, zmodyfikować ani zagnieździć. Są one niezależne i odrębne w obrębie elementu (nie możesz mieć dwóch tego samego).

Jeśli którekolwiek z tych ograniczeń mogą ulec zmianie, uczyń dane węzłem potomnym kodu XML.

W twoim przykładzie masz osobę, która ma imię i wiek. Mam imię, środkowe i nazwisko ... i pseudonim. A niektórzy ludzie mają nazwiska panieńskie, wiele drugich imion lub honorykę - jak byś włożył Johna Ronalda Reuela Tolkiena w takiej strukturze?

Mamy więc kogoś, kto ma dwa drugie imiona, które mają do nich rozkaz. Powinno to wyraźnie wskazywać, że nie, atrybut nie jest najlepszym wyborem.

_{Obecnie nie mogę go znaleźć, ale w powyższym połączonym dokumencie znajduje się stwierdzenie, że imiona są rzeczami, które wymagają zastanowienia, prowadząc do „Mam nadzieję rozszerzyć sposób traktowania nazwisk ludzi w znacznikach w przyszłym artykule”. Jeśli ktoś ma na to temat, zostaw komentarz lub edytuj go w tym miejscu.}

Z drugiej strony wiek jest czymś, co ma raczej stałą strukturę (sugerowałbym urodziny, a nie liczbę całkowitą). Jako takie, przedstawienie tej informacji w dobrze znanym i zrozumiałym formacie ma sens w atrybucie. Osoba ma jedno i tylko jedno urodziny i nie ma „zamówienia”, które chcesz zachować.

Uche Ogbuji identyfikuje trzy podstawowe zasady prawidłowego projektowania formatu xml. Poniżej znajdują się skrócone cytaty z powyższego połączonego dokumentu.

• Zasada ustrukturyzowanej informacji
  Jeśli informacje są wyrażone w ustrukturyzowanej formie, szczególnie jeśli struktura może być rozszerzalna, użyj elementów. Z drugiej strony: jeśli informacja jest wyrażona jako token atomowy, użyj atrybutów
• Zasada czytelności
  Jeśli informacje mają być przeczytane i zrozumiane przez osobę, należy użyć elementów. Jeśli informacje są najłatwiej zrozumiałe i przetworzone przez maszynę, użyj atrybutów.
• Zasada wiązania elementu / atrybutu
  Użyj elementu, jeśli chcesz zmodyfikować jego wartość innym atrybutem

I tak, nazwy powinny zawierać elementy - są to ustrukturyzowane dane, które nie są tokenem atomowym, są bardziej prawdopodobne, że zostaną odczytane przez człowieka niż komputer i mogą zostać zmodyfikowane przez inny atrybut samej nazwy.

Daty powinny być atrybutami - są to dane, które są tokenem atomowym, są bardziej prawdopodobne, że są odczytywane przez komputer niż człowiek (a następnie przekształcane w preferowany format człowieka, jeśli to konieczne ), a na koniec jest mało prawdopodobne, aby zostały zmodyfikowane przez inne atrybuty na nich.

Kolejną kwestią, jaką należy wziąć pod uwagę przy rolfl, jest liczba pól.
Więcej niż niewielka liczba atrybutów staje się bałaganem i trudnym do odczytania (zakładając, że chcesz, aby twój xml był czytelny dla ludzi, ale jako programista będziesz chciał to zrobić przynajmniej w celu przetestowania).

Ponadto, jeśli oczekujesz, że struktura danych jednego pola zmieni się w czasie, nie rób z tego atrybutu.
Na przykład twoje imię i nazwisko. Może w przyszłości tak się stanie

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

Jeśli spodziewasz się, że coś takiego się wydarzy, uczynienie go atrybutem oznaczałoby później więcej refaktoryzacji kodu.

W przypadku znacznika Persons normalne jest posiadanie większej liczby znaczników Person, ma to sens, lista Osób ma pewne byty, a nie atrybuty.

Historia jest inna w przypadku Osoby i jej elementów. Osoba nie zawiera imienia, nazwa jest atrybutem Osoby, więc trzymałbym się atrybutów zamiast nowych tagów. Tagi są przydatne, gdy masz powtarzające się rzeczy, takie jak Adresy, nie możesz tego zrobić z atrybutami.

Jeśli myślimy w kontekście HTML, nie masz danych wejściowych ze znacznikiem nazwy o wartości, prawda?