Bahasa XML telah dicipta pada tahun 1996. Tidak lama kemudian ia muncul daripada kemungkinan penggunaannya telah mula disalahfahamkan, dan untuk tujuan yang mereka cuba menyesuaikannya, ia bukanlah pilihan terbaik.
Tidak keterlaluan untuk mengatakan bahawa sebahagian besar skema XML yang saya lihat adalah penggunaan XML yang tidak sesuai atau tidak betul. Selain itu, penggunaan XML ini menunjukkan salah faham asas tentang apa itu XML.
XML ialah bahasa penanda. Ini bukan format data. Kebanyakan skema XML secara eksplisit mengabaikan perbezaan ini, mengelirukan XML dengan format data, yang akhirnya mengakibatkan kesilapan dalam memilih XML kerana ia adalah format data yang sebenarnya diperlukan.
Tanpa memasukkan terlalu banyak perincian, XML paling sesuai untuk menganotasi blok teks dengan struktur dan metadata. Jika matlamat utama anda bukan untuk berfungsi dengan blok teks, memilih XML tidak mungkin wajar.
Dari sudut pandangan ini, terdapat cara mudah untuk menyemak seberapa baik skema XML dibuat. Mari kita ambil sebagai contoh dokumen dalam skema yang dimaksudkan dan alih keluar semua teg dan atribut daripadanya. Jika apa yang tinggal tidak masuk akal (atau jika terdapat baris kosong yang tinggal), maka sama ada skema anda tidak dibina dengan betul atau anda tidak sepatutnya menggunakan XML.
Di bawah ini saya akan memberikan beberapa contoh yang paling biasa bagi litar yang dibina secara tidak betul.
<roΠΎt>
<item name="name" value="John" />
<item name="city" value="London" />
</roΠΎt>Di sini kita melihat contoh percubaan yang tidak berasas dan pelik (walaupun sangat biasa) untuk menyatakan kamus nilai kunci mudah dalam XML. Jika anda mengalih keluar semua teg dan atribut, anda akan ditinggalkan dengan baris kosong. Pada asasnya, dokumen ini, tidak kira betapa tidak masuk akal kedengarannya, anotasi semantik bagi baris kosong.
<root name="John" city="London" />Lebih memburukkan lagi keadaan, kami tidak hanya mempunyai anotasi semantik rentetan kosong di sini sebagai cara mewah untuk menyatakan kamus - kali ini "kamus" dikodkan secara langsung sebagai atribut unsur akar. Ini menjadikan set nama atribut yang diberikan pada elemen tidak ditentukan dan dinamik. Lebih-lebih lagi, ia menunjukkan bahawa semua yang benar-benar ingin diungkapkan oleh pengarang ialah sintaks nilai kunci yang mudah, tetapi sebaliknya dia membuat keputusan yang sangat pelik untuk menggunakan XML, memaksa penggunaan satu elemen kosong hanya sebagai awalan untuk menggunakan sintaks atribut. Dan saya sering menemui skim sedemikian.
<roΠΎt>
<item key="name">John</item>
<item key="city">London</item>
</roΠΎt>Ini adalah sesuatu yang lebih baik, tetapi sekarang atas sebab tertentu kunci adalah metadata dan nilainya tidak. Pandangan yang sangat pelik pada kamus. Jika anda mengalih keluar semua teg dan atribut, separuh maklumat akan hilang.
Ungkapan kamus yang betul dalam XML akan kelihatan seperti ini:
<roΠΎt>
<item>
<key>Name</key>
<value>John</value>
</item>
<item>
<key>City</key>
<value>London</value>
</item>
</roΠΎt>Tetapi jika orang telah membuat keputusan aneh untuk menggunakan XML sebagai format data dan kemudian menggunakannya untuk menyusun perbendaharaan kata, maka mereka harus memahami bahawa apa yang mereka lakukan adalah tidak sesuai dan tidak mudah. Ia juga biasa bagi pereka bentuk untuk tersilap memilih XML untuk mencipta aplikasi mereka. Tetapi lebih kerap, mereka memburukkan keadaan dengan menggunakan XML secara tidak bermakna dalam salah satu bentuk yang diterangkan di atas, mengabaikan fakta bahawa XML tidak sesuai untuk ini.
Skema XML Terburuk? By the way, hadiah untuk skema XML paling teruk pernah saya lihat, Mendapat format fail konfigurasi peruntukan automatik untuk telefon telefon IP Polycom. Fail sedemikian memerlukan muat turun fail permintaan XML melalui TFTP, yang... Secara umum, berikut adalah petikan daripada satu fail 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 gurauan buruk seseorang. Dan ini bukan ciptaan saya:
- elemen hanya digunakan sebagai awalan untuk melampirkan atribut, yang sendiri mempunyai nama hierarki.
- Jika anda ingin memberikan nilai kepada berbilang kejadian bagi jenis rekod tertentu, anda mesti menggunakan nama atribut untuk melakukan ini. yang mempunyai indeks.
- Selain itu, atribut bermula dengan
softkey., mesti diletakkan pada elemen<softkey/>, atribut bermula denganfeature., mesti diletakkan pada elemen<feature/>dan lain-lain, walaupun pada hakikatnya ia kelihatan sama sekali tidak perlu dan pada pandangan pertama tidak bermakna. - Dan akhirnya, jika anda berharap bahawa komponen pertama nama atribut akan sentiasa sama dengan nama elemen - tidak seperti itu! Contohnya, atribut
up.mesti dilampirkan<userpreferences/>. Urutan melampirkan nama atribut pada elemen adalah sewenang-wenangnya, hampir sepenuhnya.
Dokumen atau data. Sekali-sekala, seseorang melakukan sesuatu yang benar-benar pelik dengan cuba membandingkan XML dan JSONβdan dengan itu menunjukkan bahawa mereka juga tidak faham. XML ialah bahasa penanda dokumen. JSON ialah format data berstruktur, jadi membandingkannya antara satu sama lain adalah seperti cuba membandingkan hangat dengan lembut.
Konsep perbezaan antara dokumen dan data. Sebagai analog XML, kita boleh mengambil dokumen yang boleh dibaca mesin secara bersyarat. Walaupun ia bertujuan untuk dibaca mesin, ia merujuk secara metafora kepada dokumen, dan dari sudut pandangan ini sebenarnya setanding dengan dokumen PDF, yang selalunya tidak boleh dibaca mesin.
Sebagai contoh, dalam XML susunan elemen penting. Tetapi dalam JSON, susunan pasangan nilai kunci dalam objek tidak bermakna dan tidak ditentukan. Jika anda ingin mendapatkan kamus tidak tertib pasangan nilai kunci, susunan sebenar unsur-unsur yang muncul dalam fail itu tidak penting. Tetapi anda boleh membentuk pelbagai jenis data daripada data ini. dokumen, kerana terdapat perintah tertentu dalam dokumen. Secara metafora, ia adalah analog dengan dokumen di atas kertas, walaupun ia tidak mempunyai dimensi fizikal, tidak seperti cetakan atau fail PDF.
Contoh saya bagi perwakilan kamus XML yang betul menunjukkan susunan unsur dalam kamus, berbanding dengan perwakilan JSON. Saya tidak boleh mengabaikan pesanan ini: lineariti ini wujud dalam model dokumen dan format XML. Sesetengah mungkin memilih untuk mengabaikan perintah itu apabila mentafsir dokumen XML ini, tetapi tidak ada gunanya mempertikaikan tentang perkara ini kerana isu ini berada di luar skop perbincangan mengenai format itu sendiri. Lebih-lebih lagi, jika anda menjadikan dokumen itu boleh dilihat dalam penyemak imbas dengan melampirkan helaian gaya berlatarkan padanya, anda akan melihat bahawa unsur-unsur kamus muncul dalam susunan tertentu dan tiada yang lain.
Dalam erti kata lain, kamus (sekeping data berstruktur) boleh ditukar menjadi n pelbagai dokumen yang mungkin (dalam XML, PDF, kertas, dll.), di mana n - bilangan kemungkinan gabungan unsur dalam kamus, dan kami belum lagi mengambil kira pembolehubah lain yang mungkin.
Walau bagaimanapun, ia juga mengikut bahawa jika anda ingin memindahkan data sahaja, maka menggunakan dokumen yang boleh dibaca mesin untuk ini tidak akan berkesan. Ia menggunakan model, yang dalam kes ini tidak diperlukan; ia hanya akan menghalangnya. Di samping itu, untuk mengekstrak data sumber, anda perlu menulis program. Hampir tidak ada gunanya menggunakan XML untuk sesuatu yang tidak akan diformatkan sebagai dokumen pada satu ketika (katakan, menggunakan CSS atau XSLT, atau kedua-duanya), kerana itulah sebab utama (jika bukan satu-satunya) untuk berbuat demikian. untuk mematuhi kepada model dokumen.
Selain itu, memandangkan XML tidak mempunyai konsep nombor (atau ungkapan Boolean, atau jenis data lain), semua nombor yang diwakili dalam format ini dianggap hanya teks tambahan. Untuk mengekstrak data, skema dan hubungannya dengan data sepadan yang dinyatakan mesti diketahui. Anda juga perlu tahu bila, berdasarkan konteks, elemen teks tertentu mewakili nombor dan harus ditukar kepada nombor, dsb.
Oleh itu, proses mengekstrak data daripada dokumen XML tidak begitu berbeza daripada proses mengenal pasti dokumen yang diimbas yang mengandungi, sebagai contoh, jadual yang membentuk banyak halaman data berangka. Ya, adalah mungkin untuk melakukan ini pada dasarnya, tetapi ini bukan cara yang paling optimum, kecuali sebagai pilihan terakhir, apabila tidak ada pilihan lain. Penyelesaian yang munasabah adalah dengan hanya mencari salinan digital data asal yang tidak dibenamkan dalam model dokumen yang menggabungkan data dengan perwakilan teks khususnya.
Walau bagaimanapun, ia tidak mengejutkan saya sama sekali bahawa XML popular dalam perniagaan. Sebabnya adalah tepat kerana format dokumen (di atas kertas) boleh difahami dan biasa untuk perniagaan, dan mereka mahu terus menggunakan model yang biasa dan mudah difahami. Atas sebab yang sama, perniagaan terlalu kerap menggunakan dokumen PDF dan bukannya lebih banyak format yang boleh dibaca mesin - kerana mereka masih terikat dengan konsep halaman bercetak dengan saiz fizikal tertentu. Ini juga terpakai pada dokumen yang tidak mungkin dicetak (contohnya, PDF 8000 halaman dokumentasi pendaftaran). Dari sudut pandangan ini, penggunaan XML dalam perniagaan pada dasarnya adalah manifestasi skeuomorphism. Orang ramai memahami idea metafora halaman bercetak dengan saiz terhad, dan mereka memahami cara membuat proses perniagaan berdasarkan dokumen bercetak. Jika itu panduan anda, dokumen tanpa had saiz fizikal yang boleh dibaca mesinβdokumen XMLβmewakili inovasi sambil menjadi rakan dokumen yang biasa dan selesa. Ini tidak menghalang mereka daripada kekal sebagai cara yang tidak betul dan terlalu skeuomorphic untuk menyampaikan data.
Sehingga kini, satu-satunya skema XML yang saya tahu yang saya benar-benar boleh memanggil penggunaan format yang sah ialah XHTML dan DocBook.
Sumber: www.habr.com