XML kasutatakse praktiliselt alati vale eesmärgi jaoks

XML keel loodi 1996. aastal. Peaaegu kohe pärast selle ilmumist hakkasid selle rakendamise võimalusi valesti mõistetama, ja eesmärkide jaoks, mille järgi prooviti seda kohandada, ei olnud see parim valik.

Ei ole liialdus öelda, et suurem osa XML skeeme, mida olen näinud, on olnud mõttetu või vale kasutamine XML-ist. Veelgi enam, selline XML-i rakendamine näitab põhimõttelist arusaamatust sellest, mis XML tegelikult on.

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

Kui mitte minna detailidesse, siis sobib XML kõige paremini tekstilõikude struktuuri ja metaandmetega annotatsiooniks. Kui teie peamine eesmärk ei ole töötada tekstilõikidega, siis pole XML-i valik tõenäoliselt õigustatud.

Selle vaatenurgast on lihtne viis kontrollida, kui hästi on XML skeem tehtud. Võtame näiteks dokumendi ettepanekuga skeemis ja kustutame kõik sildid ning atribuudid. Kui allesjäänud tekstis ei ole mõtet (või kui jääb tühi rida), siis on teie skeem kas valesti üles ehitatud või ei olnud XML-i kasutamine lihtsalt õigustatud.

Järgnevalt tutvustan mõningaid kõige levinumaid valesti üles ehitatud skeeme.

Siin näeme näidet põhjendamatu ja kummalise (kuigi üsna levinud) katse kohta väljendada XML-i keeles lihtsat «võti-väärtus» sõnastikku. Kui kustutada kõik sildid ja atribuudid, jääb alles tühi rida. Sisuliselt esindab see dokument, kuigi see võib tunduda absurdne, semantilist annotatsiooni tühjale reale.

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

Veel hullem, meil pole siin lihtsalt semantilist tühja rida sõnastiku erakordse väljendamise viisina — seekord on "sõnastik" otse kodeeritud juureelemendi atribuutide näol. Seetõttu muutub määratud atribuutide nimekiri elemendil määramatuks ja dünaamiliseks. Veelgi enam, siin on selgelt näha, et kõik, mida autor tegelikult väljendada tahtis, on lihtne süntaks "võti-väärtus", kuid selle asemel valis ta täiesti kummalise lahenduse rakendada XML-i, sunniviisiliselt määrates tühja elemendi kasutamise lihtsalt atribuutide süntaksi eelprefiksina. Sellised skeemid satuvad mulle väga sageli.

John
  London

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

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

Name
    John
  
  
    City
    London

Aga kui inimesed on teinud kummalise otsuse rakendada XML-i andmeformaadina ja seejärel selle abil sõnastikku korraldada, peavad nad mõistma, et see, mida nad teevad, on sobimatu ja ebamugav. Sageli valivad projekteerijad ekslikult XML-i oma rakenduste loomiseks. Veelgi sagedamini süvendavad nad olukorda mõttetuks XML-i rakendamisega ühes ülaltoodud vormis, ignoreerides fakti, et XML pole selleks lihtsalt sobiv.

Halvim XML-skeem? Muide, auhind halvima XML-skeemi eest, mida olen kunagi näinud, läheb Polycomi IP-telefonide automaatsete ressursihalduse seadete konfiguratsioonifailivormingule. Sellised failid nõuavad XML-i laadimist TFTP kaudu, mis... Ühesõnaga, siin on katkend ü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 halb nalja. Ja see ei ole minu väljamõeldis:

• elemendid kasutatakse lihtsalt eelsõnana atribuutide kinnitamiseks, millel endil on hierarhilised nimed.
• Kui on vajalik lisada väärtusi mitmele ülesande eksemplarile, siis tuleb kasutada atribuutide nimesid, millel on indeksid.
• Lisaks sellele tuleb atribuudid, mis algavad softkey., paigutada elementidele <softkey/>, atribuudid, mis algavad feature., paigutada elementidele <feature/> jne., hoolimata sellest, et see tundub täiesti üleliigne ja esmapilgul mõttetu.
• Ja lõpuks, kui loodsite, et atribuudi nime esimene komponent langeb alati kokku elemendi nimega — seda ei juhtu! Näiteks atribuudid up. peavad olema kinnitatud <userpreferences/>. Atribuutide nimede kinnitamise järjekord elementidele on meelevaldne ja praktiliselt täielik.

Dokumendid või andmed. Aeg-ajalt tegeleb keegi täiesti kummaliste asjadega, püüdes võrrelda XML-i ja JSON-i — ning näitab seeläbi, et ei mõista kumbagi. XML on dokumentide märgistamise keel. JSON on aga struktureeritud andmete formaat, nii et nende omavaheline võrdlemine on nagu proovida võrrelda sooja ja pehmet.

Selle mõistmisel aitab arusaam erinevusest dokumendid ja andmed. XML-i analoogina võib tinglikult võtta masinloetava dokumendi. Kuigi see on mõeldud masina lugemiseks, viitab see metafooriliselt dokumentidele ja on seega tõeliselt võrreldav PDF formaadi dokumentidega, mis enamasti pole masinloetavad.

Näiteks XML-is on elementide järjekord tähtis. JSON-is aga ei oma objektide sees «võti-väärtus» paaride järjekord mõtet ja ei ole määratud. Kui soovite saada järjestamata sõnastikku «võti-väärtus» paaridest, siis ei ole selle faili elementide tõeline järjekord oluline. Kuid saate nende andmete põhjal luua palju erinevaid dokumente, kuna dokumendis on kindel järjekord. Metafooriliselt on see sarnane paberdokumendile, kuigi tal ei ole füüsilisi mõõtmeid, nagu trükitud lehe või PDF-faili puhul.

Minu näites on XML-keeles sõnastiku esitlemise õige korraldus, mis näitab elementide järjestust sõnastikus, erinevalt esitlemisest JSON-keeles. Ma ei saa seda järjekorda ignoreerida: selline lineaarne struktuur on algselt omane dokumendimudelitele ja XML-formaadile. Keegi võib selle XML-dokumendi tõlgendamisel otsustada, et ignoreerib järjekorda, kuid selle üle vaielda on mõttetu, kuna see küsimus ületab formaadi arutelu. Veelgi enam, kui dokument muuta brauseris vaadatavaks, lisades sellele kaskaadstiilide tabeli, on võimalik näha, et sõnastiku elemendid järgivad teatud järjekorda, ja mitte mingis muus.

Teisisõnu, sõnastik (struktureeritud andmete fragment) saab muuta n erinevateks võimalike dokumentideks (XML, PDF, paberil jne), kus n — sõnastikus elementide võimalike kombinatsioonide arv, ja me ei ole veel arvesse võtnud teisi võimalikke muutujaid.

Samas tuleneb sellest ka see, et kui soovite edastada ainult andmeid, siis ei ole masinloetava dokumendi kasutamine tõhus. Seal kasutatakse mudelit, mis on sel juhul liig, see ainult segab. Lisaks tuleb algandmete välja ekstraktimiseks kirjutada programm. Keeruline on leida mõtet kasutada XML-i millegi jaoks, mis mingil hetkel ei formeerita dokumendiks (ütleme, CSS või XSLT abil, või mõlema abiga), kuna see on peamine (kui mitte ainus) põhjus, et jääda dokumendimudeli juurde.

Veelgi enam, kuna XML-is ei ole numbrite (või boolean-väljendite või teiste andmetüüpide) mõistet, loetakse selles formaadis esitatud numbreid vaid täiendavaks tekstiks. Andmete ekstrakteerimiseks peab olema teada skeem ja selle seos vastava väljendatud andmetega. Samuti peab olema selge, millal konteksti põhjal esindab tekstielement numbrit, ja see tuleb muuta numbriks jne.

Seega, andmete väljavõtmise protsess XML-dokumentidest ei erine eriti sellest, kuidas tuvastatakse skaneeritud dokumente, mis sisaldavad näiteks tabelit, mis koosneb paljusid lehekülgi numbreid. Jah, see on tõepoolest võimalik, kuid see pole kõige optimaalsem tee — välja arvatud äärmisel juhul, kui pole muud võimalust. Mõistlik lahendus oleks lihtsalt leida originaalsete andmete digitaalne koopia, mis ei ole dokumentide mudelisse sisse ehitatud, kus andmed on ühendatud nende konkreetse tekstilise esitusega.

Sellegipoolest ei üllata mind üldse, et XML on ettevõtetes populaarne. Selle põhjuseks on just see, et dokumentide formaat (paberil) on ettevõtetele arusaadav ja tuttav, ning nad soovivad jätkuvalt kasutada tuttavat ja selget mudelit. Sama tõttu kasutatakse ettevõtetes liiga tihti PDF-dokumente, mitte masinaliselt töödeldavaid formaate - sest nad on endiselt seotud mõistega trükitud leht, millel on kindel füüsiline suurus. See kehtib isegi nende dokumentide kohta, mis tõenäoliselt kunagi ei trükitakse (näiteks 8000-leheküljeline PDF-fail registri dokumentatsioonist). Sellest vaatepunktist on XML-i kasutamine ettevõtetes sisuliselt skevomorfism. Inimestele on arusaadav metafoorne idee piiratud suurusega trükitud lehe kohta ja nad mõistavad, kuidas luua äri protsesse trükitud dokumentide põhjal. Kui see on teie suunanäitajaks, siis piiramatud füüsilise suurusega, masinloetavad dokumendid — XML-dokumendid — esindavad innovatsiooni, olles samas tuttav ja mugav dokumentide analoog. Mis ei takista neil jäämast vale ja liiga skevomorfiliseks andmete esitamise viisiks.

Praegu on ainsad XML-skeemid, mida ma tõeliselt saan nimetada selle formaadi õigeteks rakendusteks, XHTML ja DocBook.

Allikas: habr.com