Bahasa XML ditemukan pada tahun 1996. Segera setelah itu muncul, kemungkinan penerapannya sudah mulai disalahpahami, dan untuk tujuan yang mereka coba adaptasi, itu bukanlah pilihan terbaik.
Tidaklah berlebihan untuk mengatakan bahwa sebagian besar skema XML yang saya lihat adalah penggunaan XML yang tidak tepat atau salah. Selain itu, penggunaan XML ini menunjukkan kesalahpahaman mendasar tentang apa itu XML.
XML adalah bahasa markup. Ini bukan format data. Kebanyakan skema XML secara eksplisit mengabaikan perbedaan ini, sehingga mengacaukan XML dengan format data, yang pada akhirnya mengakibatkan kesalahan dalam memilih XML karena format data itulah yang sebenarnya dibutuhkan.
Tanpa menjelaskan terlalu banyak detail, XML paling cocok untuk memberi anotasi pada blok teks dengan struktur dan metadata. Jika tujuan utama Anda bukan untuk bekerja dengan blok teks, memilih XML sepertinya tidak dapat dibenarkan.
Dari sudut pandang ini, ada cara sederhana untuk memeriksa seberapa baik skema XML dibuat. Mari kita ambil contoh dokumen dalam skema yang dimaksud dan hapus semua tag dan atribut darinya. Jika yang tersisa tidak masuk akal (atau jika ada baris kosong yang tersisa), skema Anda mungkin tidak dibuat dengan benar atau Anda seharusnya tidak menggunakan XML.
Di bawah ini saya akan memberikan beberapa contoh paling umum dari rangkaian yang dibangun secara tidak benar.
<roоt>
<item name="name" value="John" />
<item name="city" value="London" />
</roоt>Di sini kita melihat contoh upaya tidak berdasar dan aneh (walaupun sangat umum) untuk mengekspresikan kamus nilai kunci sederhana dalam XML. Jika Anda menghapus semua tag dan atribut, Anda akan mendapatkan baris kosong. Pada dasarnya, dokumen ini, betapapun absurdnya kedengarannya, merupakan anotasi semantik dari baris kosong.
<root name="John" city="London" />Lebih buruk lagi, kami tidak hanya memiliki anotasi semantik dari string kosong di sini sebagai cara yang berlebihan untuk mengekspresikan kamus - kali ini "kamus" secara langsung dikodekan sebagai atribut elemen root. Hal ini membuat kumpulan nama atribut tertentu pada suatu elemen tidak terdefinisi dan dinamis. Selain itu, hal ini menunjukkan bahwa yang benar-benar ingin diungkapkan oleh penulis hanyalah sintaksis nilai kunci yang sederhana, namun ia malah membuat keputusan yang sangat aneh untuk menerapkan XML, memaksa penggunaan satu elemen kosong hanya sebagai awalan untuk menggunakan sintaksis atribut. Dan saya sangat sering menjumpai skema seperti itu.
<roоt>
<item key="name">John</item>
<item key="city">London</item>
</roоt>Ini adalah sesuatu yang lebih baik, tetapi sekarang karena alasan tertentu kuncinya adalah metadata dan nilainya tidak. Pandangan yang sangat aneh pada kamus. Jika Anda menghapus semua tag dan atribut, separuh informasinya akan hilang.
Ekspresi kamus yang benar dalam XML akan terlihat seperti ini:
<roоt>
<item>
<key>Name</key>
<value>John</value>
</item>
<item>
<key>City</key>
<value>London</value>
</item>
</roоt>Namun jika orang telah membuat keputusan aneh untuk menggunakan XML sebagai format data dan kemudian menggunakannya untuk mengatur kosa kata, maka mereka harus memahami bahwa apa yang mereka lakukan tidak pantas dan tidak nyaman. Seringkali juga desainer salah memilih XML untuk membuat aplikasi mereka. Namun lebih sering lagi, mereka memperburuk keadaan dengan menggunakan XML dalam salah satu bentuk yang dijelaskan di atas secara sia-sia, mengabaikan fakta bahwa XML tidak cocok untuk ini.
Skema XML Terburuk? Omong-omong, hadiahnya untuk skema XML terburuk yang pernah saya lihat, Mendapatkan format file konfigurasi penyediaan otomatis untuk telepon IP Polycom. File tersebut memerlukan pengunduhan file permintaan XML melalui TFTP, yang... Secara umum, berikut adalah kutipan dari salah satu file tersebut:
<softkey
softkey.feature.directories="0"
softkey.feature.buddies="0"
softkey.feature.forward="0"
softkey.feature.meetnow="0"
softkey.feature.redial="1"
softkey.feature.search="1"
softkey.1.enable="1"
softkey.1.use.idle="1"
softkey.1.label="Foo"
softkey.1.insert="1"
softkey.1.action="..."
softkey.2.enable="1"
softkey.2.use.idle="1"
softkey.2.label="Bar"
softkey.2.insert="2"
softkey.2.action="..." />Ini bukan lelucon buruk seseorang. Dan ini bukan penemuan saya:
- elemen hanya digunakan sebagai awalan untuk melampirkan atribut, yang memiliki nama hierarki.
- Jika Anda ingin menetapkan nilai ke beberapa instance dari jenis rekaman tertentu, Anda harus menggunakan nama atribut untuk melakukannya. yang memiliki indeks.
- Selain itu, atribut dimulai dengan
softkey., harus ditempatkan pada elemen<softkey/>, atribut dimulai denganfeature., harus ditempatkan pada elemen<feature/>dll., meskipun pada kenyataannya hal itu terlihat sama sekali tidak perlu dan pada pandangan pertama tidak ada artinya. - Dan terakhir, jika Anda berharap komponen pertama dari nama atribut akan selalu sama dengan nama elemen - tidak seperti itu! Misalnya atribut
up.harus dilampirkan<userpreferences/>. Urutan penambahan nama atribut ke elemen bersifat arbitrer, hampir seluruhnya.
Dokumen atau data. Sesekali, seseorang melakukan sesuatu yang sangat aneh dengan mencoba membandingkan XML dan JSON—dan dengan demikian menunjukkan bahwa mereka juga tidak memahaminya. XML adalah bahasa markup dokumen. JSON adalah format data terstruktur, jadi membandingkannya satu sama lain seperti mencoba membandingkan hangat dengan lembut.
Konsep perbedaan antara dokumen dan data. Sebagai analogi XML, kita dapat mengambil dokumen yang dapat dibaca mesin secara kondisional. Meskipun dimaksudkan agar dapat dibaca oleh mesin, secara metaforis mengacu pada dokumen, dan dari sudut pandang ini sebenarnya sebanding dengan dokumen PDF, yang seringkali tidak dapat dibaca oleh mesin.
Misalnya, dalam XML, urutan elemen penting. Namun di JSON, urutan pasangan nilai kunci dalam objek tidak ada artinya dan tidak terdefinisi. Jika Anda ingin mendapatkan kamus pasangan nilai kunci yang tidak berurutan, urutan sebenarnya kemunculan elemen dalam file tersebut tidak menjadi masalah. Namun Anda dapat membentuk berbagai jenis data dari data ini. dokumen, karena ada urutan tertentu dalam dokumen tersebut. Secara metaforis dianalogikan dengan dokumen di atas kertas, meskipun tidak memiliki dimensi fisik, tidak seperti hasil cetakan atau file PDF.
Contoh saya tentang representasi kamus XML yang tepat menunjukkan urutan elemen dalam kamus, berbeda dengan representasi JSON. Saya tidak bisa mengabaikan urutan ini: linearitas ini melekat pada model dokumen dan format XML. Beberapa orang mungkin memilih untuk mengabaikan urutan ketika menafsirkan dokumen XML ini, namun tidak ada gunanya berdebat mengenai hal ini karena masalah ini berada di luar cakupan diskusi tentang format itu sendiri. Selain itu, jika Anda membuat dokumen dapat dilihat di browser dengan melampirkan lembar gaya berjenjang ke dalamnya, Anda akan melihat bahwa elemen kamus muncul dalam urutan tertentu dan tidak dalam urutan lain.
Dengan kata lain, kamus (sepotong data terstruktur) dapat diubah menjadi n berbagai kemungkinan dokumen (dalam XML, PDF, kertas, dll.), di mana n - jumlah kemungkinan kombinasi elemen dalam kamus, dan kami belum memperhitungkan kemungkinan variabel lain.
Namun, jika Anda hanya ingin mentransfer data, maka menggunakan dokumen yang dapat dibaca mesin tidak akan efektif. Ia menggunakan sebuah model, yang dalam hal ini tidak berguna; ia hanya akan menghalangi. Selain itu, untuk mengekstrak data sumber, Anda perlu menulis sebuah program. Hampir tidak ada gunanya menggunakan XML untuk sesuatu yang tidak akan diformat sebagai dokumen di beberapa titik (misalnya, menggunakan CSS atau XSLT, atau keduanya), karena itulah alasan utama (jika bukan satu-satunya) untuk melakukannya. ke model dokumen.
Selain itu, karena XML tidak memiliki konsep angka (atau ekspresi Boolean, atau tipe data lainnya), semua angka yang direpresentasikan dalam format ini dianggap hanya teks tambahan. Untuk mengekstrak data, skema dan hubungannya dengan data terkait yang diungkapkan harus diketahui. Anda juga perlu mengetahui kapan, berdasarkan konteksnya, elemen teks tertentu mewakili angka dan harus dikonversi menjadi angka, dll.
Dengan demikian, proses mengekstraksi data dari dokumen XML tidak jauh berbeda dengan proses mengenali dokumen pindaian yang berisi, misalnya tabel yang membentuk banyak halaman data numerik. Ya, pada prinsipnya hal ini dapat dilakukan, tetapi ini bukanlah cara yang paling optimal, kecuali sebagai upaya terakhir, ketika sama sekali tidak ada pilihan lain. Solusi yang masuk akal adalah dengan menemukan salinan digital dari data asli yang tidak tertanam dalam model dokumen yang menggabungkan data dengan representasi tekstual spesifiknya.
Meskipun demikian, saya tidak terkejut sama sekali bahwa XML populer dalam bisnis. Alasannya justru karena format dokumen (di atas kertas) dapat dimengerti dan familiar bagi bisnis, dan mereka ingin terus menggunakan model yang familiar dan mudah dipahami. Untuk alasan yang sama, bisnis terlalu sering menggunakan dokumen PDF dibandingkan format yang lebih mudah dibaca mesin - karena masih terikat pada konsep halaman cetak dengan ukuran fisik tertentu. Hal ini bahkan berlaku untuk dokumen yang kemungkinan tidak akan pernah dicetak (misalnya, dokumentasi registri PDF setebal 8000 halaman). Dari sudut pandang ini, penggunaan XML dalam bisnis pada dasarnya merupakan manifestasi dari skeuomorfisme. Orang-orang memahami gagasan metaforis dari halaman cetak berukuran terbatas, dan mereka memahami cara membuat proses bisnis berdasarkan dokumen cetak. Jika itu panduan Anda, dokumen tanpa batasan ukuran fisik yang dapat dibaca mesin—dokumen XML—mewakili inovasi sekaligus menjadi rekanan dokumen yang familiar dan nyaman. Hal ini tidak mencegah mereka untuk tetap menggunakan cara penyajian data yang salah dan terlalu skeuomorfik.
Sampai saat ini, satu-satunya skema XML yang saya tahu yang benar-benar dapat saya sebut sebagai penggunaan format yang valid adalah XHTML dan DocBook.
Sumber: www.habr.com