XML se praktično uvijek koristi neusklađeno

XML jezik je izumljen 1996. godine. Čim je nastao, mogućnosti njegove primjene su već počele biti pogrešno shvaćene, a za one svrhe za koje su pokušavali da ga prilagode, nije bio najbolji izbor.

Ne bi bilo pretjerano reći da je ogromna većina XML shema koje sam vidio predstavljala nerazmjernu ili pogrešnu upotrebu XML-a. Štaviše, takva primjena XML-a svjedočila je o fundamentalnom nerazumijevanju onoga što XML zapravo jeste.

XML je jezik za označavanje. To nije format podataka. U većini XML shema ovo razdvajanje nije uzeto u obzir, brkajući XML s formatom podataka, što je na kraju značilo grešku u samom izboru XML-a, jer je u stvarnosti potreban bio format podataka.

U suštini, XML je najbolje prikladan za označavanje blokova teksta sa strukturom i metapodacima. Ako vaš glavni zadatak nije rad s blokovima teksta, vjerojatno odabir XML-a neće biti opravdan.

S ove tačke gledišta postoji jednostavan način da se provjeri koliko je dobro napravljena XML shema. Uzmimo, na primjer, dokument u pretpostavljenoj shemi i uklonimo sve oznake i atribute. Ako preostalo nema smisla (ili ako ostane prazna linija), onda je ili vaša shema pogrešno izgrađena, ili jednostavno niste trebali primijeniti XML.

U nastavku ću navesti nekoliko najčešćih primjera pogrešno izrađenih shema.

Ovdje vidimo primjer neopravdane i čudne (iako vrlo rasprostranjene) pokušaje da se jednostavni rječnik "ključ-vrijednost" izrazi jezikom XML-a. Ako se uklone sve oznake i atribute, ostaje prazna linija. U suštini, ovaj dokument predstavlja, koliko god to apsurdno zvučalo, semantičku anotaciju prazne linije.

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

Kar še huje, imamo tukaj ne samo semantično oznako prazne vrstice kot ekstravagantno izrazoslovje — tokrat je „slovar“ neposredno zakodiran v atributih korenskega elementa. Zaradi tega je določen nabor imen atributov na elementu nepregleden in dinamičen. Poleg tega je razvidno, da je edino, kar je avtor dejansko hotel izraziti, preprosta sintaksa „ključ-vrednost“, vendar je namesto tega sprejel povsem nenavaden pristop k uporabi XML, prisilno določa uporabo enega samega praznega elementa le kot predpono za uporabo sintakse atributov. Takšne sheme se mi zelo pogosto zgodijo.

John
  London

To je že boljše, a zdaj so ključi iz neznanega razloga metapodatki, vrednosti pa ne. Zelo nenavaden pogled na slovarje. Če odstranite vse oznake in atribute, se izgubi polovica informacij.

Pravilno izražanje slovarja v XML bi izgledalo približno tako:

Ime
    John
  
  
    Mesto
    London

Ampak če so ljudje sprejeli nenavaden pristop k uporabi XML kot podatkovnega formata in ga uporabljajo za organizacijo slovarja, potem morajo razumeti, da to, kar počnejo, ni primerno in udobno. Pogosto da oblikovalci napačno izberejo XML za izdelavo svojih aplikacij. Še pogosteje pa poslabšajo situacijo z brezsmiselno uporabo XML v eni od zgoraj opisanih oblik, ignorirajoč dejstvo, da XML za to preprosto ni primeren.

Najslabša shema XML? Mimogrede, nagrada za najslabšo shemo XML, ki sem jo videl, gre formatu datoteke za konfiguracijo avtomatskega dodeljevanja sredstev za IP-telefonijo Polycom. Takšne datoteke zahtevajo nalaganje XML datotek po TFTP, ki… Na kratko, tukaj je izsek iz ene take datoteke:

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

To ni slab smeh nekoga. In to ni moja izmišljotina:

• Elementi se preprosto uporabljajo kot predpona za pritrditev atributov, ki sami po sebi nosijo hierarhična imena.
• Če je treba dodeliti vrednosti več primerkom vnosa določenega tipa, je treba uporabiti imena atributov, ki vsebujejo indekse..
• Poleg tega je treba atribute, ki se začnejo z softkey., namestiti na elemente <softkey/>, atribute, ki se začnejo z feature., namestiti na elemente <feature/> itd., kljub temu, da se zdi popolnoma odveč in na prvi pogled brezsmisleno.
• In končno, če ste upali, da se prvi del imena atributa vedno ujema z imenom elementa — ne, ni tako! Na primer, atribute up. je treba pritrditi na .Redosled pritrditev imen atributov k elementom je poljuben, skoraj v celoti.

Dokumenti ali podatki.Občasno nekdo počne popolnoma nenavadne stvari, ko poskuša primerjati XML in JSON — ter s tem dokazuje, da ne razume niti enega niti drugega. XML je jezik za označevanje dokumentov. JSON pa je format strukturiranih podatkov, zato njihovo primerjanje med seboj ni nič drugega kot poskus primerjanja toplih in mehkih stvari.

Razumevanje tega bo olajšalo razumevanje razlike med dokumenti in podatki.Kot analogija za XML lahko vzamemo strojno berljiv dokument. Čeprav je namenjen branju napravam, se metaforično nanaša na dokumente in ga je mogoče smatrati za primerljivega s PDF dokumenti, ki pogosto niso strojno berljivi.

Na primer, v XML je zaporedje elementov pomembno. V JSON-u pa vrstni red parov »ključ-vrednost« znotraj objektov nima pomena in ni določen. Če želite dobiti neporedno slovar iz parov »ključ-vrednost«, dejanski vrstni red, v katerem sledijo elementi v tem dokumentu, ni pomemben. Lahko pa iz teh podatkov oblikujete veliko različnih dokumentov,saj dokument ima določen vrstni red. Metaforično je to podobno dokumentu na papirju, četudi nima fizične velikosti v nasprotju s tiskanjem ali PDF dokumentom.

V mojem primeru pravilne predstavitve slovarja v jeziku XML je prikazan redosled elementov v slovarju, v nasprotju s predstavitvijo v jeziku JSON. Ne morem prezreti tega reda: takšna linearna narava je že v osnovi lastnost modela dokumentov in formata XML. Nekdo bi morda pri interpretaciji tega XML-dokumenta odločil, da bo red prezrl, vendar je razpravljanje o tem brezsmiselno, saj ta vprašanja izstopajo iz okvira razprave o samem formatu. Poleg tega, če dokument naredimo preglednega v brskalniku tako, da mu priložimo kaskadne sloge, lahko vidimo, da elementi slovarja sledijo določenemu redu in ne drugemu.

Drugimi besedami, slovar (fragment strukturiranih podatkov) je mogoče pretvoriti v n različne možne dokumente (v formatu XML, PDF, na papirju itd.), kjer n je število možnih kombinacij elementov v slovarju, in še nismo upoštevali drugih potencialnih spremenljivk.

Hkrati to tudi pomeni, da, če želite prenesti samo podatke, bo uporaba strojno berljivega dokumenta neučinkovita. V njem se uporablja model, ki je v tem primeru odvečen in bo le motil. Poleg tega bo potrebno za izvlečenje prvotnih podatkov napisati program. Malo verjetno je, da bi imelo smisel uporabljati XML za kaj takšnega, kar v določeni fazi ne bo formatirano kot dokument (recimo s CSS ali XSLT, ali oboje), saj je to glavni (če ne edini) razlog za zadrževanje dokumentnega modela.

Poleg tega, ker v XML ni pojma številk (ali logičnih izrazov, ali drugih podatkovnih tipov), se v tem formatu predstavljene številke obravnavajo le kot dodatno besedilo. Za izvlečenje podatkov je treba poznati shemo in njeno povezavo z ustreznimi izraženimi podatki. Prav tako je treba vedeti, kdaj, glede na kontekst, določen element besedila predstavlja število in ga je treba pretvoriti v število, itd.

Tako je postopek pridobivanja podatkov iz dokumentov XML precej podoben postopku prepoznavanja skeniranih dokumentov, ki vsebujejo na primer številčne tabele, razporejene čez več strani. Da, to načeloma zmoremo, vendar ni najbolj optimalen način — razen v skrajni nuji, ko ni drugih možnosti. Razumnejša rešitev bi bila, da preprosto najdemo digitalno kopijo izvirnih podatkov, ki niso vdelani v model dokumenta, kjer so podatki združeni z njihovim konkretnim besedilnim prikazom.

Ob tem me sploh ne preseneča, da je XML priljubljen v poslovanju. Razlog za to je prav ta, da je oblikovni format dokumentov (na papirju) jasen in znan poslovanju, kjer želijo nadaljevati z uporabo poznanega in razumljivega modela. Iz istega razloga se v poslovanju prepogosto uporabljajo dokumenti v PDF-ju namesto bolj obdelovalnih formatov — ker so še vedno povezani s pojmom tiskanih strani z določenimi fizičnimi dimenzijami. To velja tudi za dokumente, ki jih verjetno nikoli ne bodo natisnjeni (na primer PDF-dokumentacija registra s 8000 stranmi). Z tega vidika je uporaba XML v poslu v bistvu izraz skevomorfizma. Ljudem je jasna metaforična ideja tiskanih strani omejene velikosti in razumejo, kako ustvarjati poslovne postopke na podlagi tiskanih dokumentov. Če je to vaša usmeritev, dokumenti brez omejene fizične velikosti, ki so strojno berljivi — dokumenti XML — predstavljajo inovacijo, hkrati pa so poznana in udobna alternativa dokumentu. Kar pa ne preprečuje, da še vedno ostajajo nevredni in prekomerno skevomorfni način predstavitve podatkov.

Danes so edini znani XML-schemati, ki jih lahko resnično imenujem pravilna uporaba te oblike, XHTML in DocBook.

Izvor: habr.com