Atribut XML vs elemen XML


253

Di tempat kerja kami diminta untuk membuat file XML untuk meneruskan data ke aplikasi offline lain yang kemudian akan membuat file XML kedua untuk dilewati agar dapat memperbarui beberapa data kami. Selama proses kami telah berdiskusi dengan tim aplikasi lain tentang struktur file XML.

Sampel yang saya buat pada dasarnya adalah sesuatu seperti:

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

Tim lain mengatakan bahwa ini bukan standar industri dan bahwa atribut hanya boleh digunakan untuk data meta. Mereka menyarankan:

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

Alasan saya menyarankan yang pertama adalah bahwa ukuran file yang dibuat jauh lebih kecil. Akan ada sekitar 80000 item yang akan ada dalam file selama transfer. Saran mereka pada kenyataannya ternyata tiga kali lebih besar dari yang saya sarankan. Saya mencari "Standar Industri" misterius yang disebutkan, tetapi yang paling dekat yang bisa saya temukan adalah bahwa atribut XML hanya boleh digunakan untuk data meta, tetapi mengatakan perdebatannya adalah tentang apa yang sebenarnya adalah data meta.

Setelah penjelasan panjang lebar (maaf) bagaimana Anda menentukan apa itu data meta, dan ketika merancang struktur dokumen XML bagaimana Anda harus memutuskan kapan harus menggunakan atribut atau elemen?


4
Saya menemukan sumber yang sangat bagus ini: ibm.com/developerworks/xml/library/x-eleatt.html
Laurens Holst

5
+1 untuk "... debatnya adalah tentang apa yang sebenarnya merupakan data meta."
Dirahasiakan

Harap perhatikan nama tag huruf kecil dengan tanda hubung: stackoverflow.com/questions/1074447/...
Ben

Jawaban:


145

Saya menggunakan aturan praktis ini:

  1. Atribut adalah sesuatu yang mandiri, yaitu warna, ID, nama.
  2. Suatu Elemen adalah sesuatu yang memiliki atau dapat memiliki atributnya sendiri atau mengandung elemen lain.

Jadi milikmu sudah dekat. Saya akan melakukan sesuatu seperti:

EDIT : Diperbarui contoh asli berdasarkan umpan balik di bawah ini.

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

22
Saya membaca beberapa jawaban dan sesuatu yang tidak cukup ditekankan dari pengalaman saya adalah bahwa jika Anda data dalam "atribut" dan tiba-tiba memiliki> atau <Anda dokumen XML akan pecah, saya pikir ada lima karakter ascii (>, <, &,?, ") yang akan membunuhnya. Jika karakter khusus ini ada di Elemen, Anda cukup menambahkan beberapa tag CDATA di sekitar data ini. Saya akan mengatakan, hanya gunakan atribut ketika Anda 100% tahu nilai apa yang akan diberikan . di sana, misalnya, bilangan bulat atau tanggal, mungkin apa yang dihasilkan komputer Jika barcode dihasilkan oleh manusia maka seharusnya tidak menjadi atribut.
John Ballinger

39
Benar-benar terlambat ke pesta, tapi argumen khusus ASCII char salah - untuk itulah melarikan diri, baik untuk atribut dan data teks.
micahtan

2
@donroby - Maaf, itu adalah kesalahan saya dalam berkomunikasi. Dengan melarikan diri, maksud saya penyandian XML. '<' = & lt; dll. Tampaknya aneh bagi saya untuk memutuskan antara atribut atau elemen berdasarkan karakter yang membentuk konten alih-alih makna konten.
micahtan

3
@donroby: tidak benar Teks pengganti &lt;adalah &#60;, yang merupakan referensi karakter, bukan referensi entitas. &lt;tidak apa-apa dalam atribut. Lihat: w3.org/TR/REC-xml/#sec-predefined-ent
Porges

14
@ John: jika ini masalah maka ada sesuatu di rantai alat Anda yang tidak menghasilkan XML yang valid. Saya tidak berpikir ini adalah alasan untuk memilih antara atribut atau elemen. (Selain itu, Anda tidak dapat "hanya menambahkan tag CDATA" di sekitar input pengguna karena mungkin mengandung ]]>!)
porges

48

Beberapa masalah dengan atribut adalah:

  • atribut tidak boleh mengandung banyak nilai (elemen anak bisa)
  • atribut tidak mudah diperluas (untuk perubahan di masa mendatang)
  • atribut tidak dapat menggambarkan struktur (elemen anak bisa)
  • atribut lebih sulit untuk dimanipulasi oleh kode program
  • nilai atribut tidak mudah diuji terhadap DTD

Jika Anda menggunakan atribut sebagai wadah untuk data, Anda berakhir dengan dokumen yang sulit dibaca dan dipelihara. Cobalah menggunakan elemen untuk menggambarkan data. Gunakan atribut hanya untuk memberikan informasi yang tidak relevan dengan data.

Jangan berakhir seperti ini (ini bukan bagaimana XML seharusnya digunakan):

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

Sumber: http://www.w3schools.com/xml/xml_dtd_el_vs_attr.asp


2
Titik pertama adalah tidak benar, lihat: w3.org/TR/xmlschema-2/#derivation-by-list
Porges

6
Saya akan mengatakan bahwa poin pertama benar dan listmerupakan solusi parsial untuk masalah ini. Tidak boleh ada banyak atribut dengan nama yang sama. Dengan listatribut masih hanya memiliki satu nilai, yaitu daftar yang dipisahkan spasi putih dari beberapa tipe data. Karakter pemisahan diperbaiki sehingga Anda tidak dapat memiliki beberapa nilai jika nilai tunggal dari tipe data yang diinginkan dapat berisi spasi. Ini mengesampingkan kemungkinan memiliki misalnya beberapa alamat dalam satu atribut "alamat".
jasso

7
'atribut lebih sulit untuk dimanipulasi oleh kode program' - Tidak dapat setuju dengan itu. Sebenarnya saya telah menemukan yang sebaliknya benar. Tidak cukup perbedaan untuk benar-benar menyatakannya.
Paul Alexander

4
Saya juga menambahkan bahwa validasi terhadap DTD tidak benar-benar relevan lagi, dengan XML-Schema, Schematron and Relax, et. Al. semuanya memberikan cara yang jauh lebih kuat dan dalam beberapa kasus lebih intuitif untuk memvalidasi dokumen XML. Juga, W3Schools adalah referensi yang sangat buruk untuk apa pun

37

"XML" adalah singkatan dari "eXtensible Markup Language". Bahasa markup menyiratkan bahwa data adalah teks, ditandai dengan metadata tentang struktur atau pemformatan.

XHTML adalah contoh XML yang digunakan seperti yang dimaksudkan:

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

Di sini, perbedaan antara elemen dan atribut jelas. Elemen teks ditampilkan di browser, dan atribut adalah instruksi tentang cara menampilkannya (walaupun ada beberapa tag yang tidak berfungsi seperti itu).

Kebingungan muncul ketika XML digunakan bukan sebagai bahasa markup, tetapi sebagai bahasa serialisasi data , di mana perbedaan antara "data" dan "metadata" lebih kabur. Jadi pilihan antara elemen dan atribut lebih atau kurang sewenang-wenang kecuali untuk hal-hal yang tidak dapat diwakili dengan atribut (lihat jawaban feenster).


32

Elemen XML vs Atribut XML

XML adalah tentang kesepakatan. Pertama-tama tunda skema XML yang ada atau konvensi yang sudah mapan dalam komunitas atau industri Anda.

Jika Anda benar-benar dalam situasi untuk menentukan skema Anda dari bawah ke atas, berikut adalah beberapa pertimbangan umum yang harus menginformasikan keputusan elemen vs atribut :

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

23

Ini mungkin tergantung pada penggunaan Anda. XML yang digunakan untuk mewakili data terstruktur yang dihasilkan dari database dapat bekerja dengan baik dengan nilai bidang akhirnya ditempatkan sebagai atribut.

Namun XML yang digunakan sebagai transportasi pesan seringkali lebih baik menggunakan lebih banyak elemen.

Misalnya katakanlah kami memiliki XML ini seperti yang diusulkan dalam jawaban: -

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

Sekarang kami ingin mengirim elemen ITEM ke perangkat untuk mencetak barcode tetapi ada pilihan jenis penyandian. Bagaimana kami mewakili jenis penyandian yang diperlukan? Tiba-tiba kami menyadari, agak terlambat, bahwa barcode bukan nilai otomatis tunggal tetapi mungkin memenuhi syarat dengan pengkodean yang diperlukan saat dicetak.

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

Intinya adalah kecuali Anda membangun semacam XSD atau DTD bersama dengan namespace untuk memperbaiki struktur di atas batu, Anda mungkin lebih baik membiarkan opsi Anda terbuka.

IMO XML paling bermanfaat ketika dapat ditekuk tanpa melanggar kode yang ada menggunakannya.


Poin bagus pada "barcode", saya bergegas contoh saya dan pasti akan memecahnya menjadi elemen sendiri. Bagus juga pada XSD / DTD.
Chuck

10

Saya menggunakan pedoman berikut dalam desain skema saya sehubungan dengan atribut vs elemen:

  • Gunakan elemen untuk teks yang sudah berjalan lama (biasanya yang berupa string atau tipe penelusuran normal)
  • Jangan gunakan atribut jika ada pengelompokan dua nilai (misalnya eventStartDate dan eventEndDate) untuk suatu elemen. Pada contoh sebelumnya, harus ada elemen baru untuk "event" yang mungkin berisi atribut startDate dan endDate.
  • Tanggal Bisnis, DateTime dan angka (mis. Jumlah, jumlah dan tingkat) harus menjadi elemen.
  • Elemen waktu non-bisnis seperti yang terakhir diperbarui, kedaluwarsa pada harus atribut.
  • Nomor non-bisnis seperti kode hash dan indeks harus atribut. * Gunakan elemen jika jenisnya akan kompleks.
  • Gunakan atribut jika nilainya adalah tipe sederhana dan tidak berulang.
  • xml: id dan xml: lang harus atribut yang merujuk pada skema XML
  • Lebih suka atribut bila mungkin secara teknis.

Preferensi untuk atribut adalah menyediakan yang berikut ini:

  • unik (atribut tidak dapat muncul beberapa kali)
  • pesanan tidak masalah
  • properti di atas dapat diwariskan (ini adalah sesuatu yang model konten "semua" tidak mendukung dalam bahasa skema saat ini)
  • bonus adalah mereka kurang bertele-tele dan menghabiskan lebih sedikit bandwidth, tapi itu bukan alasan untuk lebih memilih atribut daripada elemen.

Saya menambahkan ketika secara teknis mungkin karena ada saat-saat di mana penggunaan atribut tidak mungkin. Misalnya, atribut mengatur pilihan. Misalnya penggunaan (startDate dan endDate) xor (startTS dan endTS) tidak dimungkinkan dengan bahasa skema saat ini

Jika Skema XML mulai memungkinkan model konten "semua" dibatasi atau diperluas, maka saya mungkin akan membatalkannya


8

Saat ragu, KISS - mengapa mencampur atribut dan elemen saat Anda tidak memiliki alasan yang jelas untuk menggunakan atribut. Jika nanti Anda memutuskan untuk mendefinisikan XSD, itu juga akan menjadi lebih bersih. Kemudian jika Anda bahkan kemudian memutuskan untuk membuat struktur kelas dari XSD Anda, itu akan lebih sederhana juga.


8

Tidak ada jawaban universal untuk pertanyaan ini (saya sangat terlibat dalam pembuatan spesifikasi W3C). XML dapat digunakan untuk banyak tujuan - dokumen seperti teks, data, dan kode deklaratif adalah tiga yang paling umum. Saya juga banyak menggunakannya sebagai model data. Ada aspek aplikasi ini di mana atribut lebih umum dan yang lain di mana elemen anak lebih alami. Ada juga fitur dari berbagai alat yang membuatnya lebih mudah atau lebih sulit untuk menggunakannya.

XHTML adalah salah satu area di mana atribut memiliki kegunaan alami (misalnya di class = 'foo'). Atribut tidak memiliki urutan dan ini dapat memudahkan sebagian orang untuk mengembangkan alat. Atribut OTOH lebih sulit diketik tanpa skema. Saya juga menemukan atribut namespace (foo: bar = "zork") seringkali lebih sulit untuk dikelola di berbagai toolset. Tetapi lihat beberapa bahasa W3C untuk melihat campuran yang umum. SVG, XSLT, XSD, MathML adalah beberapa contoh bahasa terkenal dan semuanya memiliki banyak atribut dan elemen. Beberapa bahasa bahkan memungkinkan lebih dari satu cara untuk melakukannya, misalnya

<foo title="bar"/>;

atau

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

Perhatikan bahwa ini TIDAK setara secara sintaksis dan memerlukan dukungan eksplisit dalam alat pemrosesan)

Saran saya adalah untuk melihat praktik umum di area terdekat dengan aplikasi Anda dan juga mempertimbangkan perangkat apa yang mungkin ingin Anda terapkan.

Akhirnya pastikan Anda membedakan ruang nama dari atribut. Beberapa sistem XML (misalnya Linq) mewakili ruang nama sebagai atribut dalam API. IMO ini jelek dan berpotensi membingungkan.


6

Yang lain telah membahas bagaimana membedakan antara atribut dari elemen tetapi dari perspektif yang lebih umum menempatkan semuanya dalam atribut karena itu membuat XML yang dihasilkan lebih kecil salah.

XML tidak dirancang untuk menjadi ringkas tetapi untuk portabel dan dapat dibaca manusia. Jika Anda ingin mengurangi ukuran data dalam perjalanan, maka gunakan sesuatu yang lain (seperti buffer protokol Google ).


Teks XML yang lebih kecil lebih mudah dibaca manusia hanya karena lebih kecil!
Nashev

5

pertanyaan juta dolar!

pertama, jangan terlalu khawatir tentang kinerja sekarang. Anda akan kagum pada seberapa cepat parser xml yang dioptimalkan akan merobek xml Anda. yang lebih penting, apa desain Anda untuk masa depan: seiring XML berkembang, bagaimana Anda akan mempertahankan kopling yang longgar dan interoperabilitas?

lebih konkretnya, Anda dapat membuat model konten suatu elemen lebih kompleks tetapi lebih sulit untuk memperluas atribut.


5

Kedua metode untuk menyimpan properti objek sangat valid. Anda harus berangkat dari pertimbangan pragmatis. Coba jawab pertanyaan berikut:

  1. Representasi mana yang menyebabkan parsing data \ generasi lebih cepat?

  2. Representasi mana yang mengarah pada transfer data yang lebih cepat?

  3. Apakah keterbacaan penting?

    ...


5

Gunakan elemen untuk data dan atribut untuk data meta (data tentang data elemen).

Jika suatu elemen ditampilkan sebagai predikat dalam string pilihan Anda, Anda memiliki pertanda baik bahwa itu harus menjadi atribut. Demikian juga jika suatu atribut tidak pernah digunakan sebagai predikat, maka mungkin itu bukan data meta yang berguna.

Ingat bahwa XML seharusnya dapat dibaca oleh mesin, tidak dapat dibaca oleh manusia dan untuk dokumen besar, XML dapat dikompres dengan baik.


4

Ini bisa diperdebatkan dengan cara lain, tetapi kolega Anda benar dalam arti bahwa XML harus digunakan untuk "markup" atau meta-data di sekitar data aktual. Untuk bagian Anda, Anda benar bahwa kadang-kadang sulit untuk memutuskan di mana garis antara meta-data dan data saat memodelkan domain Anda dalam XML. Dalam praktiknya, apa yang saya lakukan adalah berpura-pura bahwa segala sesuatu di markup disembunyikan, dan hanya data di luar markup yang dapat dibaca. Apakah dokumen tersebut masuk akal seperti itu?

XML terkenal besar. Untuk transportasi dan penyimpanan, kompresi sangat disarankan jika Anda mampu membeli daya pemrosesan. XML kompres dengan baik, kadang-kadang sangat baik, karena pengulangannya. Saya telah mengkompres file besar hingga kurang dari 5% dari ukuran aslinya.

Poin lain untuk meningkatkan posisi Anda adalah bahwa sementara tim lain berdebat tentang gaya (dalam sebagian besar alat XML akan menangani semua-atribut dokumen semudah dokumen all-# PCDATA), Anda memperdebatkan kepraktisan. Sementara gaya tidak dapat sepenuhnya diabaikan, kelebihan teknis seharusnya lebih berat.


4

Ini sebagian besar masalah preferensi. Saya menggunakan Elemen untuk pengelompokan dan atribut untuk data jika memungkinkan karena saya melihat ini lebih kompak daripada alternatifnya.

Misalnya saya lebih suka .....

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

...Dari pada....

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

Namun jika saya memiliki data yang tidak mewakili dengan mudah dalam katakanlah 20-30 karakter atau mengandung banyak kutipan atau karakter lain yang perlu melarikan diri maka saya akan mengatakan sudah waktunya untuk memecahkan elemen ... mungkin dengan blok 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>

2
Ini salah datar, saya khawatir - Anda harus mengikuti pedoman W3C: w3schools.com/DTD/dtd_el_vs_attr.asp - XML ​​tidak boleh dibentuk berdasarkan keterbacaan atau membuatnya "kompak" - melainkan menggunakan elemen atau atribut dengan benar untuk tujuan tersebut. untuk siapa mereka dirancang.
Vidar

24
Maaf, tapi ini menyesatkan. Halaman W3schools bukan panduan W3C. Rekomendasi W3C XML (di mana saya adalah peserta) memungkinkan elemen dan atribut untuk digunakan sesuai dengan kebutuhan dan gaya pengguna.
peter.murray.rust

4

Bagaimana kalau memanfaatkan intuisi orientasi objek yang kita peroleh dengan susah payah? Saya biasanya mendapati bahwa berpikir adalah objek dan yang merupakan atribut dari objek atau objek yang dimaksud.

Apa pun yang secara intuitif masuk akal sebagai objek akan cocok sebagai elemen. Atribut-atributnya (atau propertinya) akan menjadi atribut untuk elemen-elemen ini dalam xml atau elemen turunan dengan atribut.

Saya pikir untuk kasus-kasus yang lebih sederhana seperti pada contoh analogi orientasi objek bekerja dengan baik untuk mengetahui mana elemen dan yang merupakan atribut dari suatu elemen.


2

Hanya beberapa koreksi ke beberapa info buruk:

@John Ballinger: Atribut dapat berisi data karakter apa pun. <> & "'masing-masing harus lolos ke & lt; & gt; & amp; & quot; dan & apos ;. Jika Anda menggunakan pustaka XML, itu akan mengurusnya untuk Anda.

Sial, atribut dapat berisi data biner seperti gambar, jika Anda benar-benar mau, hanya dengan encoding base64 dan menjadikannya data: URL.

@feenster: Atribut dapat berisi beberapa item yang dipisahkan oleh spasi dalam kasus IDS atau NAMES, yang akan mencakup angka. Nitpicky, tapi ini bisa menghemat ruang.

Menggunakan atribut dapat membuat XML tetap kompetitif dengan JSON. Lihat Fat Markup: Memotong Mitos Markup Lemak satu kalori setiap kali .


Bukan hanya id atau nama. Mereka dapat berisi daftar apa saja yang dipisahkan oleh ruang.
John Saunders

@JohnSaunders IDS atau NAMES adalah tipe DTD tertentu (Skema XML juga, saya pikir), didukung pada level rendah oleh sebagian besar prosesor XML. Jika ditangani oleh lapisan aplikasi alih-alih pustaka XML, segala jenis data karakter berfungsi (nilai yang dipisahkan atau apa pun).
brianary

Secara pribadi, hanya karena Anda tidak dapat berarti Anda harus melakukannya.
Lankymart

1
@Lankymart Seperti yang saya katakan, saya hanya mengoreksi beberapa info yang salah (yang mencetak skor tinggi karena alasan tertentu). Data biner biasanya tidak termasuk dalam XML sama sekali.
brianary

1

Saya selalu terkejut dengan hasil diskusi semacam ini. Bagi saya ada aturan yang sangat sederhana untuk memutuskan apakah data termasuk dalam atribut atau sebagai konten dan apakah data tersebut memiliki sub-struktur yang dapat dinavigasi.

Jadi misalnya, teks non-markup selalu termasuk dalam atribut. Selalu.

Daftar termasuk dalam sub-struktur atau konten. Teks yang dari waktu ke waktu termasuk sub-konten terstruktur yang melekat termasuk dalam konten. (Menurut pengalaman saya, ini relatif sedikit - teks dengan markup - saat menggunakan XML untuk penyimpanan atau pertukaran data.)

Skema XML yang ditulis dengan cara ini ringkas.

Setiap kali saya melihat kasus seperti <car><make>Ford</make><color>Red</color></car>, saya berpikir pada diri sendiri, "Ya, apakah penulis berpikir bahwa akan ada sub-elemen dalam elemen make?" <car make="Ford" color="Red" />secara signifikan lebih mudah dibaca, tidak ada pertanyaan tentang bagaimana ruang putih akan ditangani dll.

Diberikan hanya aturan penanganan spasi putih, saya percaya ini adalah maksud yang jelas dari desainer XML.


salah satu dari sedikit penjelasan yang bisa saya baca. tidak tahu apakah itu ide yang bagus ... tapi setidaknya saya mengerti intinya;)
Thufir

0

Ini sangat jelas dalam HTML di mana perbedaan atribut dan markup dapat dilihat dengan jelas:

  1. Semua data ada di antara markup
  2. Atribut digunakan untuk mengkarakterisasi data ini (misalnya format)

Jika Anda hanya memiliki data murni sebagai XML, ada perbedaan yang kurang jelas. Data bisa berdiri di antara markup atau sebagai atribut.

=> Sebagian besar data harus berdiri di antara markup.

Jika Anda ingin menggunakan atribut di sini: Anda dapat membagi data menjadi dua kategori: Data dan "data meta", di mana data meta bukan bagian dari catatan, Anda ingin menyajikan, tetapi hal-hal seperti "format versi", "tanggal dibuat" , dll.

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

Bisa juga dikatakan: "Gunakan atribut untuk menandai tag, gunakan tag untuk memberikan data itu sendiri."


-1

Saya setuju dengan Feenster. Jauhi atribut jika Anda bisa. Elemen-elemennya ramah evolusi dan lebih dapat dioperasikan di antara toolkit layanan web. Anda tidak akan pernah menemukan toolkit ini menyambungkan pesan permintaan / respons Anda menggunakan atribut. Ini juga masuk akal karena pesan kami adalah data (bukan metadata) untuk toolkit layanan web.


-1

Atribut dapat dengan mudah menjadi sulit dikelola seiring waktu, percayalah. Saya selalu menjauh dari mereka secara pribadi. Elemen jauh lebih eksplisit dan dapat dibaca / digunakan oleh pengurai dan pengguna.

Hanya waktu saya pernah menggunakannya adalah menentukan ekstensi file url aset:

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

Saya kira jika Anda tahu 100% atribut tidak perlu diperluas Anda bisa menggunakannya, tetapi berapa kali Anda tahu itu.

<image>
  <url>wank.jpg</url>
  <fileType>gif</fileType>
</image>
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.