Jak powinieneś uporządkować swój plik xml?

Question

Podczas tworzenia nowego pliku XML, w jaki sposób uporządkować plik poprawnie lub w najlepszy możliwy sposób. Ze względu na strukturę, która może nie być najlepszym słowem w tym przypadku, mam na myśli to, w jaki sposób można wybierać pomiędzy uczynieniem czegoś elementem lub atrybutem elementu. Na przykład, jeśli utworzyć plik Person.xml która zawiera listę osób, lepiej jest zrobić coś takiego:

<Person> 
    <FirstName>John</FirstName> 
    <LastName>Doe</LastName> 
    <Age>23</Age> 
</Person> 

czy lepiej zrobić coś takiego, czy też nawet znaczenia?

<Person FirstName="John" LastName="Doe" Age="23"></Person> 

Answer 1

pliki XML powinien (nie rozpocząć świętą wojnę) następującą strukturę:

Jeśli jest to dane, lub coś, co można zmienić, to powinno być tak:

<Person> 
    <FirstName>John</FirstName> 
    <LastName>Smith</LastName> 
    <Age>23</Age> 
</Person> 

If jest atrybutem rzeczą Person to powinno być tak:

Istnieje wiele powodów, dla tej praktyki, z których nie najmniej obejmuje łatwość f ixing transformacji XSLT za każdym razem, gdy zmienisz metodę pobierania danych osobowych.

To naprawdę ważna część: Atrybuty definiują informacje o danych (typ osoby), a dane to coś, co ma na celu wypełnienie tych dziur. Jeśli zdecydujesz, w jaki sposób zamierzasz zmienić sposób wypełniania tych dziur, staje się to trudniejsze, jeśli utworzysz je jako "atrybuty" zamiast "danych", jeśli chcesz później przekształcić swój XML.

Answer 2

To subiektywna sprawa.

Answer 3

Naprawdę nie ma znaczenia, ale sposób, w jaki decyduję, to: jeśli coś może być uznane za byt samoistnie (w tym przykładzie, Osoba, robię z tego element.) Jeśli to coś modyfikuje byt (lub atrybut podmiotu), robię to atrybut

. Przykład:

<Person FirstName="John" LastName="Doe" Age="23"> 
    <Clothing wet="No"> 
     <Shirt colour="Red" /> 
    </Clothing> 
</Person> 

Answer 4

wydaje mi się, to jest coś podobnego do Chevy vs Ford lub Windows vs MacOS nie ma wyraźnego zwycięzcy dla wszystkich. sytuacje, a samo pytanie może generować bardzo zmienną "dyskusję" z właściwymi uczestnikami;)

Krótka odpowiedź brzmi, że albo może być odpowiedni w zależności od sytuacji. Czasami decydującym czynnikiem jest nawet biblioteka, którą wybierzesz do odczytu lub aktualizacji danych w XML.

Answer 5

Oto pretty good article o princeiples projektowania XML:

• Principles of XML design: When to use elements versus attributes

Answer 6

Pierwszym jest rozwlekły sposób robienia rzeczy: Wszystko jest elementem. Jest to powszechny sposób, w jaki ludzie robią to po prostu dlatego, że tak łatwo jest je przeglądać i analizować.

Jednak atrybuty zostały wprowadzone tylko z tego powodu: są to fragmenty informacji o elemencie. Twój drugi przykład jest całkowicie akceptowalny.W rzeczywistości można go skrócić:

<Person FirstName="John" LastName="Doe" Age="23" /> 

Prawdopodobnie zrobiłbym to drugie.

Jedyna chwila, której nie chcesz, jeśli potrzebujesz więcej danych xml wewnątrz lub długich formatów.

Answer 7

Ogólnie rzecz biorąc, chcesz, aby elementy reprezentowały "prawdziwe" informacje, które modelujesz, i rezerwować atrybuty dla informacji "meta" - które kwalifikują treść.

Answer 8

Niezależnie od gustu, tutaj jest podstawowym zbiorem zagadnień:

Wykorzystanie atrybutów do mapowania wartości unikatowych nazw podczas zamawiania nie jest znacząca. W przeciwnym razie użyj elementów.

• Wartości: liczby, łańcuchy, daty itd., Ale nie obiekty o wielu właściwościach.
• Unikalne nazwy: każda nazwa atrybutu na elemencie musi być niepowtarzalna. Jeśli rzecz reprezentowana przez element może mieć więcej niż jedno skojarzenie z Foo, Foo nie powinien być atrybutem.
• Zamawianie nie jest znaczące: aplikacja nie może zależeć od wartości przedstawianych procesom w określonej kolejności.

Przykład: jeśli chcesz zaokrąglić dane między (powiedzmy) ADO.NET i XML, czy wartości kolumn powinny być przechowywane w atrybutach lub elementach? (Nie przejmuj się przez chwilę, że ADO.NET robi to za Ciebie.) Cóż, nazwy kolumn są odwzorowywane w unikalny sposób, a wartości kolumn są łatwo serializowanymi typami danych. Na pewno, dlaczego tego nie zrobić?

<Person FirstName="John" MiddleName="Q." LastName="Smith"/> 

Ale tak naprawdę jest to niszcząca informacje transformacja. Kolejność kolumn wyświetlana w rekordzie ADO.NET jest znacząca. Jeśli coś jest w kolumnie 2 przed transformacją, powinno być w kolumnie 2 później. Konwertowanie ich na atrybuty spowoduje utratę tych informacji. (Znam jeden implementacja DOM, na przykład, że pobiera atrybuty w porządku alfabetycznym według nazwy.)

Dlatego ADO.NET reprezentuje wiersze jak ten, choć jest rozwlekły:

<Person> 
    <FirstName>John</FirstName> 
    <MiddleName>Q.</MiddleName> 
    <LastName>Smith</LastName> 
</Person> 

Jeśli chodzi o powszechna mądrość, że elementy są dla informacji, a atrybuty są dla metainformacji: jest to często bardzo dobra rada. Często jest to także przesąd, który doprowadzi cię do złych miejsc.

Po pierwsze, metainformacja może wymagać wielu wartości powiązanych z tą samą nazwą. Można, na przykład, chcesz oznaczyć element z listy stron, które będą go używać:

<Person Pages="B1,B2,B3,B4"> 
    <FirstName>John... 

kiedykolwiek próbował napisać szablon XSLT, który analizuje listę oddzielonych przecinkami? Dowiesz się wiele, robiąc to, ale prawdopodobnie nie jest to coś, o czym chcesz wiedzieć.

Po drugie, projektanci XML, którzy nie wiedzą, z kim mają do czynienia, niech te wskazówki poprowadzą ich do wpisania atrybutu, który powinien znajdować się w nazwie znacznika elementu. Na przykład:

<Person Type="Employee"> 
    <SSN>123-45-6789</SSN> 
    <Extension>123</Extension> 
</Person> 
<Person Type="Customer"> 
    <PhoneNumber>123-456-7890</PhoneNumber> 
    <BillingAddress>... 

i tak dalej.Zgadnij, co się dzieje, gdy próbujesz napisać schemat wymuszający różne reguły na elementach Person na podstawie atrybutu Type? Niepowodzenie. Schematy są powiązane z nazwą elementu. Wszystkie elementy Person muszą mieć ten sam schemat. W takim przypadku elementy powinny mieć nazwy: Employee i Customer.