Bahasa XML ditemukan pada tahun 1996. Dia hampir tidak muncul sebelum kemungkinan penerapannya sudah mulai disalahpahami, dan untuk tujuan yang mereka coba adaptasi, dia bukan pilihan terbaik.
Ini tidak akan berlebihan untuk mengatakan bahwa sebagian besar skema XML yang saya lihat tidak pantas atau penyalahgunaan XML. Selain itu, penggunaan XML ini membuktikan kesalahpahaman mendasar tentang apa itu XML.
XML adalah bahasa markup.
Ini bukan format data . Dalam sebagian besar skema XML, perbedaan ini tidak secara eksplisit diperhitungkan, membingungkan XML dengan format data, yang pada akhirnya berarti kesalahan dalam pemilihan XML, karena sebenarnya format data diperlukan.
Tanpa merinci, XML paling baik untuk membubuhi keterangan blok teks dengan struktur dan metadata. Jika tugas utama Anda bukan untuk bekerja dengan blok teks, pilihan XML tidak mungkin dibenarkan.
Dari sudut pandang ini, ada cara mudah untuk memeriksa seberapa baik skema XML dibuat. Ambil contoh dokumen dalam skema yang diusulkan dan hapus semua tag dan atribut dari itu. Jika tidak ada gunanya apa yang tersisa (atau jika string kosong tetap), maka skema Anda tidak dibangun dengan benar, atau Anda seharusnya tidak menggunakan XML.
Di bawah ini saya akan memberikan beberapa contoh paling umum dari rangkaian yang salah dibangun.
<rot> <item name="name" value="John" /> <item name="city" value="London" /> </rot>
Di sini kita melihat contoh dari upaya yang tidak masuk akal dan aneh (meskipun sangat luas) untuk mengekspresikan kamus nilai kunci sederhana dalam XML. Jika Anda menghapus semua tag dan atribut, baris kosong akan tetap ada. Pada dasarnya, dokumen ini adalah, tidak peduli seberapa absurd mungkin terdengar, penjelasan semantik dari baris kosong.
<root name="John" city="London" />
Untuk membuat keadaan menjadi lebih buruk, kami di sini tidak hanya memiliki anotasi semantik dari baris kosong sebagai cara mewah untuk mengekspresikan kamus - kali ini "kamus" secara langsung dikodekan sebagai atribut dari elemen root. Karena itu, sekumpulan nama atribut pada elemen menjadi tidak terdefinisi dan dinamis. Selain itu, jelas dari sini bahwa semua yang penulis benar-benar ingin ungkapkan adalah sintaks kunci-nilai sederhana, tetapi sebaliknya ia membuat keputusan yang benar-benar aneh untuk menggunakan XML, memaksa penggunaan elemen kosong tunggal hanya sebagai awalan untuk menggunakan sintaks atribut. Dan skema seperti itu sering saya temui.
<rot> <item key="name">John</item> <item key="city">London</item> </rot>
Ini sudah merupakan sesuatu yang lebih baik, tetapi sekarang kuncinya adalah metadata karena suatu alasan, tetapi nilainya tidak. Pandangan yang sangat aneh pada kamus. Jika Anda menghapus semua tag dan atribut, setengah dari informasi akan hilang.
Ekspresi kamus yang benar dalam XML akan terlihat seperti ini:
<rot> <item> <key>Name</key> <value>John</value> </item> <item> <key>City</key> <value>London</value> </item> </rot>
Tetapi jika orang membuat keputusan aneh untuk menggunakan XML sebagai format data dan kemudian menggunakannya untuk mengatur kamus, maka mereka harus mengerti bahwa apa yang mereka lakukan tidak pantas dan tidak nyaman. Masih sering, desainer keliru memilih XML untuk membangun aplikasi mereka. Tetapi bahkan lebih sering, mereka memperburuk situasi dengan menggunakan XML yang tidak masuk akal dalam salah satu bentuk yang dijelaskan di atas, mengabaikan fakta bahwa XML sama sekali tidak cocok untuk ini.
Skema XML Terburuk? Omong-omong, hadiah untuk
skema XML terburuk yang pernah saya lihat mendapatkan format file konfigurasi alokasi sumber daya otomatis untuk telepon telepon IP Polycom. File-file tersebut memerlukan memuat file permintaan XML melalui TFTP, yang ... Secara umum, berikut adalah kutipan dari satu file seperti itu:
<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. Dan ini bukan penemuan saya:
- elemen hanya digunakan sebagai awalan untuk melampirkan atribut, yang mereka sendiri memiliki nama hierarkis.
- Jika Anda ingin menetapkan nilai ke beberapa instance dari catatan jenis tertentu, Anda perlu menggunakan nama atribut di mana ada indeks .
- Selain itu, atribut dimulai dengan
softkey. , Anda perlu menempatkan pada elemen <softkey/> , atribut dimulai dengan feature. , harus ditempatkan pada elemen <feature/> , dll., terlepas dari kenyataan bahwa itu terlihat sepenuhnya berlebihan dan pada pandangan pertama tidak ada gunanya.
- Dan akhirnya, jika Anda berharap bahwa komponen pertama dari nama atribut selalu cocok dengan nama elemen - tidak seperti itu! Misalnya atribut
up. harus dilampirkan ke <userpreferences/> . Urutan melampirkan nama atribut ke elemen sewenang-wenang, dan hampir sepenuhnya.
Dokumen atau data . Dari waktu ke waktu, seseorang melakukan hal-hal yang benar-benar aneh, mencoba membandingkan XML dan JSON - dan dengan demikian menunjukkan bahwa ia tidak memahami satu atau yang lain. XML adalah bahasa markup dokumen. JSON adalah format data terstruktur, jadi membandingkannya satu sama lain seperti mencoba membandingkan hangat ke lembut.
Untuk memahami hal ini, konsep perbedaan antara
dokumen dan data akan membantu. Sebagai analog dari XML, Anda dapat secara sewenang-wenang mengambil dokumen yang dapat dibaca mesin. Meskipun dimaksudkan untuk dibaca oleh mesin, ini merujuk secara metaforis ke dokumen, dan dari sudut pandang ini sebenarnya dapat dibandingkan dengan dokumen PDF, yang paling sering tidak dapat dibaca oleh mesin.
Misalnya, dalam XML, urutan elemen penting. Dan di JSON, urutan pasangan kunci-nilai di dalam objek tidak masuk akal dan tidak didefinisikan. Jika Anda ingin mendapatkan kamus tidak berurutan dari pasangan nilai kunci, urutan sebenarnya yang diikuti oleh item dalam file ini tidak masalah. Tetapi Anda dapat membentuk banyak
dokumen berbeda dari data ini, karena dokumen tersebut memiliki urutan tertentu. Secara metaforis, ini adalah analog dari dokumen di atas kertas, meskipun tidak memiliki dimensi fisik, tidak seperti cetakan atau file PDF.
Dalam contoh saya tentang representasi kamus yang benar dalam XML, urutan elemen dalam kamus ditampilkan, berbeda dengan representasi dalam bahasa JSON. Saya tidak bisa mengabaikan urutan ini: linearitas seperti itu melekat pada model dokumen dan format XML. Ketika menafsirkan dokumen XML ini, seseorang mungkin memutuskan untuk mengabaikan pesanan, tetapi tidak ada gunanya untuk berdebat tentang ini, karena masalah ini melampaui membahas format itu sendiri. Selain itu, jika Anda membuat dokumen dapat dilihat di browser dengan melampirkan lembar gaya berjenjang padanya, Anda dapat melihat bahwa elemen kamus mengikuti dalam urutan tertentu, dan tidak dengan cara lain.
Dengan kata lain, kamus (sebuah fragmen data terstruktur) dapat dikonversi menjadi
n dokumen yang mungkin berbeda (dalam XML, PDF, di atas kertas, dll.), Di mana
n adalah jumlah kemungkinan kombinasi elemen dalam kamus, dan kami belum mempertimbangkan yang lain variabel yang mungkin.
Namun, ini juga mengikuti dari ini bahwa jika Anda ingin mengirimkan data sendirian, maka menggunakan dokumen yang dapat dibaca mesin untuk ini tidak akan efektif. Ini menggunakan model, yang dalam hal ini berlebihan, hanya akan mengganggu. Selain itu, untuk mengekstraksi data sumber, perlu untuk menulis sebuah program. Hampir tidak masuk akal untuk menggunakan XML untuk sesuatu yang pada tahap tertentu tidak akan diformat sebagai dokumen (katakanlah, menggunakan CSS atau XSLT, atau keduanya), karena ini adalah alasan utama (jika bukan satu-satunya) untuk itu untuk tetap berpegang pada model dokumen.
Selain itu, karena XML tidak memiliki konsep angka (atau ekspresi Boolean, atau tipe data lainnya), semua angka yang diwakili dalam format ini dianggap hanya teks tambahan. Untuk mengekstraksi data, skema dan hubungannya dengan data yang diungkapkan harus diketahui. Penting juga untuk mengetahui kapan, berdasarkan konteksnya, satu atau beberapa elemen teks adalah angka, dan harus dikonversi ke angka, dll.
Dengan demikian, proses ekstraksi data dari dokumen XML tidak jauh berbeda dari proses mengenali dokumen yang dipindai yang berisi, misalnya, tabel yang membentuk banyak halaman data numerik. Ya, pada prinsipnya adalah mungkin untuk melakukan ini, tetapi ini bukan cara yang paling optimal, kecuali dalam kasus yang ekstrim, ketika tidak ada pilihan lain sama sekali. Keputusan yang cerdas adalah menemukan salinan digital dari data asli yang tidak tertanam dalam model dokumen, di mana data tersebut dikombinasikan dengan representasi tekstual spesifik mereka.
Namun, sama sekali tidak mengejutkan saya bahwa XML populer dalam bisnis. Alasan untuk ini justru karena format dokumen (di atas kertas) dapat dimengerti dan akrab bagi bisnis, dan mereka ingin terus menggunakan model yang sudah dikenal dan dimengerti di sana. Untuk alasan yang sama, dalam bisnis terlalu sering menggunakan dokumen dalam PDF daripada lebih nyaman untuk format pemrosesan mesin - karena mereka masih terikat pada konsep halaman yang dicetak dengan ukuran fisik tertentu. Ini berlaku bahkan untuk dokumen yang tidak mungkin dicetak (misalnya, file PDF dari dokumentasi registrasi 8.000 halaman). Dari sudut pandang ini, penggunaan XML dalam bisnis pada dasarnya adalah manifestasi dari skeuomorfisme. Orang-orang memahami ide metaforis dari halaman yang dicetak dengan ukuran terbatas, dan mereka memahami cara membuat proses bisnis berdasarkan dokumen cetak. Jika ini adalah panduan Anda, dokumen tanpa ukuran fisik terbatas yang dapat dibaca mesin - dokumen XML - adalah sebuah inovasi, sekaligus menjadi analog dokumen yang akrab dan nyaman. Yang tidak mencegah mereka dari tetap menyajikan cara yang salah dan terlalu skeuomorfik untuk menyajikan data.
Sampai saat ini, satu-satunya skema XML yang saya tahu dapat benar-benar saya sebut penggunaan format ini adalah XHTML dan DocBook.