XML-i kasutatakse praktiliselt alati valesti

XML-i keel leiutati 1996. aastal. Peaaegu kohe pärast selle ilmumist hakkasid inimesed selle rakendamise võimalusi valesti mõistma ning selleks, mille jaoks seda prooviti kohandada, ei olnud see parim valik.

Ei oleks ülemäärane öelda, et enamik XML-skeeme, mida olen näinud, kujutas endast mõttetut või vale XML-i kasutamist. Veelgi enam, selline XML-i rakendamine näitas põhjalikku arusaamatust selle kohta, millega XML eelkõige on.

XML on märgistuskeel. See ei ole andmevorming. Enamikus XML-skeemides seda eristust selgelt ei arvestatud, segades XML-i andmevorminguga, mis lõppkokkuvõttes tähendas, et XML-i valik ise oli vale, kuna tegelikult oli vajalik just andmevorming.

Ilma detailidesse laskumata sobib XML kõige paremini struktureeritud teksti ja metaandmetega plokkide annotatsiooniks. Kui teie peamine ülesanne ei ole töötada tekstiplokiga, ei pruugi XML-i valik olla põhjendatud.

Sellest vaatepunktist on lihtne viis kontrollida, kui hästi on XML-skeem koostatud. Võtame näiteks dokumendi eeldatavas skeemis ja eemaldame kõik sildid ja atribuudid. Kui jääb midagi mõtetust (või kui jääb tühi rida), siis on kas teie skeem valesti koostatud või ei olnud XML-i kasutamine lihtsalt otstarbekas.

Edasi toon mõned kõige sagedamini esinevad valesti koostatud skeemide näited.

Siin näeme põhjendamata ja kummalist (kuigi üsna levinud) katset väljendada XML-i keeles lihtsat sõnastikku «võti-väärtus». Kui eemaldada kõik sildid ja atribuudid, jääb tühi rida. Tegelikult esindab see dokument — kui absurdne see ka ei tunduks — semantilist annotatsiooni tühi rida.

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

Miski veel hullem, meil pole siin lihtsalt semantilist annotatsiooni tühjast reast kui ekstsentriline viis sõnavara väljendamiseks — seekord on „sõnavara“ otseselt kodeeritud juuri elementide atribuutidena. Seetõttu muutub määratletud atribuutide nimede kogum elemendil määramatuks ja dünaamiliseks. Veelgi enam, siit on näha, et kõik, mida autor tegelikult väljendada soovis, on lihtne süntaks „võti-väärtus“, kuid selle asemel valis ta täiesti kummalise lahenduse, rakendades XML-i, sundides kasutama ühte tühja elementi lihtsalt atribuutide süntaksi eelseisjana. Ja selliste skeemidega kohtan ma väga tihti.

John
  London

See on juba mõnevõrra parem, kuid nüüd on võtmed mingil põhjusel metaandmed, mitte väärtused. Üsna kummaline vaade sõnastikele. Kui eemaldada kõik sildid ja atribuudid, kaob pool teabest.

Sõnastiku õige väljendus XML-is näeks välja umbes nii:

Nimi
    John
  
  
    Linn
    London

Kuid kui inimesed otsustavad kummaliselt kasutada XML-i andmevorminguna ning korraldada sõnastikku selle abil, peavad nad aru saama, et see, mida nad teevad, ei ole sobiv ega mugav. Tihti valivad projekteerijad valesti XML-i oma rakenduste loomiseks. Veelgi tihedamini süvendavad nad olukorda mõttetute XML-i rakendustega ühes ülaltoodud vormis, ignoreerides asjaolu, et XML ei sobi selleks lihtsalt.

Halvim XML-i skeem? Muide, auhind halvima XML-i skeemi eest, mida mul on olnud võimalus näha, minna konfiguratsioonifaili formaadi juurde, mis on mõeldud IP-telefonide Polycom automaatseks ressursijagamiseks. Sellised failid nõuavad TFTP kaudu XML-päringufailide laadimist, mis... Kokkuvõttes, siin on lõik ühest sellisest failist:

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

See ei ole kellegi naljakas nali. Ja see ei ole ka minu väljamõeldis:

• elemendid kasutatakse lihtsalt prefiksina atribuutide lisamiseks, mis omavad hierarhilisi nimesid.
• Kui on vajalik lisada väärtusi mitmele rekordite eksemplarile, tuleb kasutada atribuutide nimesid, millel on indeksid.
• Lisaks sellele tuleb atribuudid, mis algavad softkey.paigutada elementidele <softkey/>ja atribuudid, mis algavad feature.paigutada elementidele <feature/> jne., kuigi see näeb välja täiesti liialdatud ja esmapilgul mõttetu.
• Ja lõpuks, kui lootsite, et atribuutide nime esimene komponent sobib alati elemendi nimega — ei! Näiteks atribuudid up. peavad olema seotud <userpreferences/>. Atribuutide nimede kinnitamise kord on vabalt valitud ja praktiliselt täielik.

Dokumendid või andmed. Üksikute isikute poolt aeg-ajalt tehakse täiesti kummalisi asju, püüdes võrrelda XML-i ja JSON-i — sellega näidates, et ei mõista kumbagi. XML on dokumentide märgistuskeel. JSON on aga struktuurse andmeformaadi kujul, nii et nende omavaheline võrdlemine on sama, mis püüda võrrelda sooja külmaga.

Sellesse arusaamisse aitab mõisted dokumentide ja andmete erinevus. XML-i analoogina võib soovitada masinloetavat dokumenti. Kuigi see on mõeldud masinaga lugemiseks, kuulub see metafooriliselt dokumentide hulka ning sellelt vaatenurgalt on see tegelikult võrreldav PDF formaadi dokumentidega, mis enamasti ei ole masinloetavad.

Näiteks XML-is on elementide järjekord oluline. JSON-is aga paaride «võti-väärtus» järjekord objektides ei oma tähendust ja ei ole määratletud. Kui soovite saada järjekorrast sõltumatut sõnastikku «võti-väärtus» paaridest, siis elementide tegelik järjekord selles failis ei ole oluline. Kuid võite nende andmete põhjal luua palju erinevaid dokumente, kuna dokumendis on määratud teatud järjekord. Metaforina on see sarnane paberil dokumendile, kuigi tal ei ole füüsilisi mõõte, erinevalt väljaprintimisest või PDF-failist.

Minu näites XML-keeles sõnaraamatu õigest esitamisest on näidatud elementide järjekord, mis erineb JSON-i esitamisest. Ma ei saa seda järjekorda eirata: selline joonelisus on algselt dokumentide mudelile ja XML-formaadile omane. Keegi võib selle XML-dokumendi tõlgendamisel otsustada järjekorda ignoreerida, kuid selle üle vaielda on mõttetu, kuna see küsimus ületab arutelu ise formaadi üle. Veelgi enam, kui muuta dokument brauseris nähtavaks, lisades sellele kaskaadse stiilitabele, saab näha, et sõnaraamatu elemendid järgivad kindlat järjekorda, mitte mingis muus.

Teisisõnu, sõnaraamat (struktureeritud andmete fragment) võib olla muudetud n erinevatesse võimalikesse dokumentidesse (XML, PDF, paberil jne), kus n — elementide võimalike kombinatsioonide arv sõnaraamatus, ja see on veel enne teiste võimalike muutujate arvessevõtmist.

Samasugusel juhul on vaja arvesse võtta, et andmete edastamiseks ei oleks masinatoetava dokumendi kasutamine efektiivne. Sellisel juhul on mudel üleliigne ja takistab edasist tööd. Lisaks, et algandmeid välja tõmmata, tuleb kirjutada programm. Kahtlemata ei ole mõtet kasutada XML-formaati millegi jaoks, mille puhul mingil hetkel ei kujundata dokumenti (näiteks CSS-i või XSLT abil, või nende kombinatsiooniga), kuna just see on peamine (kui mitte ainus) põhjus dokumentide mudeli järgimiseks.

Veelgi enam, kuna XML-is ei ole numbrite, booleanide ega muude andmetüüpide mõistet, peetakse kõik selle formaadis esitatud numbreid lihtsalt täiendavaks tekstiks. Andmete väljatõmbamiseks peab olema teada skeem ja selle seosed vastava väljendatud andmega. Samuti tuleb mõista, millal konteksti põhjal esindab teatud tekstielement numbrit, ning see tuleb konverteerida numbriks jne.

Seega ei erine andmete ekstraheerimise protsess XML-dokumentidest oluliselt protsessist, mis käsitleb skaneeritud dokumentide tuvastamist, mis sisaldavad näiteks tabelite kujul mitmeleheküljelist numbrilist teavet. Jah, see on põhimõtteliselt võimalik, kuid see ei ole kõige optimaalsem lähenemine — välja arvatud äärmuslikel juhtudel, kui ei ole muid võimalusi. Mõistlik lahendus on leida digitaalne koopia algsetest andmetest, mis pole dokumendi mudelisse integreeritud, kus andmed on kokku pandud nende konkreetse tekstilise esitusega.

Ei üllata mind üldse, et XML on ettevõtluses populaarne. Selle põhjuseks on just see, et dokumendi formaat (paberil) on äritegevuses arusaadav ja tuttav ning soovitakse jätkata tuttava ja selge mudeli kasutamist. Sama põhjus on ka see, miks äri maailmas kasutatakse liiga sageli PDF-dokumente, mitte masinatega töötlemiseks sobivamaid formaate — sest nad on endiselt seotud trükitud lehe mõistega, millel on kindel füüsiline suurus. See kehtib isegi nende dokumentide kohta, mida tõenäoliselt kunagi ei trükita (näiteks 8000-leheküljeline registridokumendi PDF-fail). Selles mõttes on XML-i kasutamine ettevõtluses oma olemuselt skevomorfism. Inimestele on arusaadav trükitud lehe piiratud suuruse metafooriline idee ja nad mõistavad, kuidas luua äriprotsesse trükitud dokumentide põhjal. Kui see on teie suund, siis dokumendid, millel ei ole piiratud füüsilist suurust ja mis on masinloetavad — XML-dokumendid — esindavad innovatsiooni, olles samal ajal tuttav ja mugav dokumentide analoog. Mis ei takista neil jäämast vale ja liialt skevomorfiliseks andmete esitamise viisiks.

Praegu on ainsad teadaolevad XML-skeemid, mida ma tõeliselt õigeks rakenduseks pean, XHTML ja DocBook.

Allikas: habr.com