Atrybut XML a element XML

W pracy jesteśmy proszeni o utworzenie plików XML w celu przekazania danych do innej aplikacji offline, która następnie utworzy drugi plik XML do przekazania w celu zaktualizowania niektórych naszych danych. W trakcie tego procesu rozmawialiśmy z zespołem drugiej aplikacji o strukturze pliku XML.

Próbka, którą wymyśliłem, jest w zasadzie coś takiego:

<INVENTORY>
   <ITEM serialNumber="something" location="something" barcode="something">
      <TYPE modelNumber="something" vendor="something"/> 
   </ITEM>
</INVENTORY>

Drugi zespół powiedział, że nie jest to standard branżowy i że atrybutów należy używać tylko w przypadku metadanych. Zasugerowali:

<INVENTORY>
   <ITEM>
      <SERIALNUMBER>something</SERIALNUMBER>
      <LOCATION>something</LOCATION>
      <BARCODE>something</BARCODE>
      <TYPE>
         <MODELNUMBER>something</MODELNUMBER>
         <VENDOR>something</VENDOR>
      </TYPE>
   </ITEM>
</INVENTORY>

Powodem, dla którego zasugerowałem pierwszy, jest to, że rozmiar utworzonego pliku jest znacznie mniejszy. W pliku będzie około 80000 elementów, które będą znajdować się w pliku podczas przesyłania. Ich sugestia w rzeczywistości okazuje się trzy razy większa niż ta, którą zasugerowałem. Szukałem tajemniczego „standardu przemysłowego”, o którym wspomniano, ale najbliższe, jakie mogłem znaleźć, było to, że atrybuty XML powinny być używane tylko do metadanych, ale powiedziałem, że debata dotyczyła tego, co faktycznie były metadanymi.

Po długim, wyczerpującym wyjaśnieniu (przepraszam), jak określić, co to są metadane, a kiedy projektujesz strukturę dokumentu XML, jak powinieneś zdecydować, kiedy użyć atrybutu lub elementu?

Używam tej ogólnej zasady:

1. Atrybut to coś, co jest niezależne, tj. Kolor, identyfikator, nazwa.
2. Element jest czymś, co ma lub może mieć własne atrybuty lub zawierać inne elementy.

Więc twój jest blisko. Zrobiłbym coś takiego:

EDYCJA : Zaktualizowałem oryginalny przykład na podstawie opinii poniżej.

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

Niektóre problemy z atrybutami to:

• atrybuty nie mogą zawierać wielu wartości (elementy potomne mogą)
• atrybuty nie są łatwo rozszerzalne (dla przyszłych zmian)
• atrybuty nie mogą opisywać struktur (elementy potomne mogą)
• atrybutami trudniej manipulować za pomocą kodu programu
• wartości atrybutów nie są łatwe do przetestowania względem DTD

Jeśli użyjesz atrybutów jako kontenerów danych, powstanie dokument, który jest trudny do odczytania i utrzymania. Spróbuj użyć elementów do opisania danych. Użyj atrybutów tylko w celu dostarczenia informacji, które nie są istotne dla danych.

Nie kończy się w ten sposób (nie tak powinno się używać XML):

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

Źródło: http://www.w3schools.com/xml/xml_dtd_el_vs_attr.asp

„XML” oznacza „eXtensible Markup Language”. Język znaczników oznacza, że ​​dane to tekst oznaczony metadanymi dotyczącymi struktury lub formatowania.

XHTML jest przykładem XML wykorzystanego w zamierzony sposób:

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

Tutaj rozróżnienie między elementami i atrybutami jest jasne. Elementy tekstowe są wyświetlane w przeglądarce, a atrybuty są instrukcje dotyczące sposobu ich wyświetlania (choć istnieje kilka tagów, które nie działają w ten sposób).

Zamieszanie powstaje, gdy XML nie jest używany jako język znaczników, ale jako język serializacji danych , w którym rozróżnienie między „danymi” i „metadanymi” jest bardziej niejasne. Zatem wybór między elementami i atrybutami jest mniej więcej arbitralny, z wyjątkiem rzeczy, których nie można przedstawić za pomocą atrybutów (patrz odpowiedź Feenstera).

Element XML a atrybut XML

XML polega na porozumieniu. Najpierw odłóż na bok wszelkie istniejące schematy XML lub ustalone konwencje w społeczności lub branży.

Jeśli naprawdę jesteś w sytuacji, aby zdefiniować schemat od podstaw, oto kilka ogólnych uwag, które powinny pomóc w podjęciu decyzji o elemencie a atrybucie :

<versus>
  <element attribute="Meta content">
    Content
  </element>
  <element attribute="Flat">
    <parent>
      <child>Hierarchical</child>
    </parent>
  </element>
  <element attribute="Unordered">
    <ol>
      <li>Has</li>
      <li>order</li>
    </ol>
  </element>
  <element attribute="Must copy to reuse">
    Can reference to re-use
  </element>
  <element attribute="For software">
    For humans
  </element>
  <element attribute="Extreme use leads to micro-parsing">
    Extreme use leads to document bloat
  </element>
  <element attribute="Unique names">
    Unique or non-unique names
  </element>
  <element attribute="SAX parse: read first">
    SAX parse: read later
  </element>
  <element attribute="DTD: default value">
    DTD: no default value
  </element>
</versus>

Może to zależeć od twojego użytkowania. XML używany do reprezentowania uporządkowanych danych generowanych z bazy danych może działać dobrze, a ostatecznie wartości pól są umieszczane jako atrybuty.

Jednak XML używany jako transport komunikatów często byłby lepszy przy użyciu większej liczby elementów.

Powiedzmy na przykład, że mieliśmy ten kod XML zaproponowany w odpowiedzi: -

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

Teraz chcemy wysłać element ITEM do urządzenia w celu wydrukowania kodu kreskowego, jednak istnieje wybór rodzajów kodowania. Jak reprezentujemy wymagany typ kodowania? Nagle zdajemy sobie sprawę, z pewnym opóźnieniem, że kod kreskowy nie był pojedynczą wartością automatyczną, ale raczej można go zakodować przy użyciu kodowania wymaganego podczas drukowania.

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

Chodzi o to, o ile nie budujesz jakiegoś XSD lub DTD wraz z przestrzenią nazw, aby naprawić strukturę w kamieniu, najlepiej może być pozostawienie otwartych opcji.

IMO XML jest najbardziej przydatny, gdy można go zginać, nie niszcząc przy tym istniejącego kodu.

W projekcie schematu używam następujących wskazówek w odniesieniu do atrybutów vs. elementów:

• Używaj elementów dla długiego tekstu (zwykle tych ciągów lub znormalizowanych typów ciągów)
• Nie używaj atrybutu, jeśli dla elementu istnieje grupowanie dwóch wartości (np. EventStartDate i eventEndDate). W poprzednim przykładzie powinien istnieć nowy element „event”, który może zawierać atrybuty startDate i endDate.
• Data Biznesowa, Data i godzina oraz liczby (np. Liczby, kwota i stawka) powinny być elementami.
• Elementy czasu niezwiązanego z działalnością biznesową, takie jak ostatnia aktualizacja, wygasa dnia powinny być atrybutami.
• Liczby inne niż biznesowe, takie jak kody skrótu i ​​indeksy, powinny być atrybutami. * Użyj elementów, jeśli typ będzie złożony.
• Użyj atrybutów, jeśli wartość jest prostym typem i się nie powtarza.
• xml: id i xml: lang muszą być atrybutami odwołującymi się do schematu XML
• Preferuj atrybuty, gdy jest to technicznie możliwe.

Preferowane są następujące atrybuty:

• unikalny (atrybut nie może pojawić się wiele razy)
• kolejność nie ma znaczenia
• powyższe właściwości są dziedziczne (jest to coś, czego model zawartości „wszystko” nie obsługuje w bieżącym języku schematu)
• Bonusem jest to, że są mniej gadatliwi i zużywają mniejszą przepustowość, ale tak naprawdę nie jest to powód, aby preferować atrybuty nad elementami.

Dodałem, gdy jest to technicznie możliwe, ponieważ są chwile, w których użycie atrybutów nie jest możliwe. Na przykład opcje zestawu atrybutów. Na przykład użycie (startDate i endDate) xor (startTS i endTS) nie jest możliwe w bieżącym języku schematu

Jeśli schemat XML zacznie zezwalać na ograniczenie lub rozszerzenie modelu treści „wszystko”, prawdopodobnie go upuszczę

W razie wątpliwości KISS - po co mieszać atrybuty i elementy, jeśli nie masz wyraźnego powodu, aby używać atrybutów. Jeśli później zdecydujesz się zdefiniować XSD, będzie to również czystsze. Jeśli nawet później zdecydujesz się wygenerować strukturę klas z XSD, będzie to również prostsze.

Nie ma uniwersalnej odpowiedzi na to pytanie (byłem mocno zaangażowany w tworzenie specyfikacji W3C). XML może być wykorzystywany do wielu celów - dokumenty tekstowe, dane i kod deklaratywny są trzema najbardziej powszechnymi. Używam go również często jako modelu danych. Istnieją aspekty tych aplikacji, w których atrybuty są bardziej powszechne, i inne, w których elementy potomne są bardziej naturalne. Istnieją również funkcje różnych narzędzi, które ułatwiają lub utrudniają ich użycie.

XHTML to jeden obszar, w którym atrybuty mają naturalne zastosowanie (np. W klasie = „foo”). Atrybuty nie mają kolejności, co może ułatwić niektórym osobom opracowanie narzędzi. Atrybuty OTOH są trudniejsze do wpisania bez schematu. Uważam również, że atrybuty przestrzeni nazw (foo: bar = "zork") są często trudniejsze do zarządzania w różnych zestawach narzędzi. Ale spójrz na niektóre języki W3C, aby zobaczyć mieszankę, która jest powszechna. SVG, XSLT, XSD, MathML to niektóre przykłady dobrze znanych języków i wszystkie mają bogatą ofertę atrybutów i elementów. Niektóre języki pozwalają nawet na więcej niż jeden sposób, np

<foo title="bar"/>;

lub

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

Należy pamiętać, że NIE są one równoważne składniowo i wymagają jawnego wsparcia w narzędziach do przetwarzania)

Radzę zapoznać się z powszechną praktyką w obszarze najbliższym Twojej aplikacji, a także zastanowić się, jakie zestawy narzędzi możesz zastosować.

Na koniec upewnij się, że odróżniasz przestrzenie nazw od atrybutów. Niektóre systemy XML (np. Linq) reprezentują przestrzenie nazw jako atrybuty w interfejsie API. IMO to brzydkie i potencjalnie mylące.

Inni opisali, jak odróżniać atrybuty od elementów, ale z bardziej ogólnej perspektywy umieszczanie wszystkiego w atrybutach, ponieważ zmniejszanie wynikowego kodu XML jest błędne.

XML nie został zaprojektowany jako kompaktowy, ale przenośny i czytelny dla ludzi. Jeśli chcesz zmniejszyć rozmiar przesyłanych danych, użyj czegoś innego (np. Buforów protokołu Google ).

pytanie za milion dolarów!

po pierwsze, nie przejmuj się teraz zbytnio wydajnością. Zdziwisz się, jak szybko zoptymalizowany parser XML rozdziera twój xml. co ważniejsze, jaki jest twój projekt na przyszłość: w miarę ewolucji XML, jak utrzymasz luźne połączenie i interoperacyjność?

bardziej konkretnie, możesz sprawić, że model zawartości elementu będzie bardziej złożony, ale trudniej jest rozszerzyć atrybut.

Obie metody przechowywania właściwości obiektu są całkowicie poprawne. Powinieneś odejść od rozważań pragmatycznych. Spróbuj odpowiedzieć na następujące pytanie:

1. Która reprezentacja prowadzi do szybszego analizowania / generowania danych?

2. Która reprezentacja prowadzi do szybszego transferu danych?

3. Czy czytelność ma znaczenie?

   ...

Użyj elementów dla danych i atrybutów dla metadanych (dane o danych elementu).

Jeśli element pojawia się jako predykat w wybranych ciągach znaków, masz dobry znak, że powinien to być atrybut. Podobnie, jeśli atrybut nigdy nie jest używany jako predykat, być może nie są to przydatne metadane.

Pamiętaj, że XML ma być czytelny dla komputera, a nie dla człowieka, a dla dużych dokumentów XML bardzo dobrze kompresuje.

Jest to dyskusyjne w obu przypadkach, ale twoi koledzy mają rację w tym sensie, że XML powinien być używany do „znaczników” lub metadanych wokół rzeczywistych danych. Ze swojej strony masz rację, ponieważ czasami trudno jest zdecydować, gdzie leży granica między metadanymi i danymi podczas modelowania domeny w XML. W praktyce udaję, że wszystko w znaczniku jest ukryte, a tylko dane poza znacznikiem są czytelne. Czy dokument ma w ten sposób sens?

XML jest powszechnie nieporęczny. W przypadku transportu i przechowywania zaleca się kompresję, jeśli stać Cię na moc przetwarzania. XML kompresuje się dobrze, czasem fenomenalnie dobrze, ze względu na swoją powtarzalność. Miałem kompresję dużych plików do mniej niż 5% ich oryginalnego rozmiaru.

Kolejną kwestią, która powinna wzmocnić twoje stanowisko, jest fakt, że podczas gdy drugi zespół kłóci się o styl (w tym, że większość narzędzi XML poradzi sobie z dokumentem zawierającym wszystkie atrybuty równie łatwo, jak dokument z # PCDATA), argumentujesz o praktyczności. Chociaż stylu nie można całkowicie zignorować, zalety techniczne powinny mieć większy ciężar.

To w dużej mierze kwestia preferencji. Używam elementów do grupowania i atrybutów danych tam, gdzie to możliwe, ponieważ widzę to jako bardziej kompaktowe niż alternatywa.

Na przykład wolę .....

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

...Zamiast....

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

Jeśli jednak mam dane, które nie przedstawiają się łatwo w obrębie powiedzmy 20-30 znaków lub zawierają wiele cudzysłowów lub innych znaków, które wymagają ucieczki, powiedziałbym, że nadszedł czas, aby rozbić elementy ... prawdopodobnie za pomocą bloków 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>

Co powiesz na skorzystanie z naszej ciężko zarobionej intuicyjnej orientacji na obiekt? Zazwyczaj uważam, że łatwo jest myśleć, który obiekt jest atrybutem obiektu lub do którego obiektu się odnosi.

W zależności od tego, co intuicyjnie ma sens, obiekty powinny pasować jako elementy. Jego atrybuty (lub właściwości) byłyby atrybutami dla tych elementów w XML lub element potomny z atrybutem.

Myślę, że w prostszych przypadkach, takich jak w przykładzie, analogia orientacji obiektu działa dobrze, aby dowiedzieć się, który element jest, a który atrybut elementu.

Kilka poprawek do niektórych złych informacji:

@John Ballinger: Atrybucje mogą zawierać dowolne dane postaci. <> & „” należy odpowiednio zmienić na „& amp;” i „. Jeśli używasz biblioteki XML, zajmie się tym za Ciebie.

Do diabła, atrybut może zawierać dane binarne, takie jak obraz, jeśli naprawdę chcesz, po prostu kodując go base64 i czyniąc z niego dane: URL.

@feenster: Atrybuty mogą zawierać oddzielone spacjami wiele elementów w przypadku IDS lub NAMES, które mogą zawierać liczby. Nitpicky, ale może to zaoszczędzić miejsce.

Korzystanie z atrybutów może utrzymać konkurencyjność XML-a w JSON. Zobacz Fat Markup: Trimming Fat Markup Mit jedna kaloria na raz .

Zawsze jestem zaskoczony wynikami tego rodzaju dyskusji. Dla mnie istnieje bardzo prosta reguła decydująca o tym, czy dane należą do atrybutu, czy do treści, i to, czy dane mają podstrukturalną strukturę.

Na przykład tekst bez znaczników zawsze należy do atrybutów. Zawsze.

Listy należą do podstruktury lub treści. Tekst, który z czasem może zawierać osadzoną ustrukturyzowaną pod-treść, należy do treści. (Z mojego doświadczenia wynika, że ​​jest to stosunkowo mało - tekst ze znacznikami - podczas korzystania z XML do przechowywania lub wymiany danych.)

Tak zapisany schemat XML jest zwięzły.

Ilekroć widzę takie przypadki <car><make>Ford</make><color>Red</color></car>, myślę sobie: „O rany, czy autor pomyślał, że będą elementy podrzędne w elemencie make?”. <car make="Ford" color="Red" />jest znacznie bardziej czytelny, nie ma wątpliwości co do sposobu obsługi białych znaków itp.

Biorąc pod uwagę tylko zasady obsługi białych znaków, uważam, że taka była wyraźna intencja projektantów XML.

Jest to bardzo wyraźne w HTML, gdzie wyraźnie widać różnice atrybutów i znaczników:

1. Wszystkie dane są między znacznikami
2. Atrybuty służą do charakteryzowania tych danych (np. Formaty)

Jeśli masz tylko czyste dane w formacie XML, różnica jest mniej wyraźna. Dane mogą znajdować się między znacznikami lub jako atrybuty.

=> Większość danych powinna znajdować się pomiędzy znacznikami.

Jeśli chcesz tutaj użyć atrybutów: możesz podzielić dane na dwie kategorie: Dane i „metadane”, w których metadane nie są częścią rekordu, chcesz je przedstawić, ale takie rzeczy jak „wersja formatu”, „data utworzenia” itp.

<customer format="">
     <name></name>
     ...
</customer>

Można również powiedzieć: „Użyj atrybutów do scharakteryzowania tagu, użyj tagów do dostarczenia danych”.

Zgadzam się z Feenster. Unikaj atrybutów, jeśli możesz. Elementy są przyjazne dla ewolucji i bardziej interoperacyjne między zestawami narzędzi serwisów internetowych. Nigdy nie znajdziesz tych zestawów narzędzi, które serializują wiadomości z żądaniami / odpowiedzi za pomocą atrybutów. Ma to również sens, ponieważ nasze wiadomości są danymi (a nie metadanymi) dla zestawu narzędzi serwisu internetowego.

Zaufaj mi z czasem. zawsze trzymam się od nich osobiście z daleka. Elementy są znacznie bardziej wyraźne i czytelne / użyteczne zarówno dla parserów, jak i użytkowników.

Jedynym razem, kiedy ich użyłem, było zdefiniowanie rozszerzenia pliku adresu URL zasobu:

<image type="gif">wank.jpg</image> ...etc etc

myślę, że jeśli wiesz 100%, atrybut nie musi być rozszerzany, możesz go użyć, ale ile razy to wiesz.

<image>
  <url>wank.jpg</url>
  <fileType>gif</fileType>
</image>