XML-keel leiutati 1996. aastal. Kohe kui see ilmus, hakati selle rakendusvõimalustest juba valesti aru saama ja eesmärkide jaoks, milleks seda püüti kohandada, polnud see parim valik.
Pole liialdus öelda, et suurem osa XML-skeemidest, mida olen näinud, on XML-i sobimatu või ebaõige kasutus. Veelgi enam, selline XML-i kasutamine näitas, et XML-i sisust ei saanud aru.
XML on märgistuskeel. See ei ole andmevorming. Enamik XML-skeeme on selle eristuse selgesõnaliselt kahe silma vahele jätnud, ajades XML-i segamini andmevorminguga, mille tulemuseks on lõppkokkuvõttes viga XML-i valimisel, kuna just seda andmevormingut on tegelikult vaja.
Liiga detailidesse laskumata sobib XML kõige paremini struktuuri ja metaandmetega tekstiplokkide märkimiseks. Kui teie peamine eesmärk ei ole töötada tekstiplokiga, pole XML-i valimine tõenäoliselt õigustatud.
Sellest vaatenurgast on lihtne viis kontrollida, kui hästi XML-skeem on tehtud. Võtame näiteks dokumendi kavandatud skeemis ja eemaldame sellest kõik sildid ja atribuudid. Kui see, mis on jäänud, ei ole mõttekas (või kui on tühi rida), siis kas teie skeem pole õigesti üles ehitatud või te poleks lihtsalt pidanud kasutama XML-i.
Allpool toon mõned levinumad näited valesti ehitatud vooluringidest.
<roоt>
<item name="name" value="John" />
<item name="city" value="London" />
</roоt>Siin näeme näidet alusetust ja kummalisest (kuigi väga levinud) katsest väljendada lihtsat võtmeväärtuste sõnastikku XML-is. Kui eemaldate kõik sildid ja atribuudid, jääb teile tühi rida. Põhimõtteliselt on see dokument, ükskõik kui absurdselt see ka ei kõlaks, tühja rea semantiline annotatsioon.
<root name="John" city="London" />Asja teeb veelgi hullemaks see, et meil pole siin sõnastiku ekstravagantse väljendusviisina ainult tühja stringi semantiline annotatsioon – seekord on "sõnastik" otse kodeeritud juurelemendi atribuutidena. See muudab elemendi antud atribuutide nimede komplekti määratlemata ja dünaamiliseks. Veelgi enam, see näitab, et kõik, mida autor tegelikult tahtis väljendada, oli lihtne võtmeväärtuse süntaks, kuid selle asemel tegi ta täiesti veidra otsuse XML-i rakendamiseks, sundides atribuudi süntaksi kasutamiseks kasutama üksikut tühja elementi lihtsalt eesliitena. Ja ma puutun selliste skeemidega väga sageli kokku.
<roоt>
<item key="name">John</item>
<item key="city">London</item>
</roоt>See on midagi paremat, kuid millegipärast on võtmed metaandmed ja väärtused mitte. Väga kummaline pilk sõnaraamatutele. Kui eemaldate kõik sildid ja atribuudid, läheb pool teabest kaotsi.
Õige sõnastikuavaldis XML-is näeks välja umbes selline:
<roоt>
<item>
<key>Name</key>
<value>John</value>
</item>
<item>
<key>City</key>
<value>London</value>
</item>
</roоt>Kuid kui inimesed on teinud kummalise otsuse kasutada andmevorminguna XML-i ja seejärel kasutada seda sõnavara korrastamiseks, peaksid nad mõistma, et see, mida nad teevad, on sobimatu ja mitte mugav. Samuti on tavaline, et disainerid valivad oma rakenduste loomiseks ekslikult XML-i. Kuid veelgi sagedamini teevad need asja hullemaks, kasutades mõttetult XML-i ühel ülalkirjeldatud kujul, jättes tähelepanuta asjaolu, et XML selleks lihtsalt ei sobi.
Halvim XML-skeem? Muide, auhind selle eest halvim XML-skeem, mida ma kunagi näinud olen, Hangib Polycomi IP-telefonitelefonide automaatse varustamise konfiguratsiooni failivormingu. Sellised failid nõuavad XML-i päringufailide allalaadimist TFTP kaudu, mis... Üldiselt on siin väljavõte ü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 pole kellegi halb nali. Ja see pole minu leiutis:
- elemente kasutatakse lihtsalt eesliitena atribuutide lisamiseks, millel endal on hierarhilised nimed.
- Kui soovite määrata väärtusi teatud tüüpi kirje mitmele eksemplarile, peate selleks kasutama atribuutide nimesid. millel on indeksid.
- Lisaks atribuudid, mis algavad tähega
softkey., tuleb asetada elementidele<softkey/>, atribuudid algavad tähegafeature., tuleb asetada elementidele<feature/>jne, hoolimata sellest, et see tundub täiesti ebavajalik ja esmapilgul mõttetu. - Ja lõpuks, kui lootsite, et atribuudi nime esimene komponent on alati sama, mis elemendi nimi - ei midagi sellist! Näiteks atribuudid
up.tuleb külge kinnitada<userpreferences/>. Elementidele atribuutide nimede lisamise järjekord on suvaline, peaaegu täielikult.
Dokumendid või andmed. Aeg-ajalt teeb keegi midagi täiesti veidrat, üritades võrrelda XML-i ja JSON-i, näidates sellega, et ei saa kummastki aru. XML on dokumendi märgistuskeel. JSON on struktureeritud andmevorming, nii et nende võrdlemine on sama, mis prooviks võrrelda sooja ja pehmet.
Mõiste erinevus dokumendid ja andmed. XML-i analoogina võime tinglikult võtta masinloetava dokumendi. Kuigi see on mõeldud masinloetavaks, viitab see metafooriliselt dokumentidele ja on sellest vaatenurgast tegelikult võrreldav PDF-dokumentidega, mis enamasti pole masinloetavad.
Näiteks XML-is on oluline elementide järjekord. Kuid JSON-is on võtme-väärtuste paaride järjekord objektides mõttetu ja määratlemata. Kui soovite saada järjestamata võtme-väärtuste paaride sõnastikku, ei oma elementide tegelik järjekord selles failis tähtsust. Kuid nendest andmetest saate moodustada mitut erinevat tüüpi andmeid. dokumentidest, sest dokumendis on kindel järjekord. Metafooriliselt on see analoogne paberil olevale dokumendile, kuigi erinevalt väljatrükist või PDF-failist ei ole sellel füüsilisi mõõtmeid.
Minu näide õigest XML-sõnastiku esitusest näitab sõnastikus olevate elementide järjekorda, erinevalt JSON-i esitusest. Ma ei saa seda järjekorda ignoreerida: see lineaarsus on omane dokumendimudelile ja XML-vormingule. Mõned võivad selle XML-dokumendi tõlgendamisel järjekorda eirata, kuid selle üle pole mõtet vaielda, kuna see küsimus jääb vormingu enda arutelust välja. Veelgi enam, kui muudate dokumendi brauseris vaadatavaks, lisades sellele kaskaadlaadilehe, näete, et sõnastiku elemendid kuvatakse kindlas järjekorras ja mitte muus.
Teisisõnu saab sõnastiku (struktureeritud andmete osa) teisendada n erinevaid võimalikke dokumente (XML-is, PDF-is, paberkandjal jne), kus n - võimalike elementide kombinatsioonide arv sõnastikus ja muid võimalikke muutujaid pole me veel arvesse võtnud.
Sellest aga järeldub ka see, et kui soovid edastada ainult andmeid, siis masinloetava dokumendi kasutamine selleks ei ole efektiivne. See kasutab mudelit, mis antud juhul on üleliigne, see jääb ainult teele. Lisaks peate lähteandmete väljavõtmiseks kirjutama programmi. Vaevalt on mõtet XML-i kasutada millegi jaoks, mida mingil hetkel ei vormindata dokumendina (näiteks kasutades CSS-i või XSLT-d või mõlemat), kuna see on selle peamine (kui mitte ainus) põhjus. dokumendi mudelile.
Veelgi enam, kuna XML-il pole arvude (või Boole'i avaldiste või muude andmetüüpide) mõistet, käsitletakse kõiki selles vormingus esitatud numbreid vaid lisatekstina. Andmete eraldamiseks peab olema teada skeem ja selle seos vastavate väljendatavate andmetega. Samuti peate teadma, millal konkreetne tekstielement kontekstist lähtuvalt tähistab arvu ja tuleks teisendada numbriks jne.
Seega ei erine XML-dokumentidest andmete eraldamise protsess nii palju skaneeritud dokumentide tuvastamise protsessist, mis sisaldab näiteks arvulisi lehekülgi sisaldavaid tabeleid. Jah, seda on põhimõtteliselt võimalik teha, kuid see pole kõige optimaalsem viis, välja arvatud viimase abinõuna, kui muid võimalusi pole. Mõistlik lahendus on lihtsalt leida originaalandmete digitaalne koopia, mis ei ole manustatud dokumendimudelisse, mis ühendab andmed nende konkreetse tekstilise esitusega.
Sellegipoolest ei üllata mind üldse, et XML on äris populaarne. Põhjus on just nimelt selles, et dokumendiformaat (paberil) on ettevõtlusele arusaadav ja tuttav ning soovitakse ka edaspidi kasutada tuttavat ja arusaadavat mudelit. Samal põhjusel kasutavad ettevõtted liiga sageli masinloetavate vormingute asemel PDF-dokumente – kuna need on endiselt seotud kindla füüsilise suurusega prinditud lehe kontseptsiooniga. See kehtib isegi dokumentide kohta, mida tõenäoliselt kunagi ei prindita (nt 8000-leheküljeline registridokumentatsiooni PDF-fail). Sellest vaatenurgast on XML-i kasutamine ettevõtluses sisuliselt skeuomorfismi ilming. Inimesed mõistavad piiratud suurusega trükitud lehe metafoorilist ideed ja mõistavad, kuidas luua trükitud dokumentide põhjal äriprotsesse. Kui see on teie juhend, esindavad ilma füüsilise suuruse piiranguteta masinloetavad dokumendid – XML-dokumendid – innovatsiooni, olles samas tuttavad ja mugavad dokumendi vasted. See ei takista neil jäämast valeks ja liiga skeuomorfseks andmete esitamise viisiks.
Praeguseks on ainsad XML-skeemid, mida ma tean, mida võin vormingu õigeks kasutamiseks nimetada, XHTML ja DocBook.
Allikas: www.habr.com