XML meh tansah disalahake

Basa XML diciptakake ing taun 1996. Ora suwe wis katon, kemungkinan aplikasi kasebut wis wiwit disalahake, lan kanggo tujuan sing padha nyoba adaptasi, iku dudu pilihan sing paling apik.

Ora exaggeration kanggo ngomong sing akèh-akèhé saka skema XML aku wis katon padha ora cecek utawa salah nggunakake XML. Kajaba iku, panggunaan XML iki nuduhake salah pangerten dhasar babagan apa XML.

XML minangka basa markup. Iki dudu format data. Umume skema XML kanthi jelas ora nggatekake prabédan iki, mbingungake XML karo format data, sing pungkasane nyebabake kesalahan nalika milih XML amarga format data kasebut pancen dibutuhake.

Tanpa rinci banget, XML paling cocog kanggo ngotasi blok teks kanthi struktur lan metadata. Yen tujuan utama sampeyan ora nggarap blok teks, milih XML ora bisa ditrapake.

Saka sudut pandang iki, ana cara sing gampang kanggo mriksa kepiye skema XML digawe. Ayo dadi conto dokumen ing skema sing dituju lan mbusak kabeh tag lan atribut saka iku. Yen apa sing isih ana ora ana gunane (utawa yen ana baris kosong), mula skema sampeyan ora dibangun kanthi bener utawa sampeyan ora kudu nggunakake XML.

Ing ngisor iki aku bakal menehi sawetara conto sing paling umum saka sirkuit sing ora dibangun kanthi bener.

<roоt>
  <item name="name" value="John" />
  <item name="city" value="London" />
</roоt>

Ing kene kita ndeleng conto upaya sing ora ana dhasar lan aneh (sanajan umum banget) kanggo nyebut kamus nilai kunci sing prasaja ing XML. Yen sampeyan mbusak kabeh tag lan atribut, sampeyan bakal ditinggalake kanthi baris kosong. Ateges, dokumen iki, ora ketompo carane absurd bisa muni, anotasi semantik saka baris kosong.

<root name="John" city="London" />

Kanggo nggawe masalah luwih elek, kita ora mung duwe anotasi semantik saka string kosong ing kene minangka cara boros kanggo nyebut kamus - wektu iki "kamus" langsung dienkode minangka atribut saka unsur root. Iki nggawe jeneng atribut sing diwenehake ing unsur ora ditemtokake lan dinamis. Kajaba iku, iki nuduhake yen kabeh penulis pancene pengin diekspresiake yaiku sintaks nilai kunci sing prasaja, nanging dheweke nggawe keputusan sing aneh banget kanggo ngetrapake XML, meksa nggunakake unsur kosong siji mung minangka awalan kanggo nggunakake sintaks atribut. Lan aku kerep nemoni skema kaya ngono.

<roоt>
  <item key="name">John</item>
  <item key="city">London</item>
</roоt>

Iki luwih apik, nanging saiki ana sawetara sebab kunci kasebut metadata lan nilai-nilai kasebut ora. A dipikir aneh banget ing kamus. Yen sampeyan mbusak kabeh tag lan atribut, setengah informasi bakal ilang.

Ekspresi kamus sing bener ing XML bakal katon kaya iki:

<roоt>
  <item>
    <key>Name</key>
    <value>John</value>
  </item>
  <item>
    <key>City</key>
    <value>London</value>
  </item>
</roоt>

Nanging yen wong wis nggawe keputusan aneh kanggo nggunakake XML minangka format data lan banjur digunakake kanggo ngatur vocabulary, banjur padha kudu ngerti apa sing lagi dilakoni iku ora pantes lan ora trep. Biasane desainer uga salah milih XML kanggo nggawe aplikasi. Nanging malah luwih kerep, padha nggawe prakara Samsaya Awon dening meaninglessly nggunakake XML ing salah siji saka formulir diterangake ndhuwur, nglirwakake kasunyatan sing XML mung ora cocok kanggo iki.

Skema XML paling awon? Miturut cara, hadiah kanggo skema XML paling ala sing wis dakdeleng, Entuk format file konfigurasi provisioning otomatis kanggo telpon Polycom IP telephony. File kasebut mbutuhake ngundhuh file panjalukan XML liwat TFTP, sing ... Umumé, iki minangka kutipan saka salah sawijining file kasebut:

<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="..." />

Iki dudu guyonan ala wong liya. Lan iki dudu penemuanku:

• unsur mung digunakake minangka awalan kanggo masang atribut, kang dhewe duwe jeneng hirarkis.
• Yen sampeyan pengin menehi nilai menyang macem-macem kasus saka jinis rekaman tartamtu, sampeyan kudu nggunakake jeneng atribut kanggo nindakake iki. sing duwe indeks.
• Kajaba iku, atribut diwiwiti karo softkey., kudu diselehake ing unsur <softkey/>, atribut diwiwiti karo feature., kudu diselehake ing unsur <feature/> etc., senadyan kasunyatan sing katon rampung rasah lan ing kawitan marketing meaningless.
• Lan pungkasane, yen sampeyan ngarep-arep yen komponen pisanan saka jeneng atribut mesthi padha karo jeneng unsur - ora kaya ngono! Contone, atribut up. kudu digandhengake karo <userpreferences/>. Urutan masang jeneng atribut menyang unsur iku sembarang, meh rampung.

Dokumen utawa data. Kadhangkala, ana wong sing nindakake perkara sing aneh kanthi nyoba mbandhingake XML lan JSON-lan kanthi mangkono nuduhake manawa dheweke uga ora ngerti. XML minangka basa markup dokumen. JSON minangka format data terstruktur, mula mbandhingake siji liyane kaya nyoba mbandhingake anget karo alus.

Konsep saka prabédan antarane dokumen lan data. Minangka analog XML, kita bisa njupuk dokumen sing bisa diwaca kanthi mesin. Senajan iku dimaksudaké kanggo mesin diwaca, nuduhake metaphorically kanggo dokumen, lan saka sudut pandang iki bener iso dibandhingke kanggo dokumen PDF, kang paling asring ora mesin diwaca.

Contone, ing XML urutan unsur penting. Nanging ing JSON, urutan pasangan kunci-nilai ing obyek ora ana gunane lan ora ditemtokake. Yen sampeyan pengin njaluk kamus unordered pasangan kunci-nilai, urutan nyata sing unsur katon ing file sing ora Matter. Nanging sampeyan bisa mbentuk macem-macem jinis data saka data iki. saka dokumen, amarga ana urutan tartamtu ing dokumen kasebut. Secara metaforis, padha karo dokumen ing kertas, sanajan ora duwe dimensi fisik, ora kaya file cetak utawa PDF.

Conto perwakilan kamus XML sing tepat nuduhake urutan unsur ing kamus, minangka lawan saka perwakilan JSON. Aku ora bisa nglirwakake urutan iki: linearity iki gawan ing model document lan format XML. Sawetara bisa milih kanggo nglirwakake pesenan nalika interpretasi dokumen XML iki, nanging ora ana gunane kanggo mbantah babagan iki amarga masalah kasebut ngluwihi ruang lingkup diskusi babagan format kasebut. Kajaba iku, yen sampeyan nggawe dokumen bisa dideleng ing browser kanthi nempelake lembar gaya cascading, sampeyan bakal weruh manawa unsur kamus katon ing urutan tartamtu lan ora ana liyane.

Ing tembung liya, kamus (sepotong data terstruktur) bisa diowahi dadi n macem-macem dokumen bisa (ing XML, PDF, kertas, etc.), ngendi n - jumlah kemungkinan kombinasi unsur ing kamus, lan kita durung dijupuk menyang akun variabel liyane bisa.

Nanging, uga nderek yen sampeyan mung pengin nransfer data, banjur nggunakake dokumen sing bisa diwaca mesin ora bakal efektif. Iku nggunakake model, kang ing kasus iki superfluous mung bakal njaluk ing dalan. Kajaba iku, kanggo ngekstrak data sumber, kudu nulis program. Ora ana gunane nggunakake XML kanggo soko sing ora bakal diformat minangka dokumen ing sawetara titik (umpamane, nggunakake CSS utawa XSLT, utawa loro-lorone), amarga iku alesan utama (yen ora mung) kanggo nindakake menyang model dokumen.

Kajaba iku, amarga XML ora duwe konsep angka (utawa ekspresi Boolean, utawa jinis data liyane), kabeh nomer sing dituduhake ing format iki dianggep mung teks tambahan. Kanggo ngekstrak data, skema lan hubungane karo data sing cocog kudu dingerteni. Sampeyan uga kudu ngerti kapan, adhedhasar konteks, unsur teks tartamtu makili nomer lan kudu diowahi dadi nomer, etc.

Mangkono, proses ngekstrak data saka dokumen XML ora beda banget karo proses ngenali dokumen sing dipindai sing ngemot, contone, tabel sing mbentuk akeh kaca data numerik. Ya, bisa ditindakake kanthi prinsip, nanging iki dudu cara sing paling optimal, kajaba minangka pilihan pungkasan, nalika pancen ora ana pilihan liyane. Solusi sing cukup yaiku mung golek salinan digital saka data asli sing ora dilebokake ing model dokumen sing nggabungake data karo perwakilan teks tartamtu.

Yen ngandika, iku ora surprise kula ing kabeh XML populer ing bisnis. Alesan kanggo iki sabenere format document (ing kertas) dingerteni lan menowo kanggo bisnis, lan padha arep kanggo terus nggunakake model menowo lan dingerteni. Kanggo alasan sing padha, bisnis kerep banget nggunakake dokumen PDF tinimbang format sing bisa diwaca mesin - amarga isih ana gandhengane karo konsep kaca sing dicithak kanthi ukuran fisik tartamtu. Iki malah ditrapake kanggo dokumen sing ora bisa dicithak (contone, PDF dokumentasi registri 8000 halaman). Saka sudut pandang iki, panggunaan XML ing bisnis sejatine minangka manifestasi skeuomorphism. Wong ngerti gagasan metaforis saka kaca sing dicithak kanthi ukuran winates, lan ngerti carane nggawe proses bisnis adhedhasar dokumen sing dicithak. Yen iku pandhuan sampeyan, dokumen tanpa watesan ukuran fisik sing bisa diwaca mesin-dokumen XML-makili inovasi nalika dadi mitra dokumen sing akrab lan nyaman. Iki ora nyegah wong-wong mau supaya tetep dadi cara sing salah lan kebacut skeuomorphic kanggo nampilake data.

Nganti saiki, siji-sijine skema XML sing aku ngerti yen aku bisa nelpon nggunakake format sing bener yaiku XHTML lan DocBook.

Source: www.habr.com