XML se skoraj vedno zlorablja

Jezik XML je bil izumljen leta 1996. Komaj se je pojavila, so že začeli napačno razumeti možnosti njene uporabe in za namene, ki so jih poskušali prilagoditi, ni bila najboljša izbira.

Ni pretiravanje, če rečem, da je velika večina shem XML, ki sem jih videl, neustrezna ali nepravilna uporaba XML. Poleg tega je ta uporaba XML pokazala temeljno nerazumevanje tega, kaj XML sploh je bil.

XML je označevalni jezik. To ni format podatkov. Večina shem XML je izrecno spregledala to razlikovanje in zamenjala XML s formatom podatkov, kar na koncu povzroči napako pri izbiri XML, ker je to format podatkov, ki je dejansko potreben.

Ne da bi se spuščali v preveč podrobnosti, XML je najprimernejši za označevanje blokov besedila s strukturo in metapodatki. Če vaš glavni cilj ni delo z blokom besedila, izbira XML verjetno ne bo upravičena.

S tega vidika obstaja preprost način za preverjanje, kako dobro je izdelana shema XML. Vzemimo za primer dokument v predvideni shemi in iz njega odstranimo vse oznake in atribute. Če tisto, kar je ostalo, nima smisla (ali če je ostala prazna vrstica), potem vaša shema ni pravilno zgrajena ali pa preprosto niste smeli uporabiti XML.

Spodaj bom navedel nekaj najpogostejših primerov nepravilno zgrajenih vezij.

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

Tukaj vidimo primer neutemeljenega in čudnega (čeprav zelo pogostega) poskusa izražanja preprostega slovarja ključ-vrednost v XML. Če odstranite vse oznake in atribute, boste imeli prazno vrstico. V bistvu je ta dokument, ne glede na to, kako absurdno se sliši, pomenska opomba prazne vrstice.

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

Da bi bile stvari še hujše, tukaj nimamo le semantične opombe praznega niza kot ekstravagantnega načina izražanja slovarja - tokrat je "slovar" neposredno kodiran kot atributi korenskega elementa. Zaradi tega je dani niz imen atributov na elementu nedefiniran in dinamičen. Poleg tega kaže, da je vse, kar je avtor resnično želel izraziti, preprosto sintakso ključ-vrednost, vendar je namesto tega sprejel popolnoma bizarno odločitev za uporabo XML-ja, s čimer je prisilil uporabo enega samega praznega elementa preprosto kot predpono za uporabo sintakse atributov. In na take sheme naletim zelo pogosto.

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

To je nekaj boljšega, vendar so zdaj ključi iz neznanega razloga metapodatki, vrednosti pa ne. Zelo čuden pogled na slovarje. Če odstranite vse oznake in atribute, bo izgubljena polovica informacij.

Pravilen slovarski izraz v XML bi bil videti nekako takole:

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

Toda če so se ljudje nenavadno odločili uporabiti XML kot podatkovni format in ga nato uporabiti za organizacijo besedišča, potem bi morali razumeti, da je to, kar počnejo, neprimerno in neprimerno. Prav tako je pogosto, da oblikovalci pomotoma izberejo XML za ustvarjanje svojih aplikacij. A še pogosteje zadevo poslabšajo z nesmiselno uporabo XML-ja v eni od zgoraj opisanih oblik, zanemarjajoč dejstvo, da XML za to enostavno ni primeren.

Najslabša shema XML? Mimogrede, nagrada za najslabša shema XML, kar sem jih kdaj videl, Pridobi format konfiguracijske datoteke za samodejno zagotavljanje za telefone Polycom IP telefonije. Takšne datoteke zahtevajo prenos datotek zahtev XML prek TFTP, kar ... Na splošno je tukaj izvleček 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 nečija slaba šala. In to ni moj izum:

• elementi se preprosto uporabljajo kot predpona za pripenjanje atributov, ki imajo sami hierarhična imena.
• Če želite dodeliti vrednosti več primerkom določene vrste zapisa, morate za to uporabiti imena atributov. ki imajo indekse.
• Poleg tega atributi, ki se začnejo z softkey., je treba postaviti na elemente <softkey/>, atributi, ki se začnejo z feature., je treba postaviti na elemente <feature/> itd., kljub temu, da je videti popolnoma nepotrebno in na prvi pogled nesmiselno.
• In končno, če ste upali, da bo prva komponenta imena atributa vedno enaka imenu elementa - nič takega! Na primer, atributi up. je treba priložiti <userpreferences/>. Vrstni red pripisovanja imen atributov elementom je poljuben, skoraj popolnoma.

Dokumenti ali podatki. Vsake toliko časa nekdo naredi nekaj povsem nenavadnega, ko poskuša primerjati XML in JSON – in s tem pokaže, da niti enega ne razume. XML je označevalni jezik dokumentov. JSON je format strukturiranih podatkov, zato je njihova medsebojna primerjava kot primerjava toplega z mehkim.

Koncept razlike med dokumentov in podatkov. Kot analog XML lahko pogojno vzamemo strojno berljiv dokument. Čeprav naj bi bil strojno berljiv, se metaforično nanaša na dokumente in je s tega vidika dejansko primerljiv z dokumenti PDF, ki največkrat niso strojno berljivi.

V XML je na primer pomemben vrstni red elementov. Toda v JSON je vrstni red parov ključ-vrednost znotraj predmetov nesmiseln in nedefiniran. Če želite dobiti neurejen slovar parov ključ-vrednost, dejanski vrstni red elementov v tej datoteki ni pomemben. Toda iz teh podatkov lahko oblikujete veliko različnih vrst podatkov. dokumentov, ker je v dokumentu določen vrstni red. Metaforično je analogen dokumentu na papirju, čeprav nima fizičnih dimenzij, za razliko od izpisa ali datoteke PDF.

Moj primer pravilne predstavitve slovarja XML prikazuje vrstni red elementov v slovarju v nasprotju s predstavitvijo JSON. Tega vrstnega reda ne morem prezreti: ta linearnost je neločljivo povezana z modelom dokumenta in formatom XML. Nekateri se lahko odločijo, da bodo pri razlagi tega dokumenta XML prezrli vrstni red, vendar se o tem nima smisla prepirati, saj vprašanje presega obseg razprave o samem formatu. Poleg tega, če omogočite ogled dokumenta v brskalniku tako, da mu pripnete kaskadni slogovni list, boste videli, da se elementi slovarja pojavljajo v določenem vrstnem redu in v nobenem drugem.

Z drugimi besedami, slovar (kos strukturiranih podatkov) je mogoče pretvoriti v n različne možne dokumente (v XML, PDF, na papirju itd.), kjer n - število možnih kombinacij elementov v slovarju, ostalih možnih spremenljivk pa še nismo upoštevali.

Iz tega pa tudi sledi, da če želite prenesti samo podatke, uporaba strojno berljivega dokumenta za to ne bo učinkovita. Uporablja model, ki je v tem primeru odveč, le v napoto. Poleg tega boste morali za ekstrahiranje izvornih podatkov napisati program. Skorajda nima smisla uporabljati XML za nekaj, kar na neki točki ne bo oblikovano kot dokument (recimo z uporabo CSS ali XSLT ali obojega), saj je to glavni (če ne edini) razlog za to. na model dokumenta.

Še več, ker XML nima koncepta števil (ali logičnih izrazov ali drugih tipov podatkov), se vsa števila, predstavljena v tem formatu, štejejo le za dodatno besedilo. Za pridobivanje podatkov je treba poznati shemo in njeno razmerje do ustreznih podatkov, ki se izražajo. Prav tako morate vedeti, kdaj na podlagi konteksta določen element besedila predstavlja število in ga je treba pretvoriti v število itd.

Tako se postopek pridobivanja podatkov iz dokumentov XML ne razlikuje toliko od postopka prepoznavanja skeniranih dokumentov, ki vsebujejo na primer tabele, ki tvorijo veliko strani numeričnih podatkov. Da, načeloma je to mogoče, vendar to ni najbolj optimalen način, razen v skrajni sili, ko ni nobene druge možnosti. Razumna rešitev je preprosto najti digitalno kopijo izvirnih podatkov, ki ni vdelana v model dokumenta, ki združuje podatke z njihovo specifično besedilno predstavitvijo.

Kljub temu me sploh ne preseneča, da je XML priljubljen v poslu. Razlog za to je ravno v tem, da je oblika dokumenta (na papirju) razumljiva in poznana za podjetja in želijo še naprej uporabljati poznan in razumljiv model. Iz istega razloga podjetja prepogosto uporabljajo dokumente PDF namesto bolj strojno berljivih formatov - ker so še vedno vezani na koncept natisnjene strani z določeno fizično velikostjo. To velja celo za dokumente, za katere je malo verjetno, da bodo kdaj natisnjeni (na primer 8000-stranski PDF registrske dokumentacije). S tega vidika je uporaba XML v poslovanju v bistvu manifestacija skeuomorfizma. Ljudje razumejo metaforično idejo natisnjene strani omejene velikosti in razumejo, kako ustvariti poslovne procese na podlagi natisnjenih dokumentov. Če je to vaše vodilo, dokumenti brez omejitev fizične velikosti, ki so strojno berljivi – dokumenti XML – predstavljajo inovacijo, hkrati pa so znana in udobna protipostavka dokumentu. To ne preprečuje, da bi ostali nepravilen in preveč skevomorfen način podajanja podatkov.

Do danes sta edini shemi XML, ki ju poznam in ju resnično lahko označim za veljavno uporabo formata, XHTML in DocBook.

Vir: www.habr.com