XML:ää käytetään lähes aina väärin

XML-kieli keksittiin vuonna 1996. Heti kun se ilmestyi, sen soveltamismahdollisuudet alettiin jo ymmärtää väärin, eikä se ollut paras valinta niihin tarkoituksiin, joihin sitä yritettiin mukauttaa.

Ei ole liioittelua sanoa, että suurin osa näkemistäni XML-skeemoista oli sopimatonta tai virheellistä XML:n käyttöä. Lisäksi tämä XML:n käyttö osoitti perustavanlaatuisen väärinkäsityksen siitä, mistä XML:ssä oli kyse.

XML on merkintäkieli. Tämä ei ole datamuoto. Useimmat XML-skeemat ovat eksplisiittisesti jättäneet huomiotta tämän eron ja sekoittaneet XML:n tietomuotoon, mikä johtaa lopulta virheeseen XML:n valinnassa, koska se on tietomuoto, jota todella tarvitaan.

Liika yksityiskohtiin menemättä XML sopii parhaiten tekstilohkojen rakenteen ja metatietojen merkitsemiseen. Jos päätavoitteesi ei ole työskennellä tekstilohkon kanssa, XML:n valitseminen ei todennäköisesti ole perusteltua.

Tästä näkökulmasta katsottuna on yksinkertainen tapa tarkistaa, kuinka hyvin XML-skeema on tehty. Otetaan esimerkkinä asiakirja aiotussa skeemassa ja poistetaan siitä kaikki tunnisteet ja attribuutit. Jos jäljelle jäävä ei ole järkevää (tai jos siinä on tyhjä rivi), joko skeemasi ei ole rakennettu oikein tai sinun ei yksinkertaisesti olisi pitänyt käyttää XML:ää.

Alla annan joitakin yleisimpiä esimerkkejä väärin rakennetuista piireistä.

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

Tässä on esimerkki perusteettomasta ja oudosta (vaikkakin hyvin yleisestä) yrityksestä ilmaista yksinkertainen avainarvosanakirja XML:ssä. Jos poistat kaikki tunnisteet ja attribuutit, sinulle jää tyhjä rivi. Pohjimmiltaan tämä asiakirja on, vaikka se kuulostaa kuinka absurdilta, tyhjän rivin semanttinen huomautus.

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

Vielä pahempaa on, että meillä ei ole vain tyhjän merkkijonon semanttista merkintää ylimääräisenä tapana ilmaista sanakirjaa - tällä kertaa "sanakirja" on koodattu suoraan juurielementin attribuutteiksi. Tämä tekee annetusta elementin määritteiden nimistä määrittelemättömän ja dynaamisen. Lisäksi se osoittaa, että kirjoittaja todella halusi ilmaista yksinkertaisen avainarvosyntaksin, mutta sen sijaan hän teki täysin oudon päätöksen soveltaa XML:ää pakottamalla yksittäisen tyhjän elementin yksinkertaisesti etuliitteeksi attribuuttisyntaksin käyttöön. Ja törmään tällaisiin suunnitelmiin hyvin usein.

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

Tämä on jotain parempaa, mutta nyt jostain syystä avaimet ovat metatietoja ja arvot eivät. Todella outo katsaus sanakirjoihin. Jos poistat kaikki tunnisteet ja attribuutit, puolet tiedoista menetetään.

Oikea sanakirjalauseke XML:ssä näyttäisi suunnilleen tältä:

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

Mutta jos ihmiset ovat tehneet oudon päätöksen käyttää XML:ää tietomuotona ja sitten käyttää sitä sanaston järjestämiseen, heidän pitäisi ymmärtää, että heidän tekemänsä toiminta on sopimatonta eikä kätevää. On myös yleistä, että suunnittelijat valitsevat vahingossa XML:n sovellusten luomiseen. Mutta vielä useammin ne pahentavat tilannetta käyttämällä XML:ää tarkoituksettomasti jossakin yllä kuvatuista muodoista, jättäen huomiotta sen tosiasian, että XML ei yksinkertaisesti sovellu tähän.

Huonoin XML-skeema? Muuten, palkinto pahin XML-skeema, jonka olen koskaan nähnyt, Saa automaattisen hallinnan määritystiedostomuodon Polycomin IP-puhelinpuhelimille. Tällaiset tiedostot vaativat XML-pyyntötiedostojen lataamisen TFTP:n kautta, mikä... Yleisesti ottaen tässä on ote yhdestä tällaisesta tiedostosta:

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

Tämä ei ole kenenkään huono vitsi. Ja tämä ei ole minun keksintöni:

• elementtejä käytetään yksinkertaisesti etuliitteenä attribuuttien liittämiseen, joilla itsellään on hierarkkinen nimi.
• Jos haluat määrittää arvoja useille tietyn tietuetyypin esiintymille, sinun on käytettävä attribuuttien nimiä tähän. joissa on indeksit.
• Lisäksi attribuutit alkaen softkey., on sijoitettava elementtien päälle <softkey/>, attribuutit alkaen feature., on sijoitettava elementtien päälle <feature/> jne. huolimatta siitä, että se näyttää täysin tarpeettomalta ja ensi silmäyksellä merkityksettömältä.
• Ja lopuksi, jos toivoisit, että määritteen nimen ensimmäinen komponentti olisi aina sama kuin elementin nimi - ei mitään sellaista! Esimerkiksi attribuutit up. on kiinnitettävä <userpreferences/>. Attribuuttien nimien liittämisjärjestys elementteihin on mielivaltainen, melkein kokonaan.

Asiakirjat tai tiedot. Aina silloin tällöin joku tekee jotain täysin outoa yrittäessään verrata XML:ää ja JSONia – ja siten osoittaen, ettei he ymmärrä kumpaakaan. XML on asiakirjankuvauskieli. JSON on strukturoitu tietomuoto, joten niiden vertaaminen toisiinsa on kuin yrittäisi verrata lämmintä ja pehmeää.

Käsite ero asiakirjoja ja tietoja. XML-analogina voimme ehdollisesti ottaa koneellisesti luettavan asiakirjan. Vaikka se on tarkoitettu koneellisesti luettavaksi, se viittaa metaforisesti asiakirjoihin ja on tästä näkökulmasta itse asiassa verrattavissa PDF-dokumentteihin, jotka eivät useimmiten ole koneellisesti luettavia.

Esimerkiksi XML:ssä elementtien järjestyksellä on väliä. Mutta JSONissa avain-arvo-parien järjestys objektien sisällä on merkityksetön ja määrittelemätön. Jos haluat saada avain-arvo-parien järjestämättömän sanakirjan, todellisella järjestyksellä, jossa elementit esiintyvät kyseisessä tiedostossa, ei ole väliä. Mutta voit muodostaa näistä tiedoista monenlaisia ​​​​tietoja. asiakirjat, koska asiakirjassa on tietty järjestys. Metaforisesti se on analoginen paperille kirjoitetun asiakirjan kanssa, vaikka sillä ei ole fyysisiä mittoja, toisin kuin tulosteella tai PDF-tiedostolla.

Esimerkkini oikeasta XML-sanakirjan esityksestä näyttää elementtien järjestyksen sanakirjassa, toisin kuin JSON-esitys. En voi sivuuttaa tätä järjestystä: tämä lineaarisuus on ominaista asiakirjamallille ja XML-muodolle. Jotkut saattavat jättää järjestyksen huomioimatta tätä XML-dokumenttia tulkittaessa, mutta tästä ei ole mitään järkeä kiistellä, koska asia ei kuulu itse formaatin keskusteluun. Lisäksi, jos teet asiakirjan näkyväksi selaimessa liittämällä siihen peräkkäisen tyylisivun, näet, että sanakirjan elementit näkyvät tietyssä järjestyksessä eivätkä missään muussa.

Toisin sanoen sanakirja (osa jäsenneltyä dataa) voidaan muuntaa n erilaisia ​​mahdollisia asiakirjoja (XML, PDF, paperi jne.), missä n - sanakirjan mahdollisten elementtien yhdistelmien lukumäärä, emmekä ole vielä ottaneet huomioon muita mahdollisia muuttujia.

Tästä seuraa kuitenkin myös, että jos haluat siirtää vain tietoja, koneellisesti luettavan asiakirjan käyttäminen ei ole tehokasta. Se käyttää mallia, joka tässä tapauksessa on tarpeeton, se vain estää. Lisäksi lähdetietojen purkamiseksi sinun on kirjoitettava ohjelma. Tuskin on mitään järkeä käyttää XML:ää asioihin, joita ei muotoilla dokumentiksi jossain vaiheessa (esim. käyttämällä CSS:tä tai XSLT:tä tai molempia), koska se on tärkein (ellei ainoa) syy tehdä niin. asiakirjamalliin.

Lisäksi koska XML:ssä ei ole käsitettä numeroista (tai Boolen lausekkeista tai muista tietotyypeistä), kaikkia tässä muodossa esitettyjä numeroita pidetään vain lisätekstinä. Tiedon poimimiseksi on tunnettava skeema ja sen suhde vastaavaan ilmaistavaan dataan. Sinun on myös tiedettävä, milloin tietty tekstielementti edustaa kontekstin perusteella numeroa ja se tulisi muuntaa luvuksi jne.

Näin ollen prosessi tietojen poimimiseen XML-asiakirjoista ei eroa niin paljon prosessista, jossa tunnistetaan skannattuja asiakirjoja, jotka sisältävät esimerkiksi taulukoita, jotka muodostavat useita sivuja numeerista dataa. Kyllä, tämä on mahdollista tehdä periaatteessa, mutta tämä ei ole optimaalinen tapa, paitsi viimeisenä keinona, kun muita vaihtoehtoja ei ole. Järkevä ratkaisu on yksinkertaisesti löytää digitaalinen kopio alkuperäisestä tiedosta, jota ei ole upotettu asiakirjamalliin, joka yhdistää tiedot sen erityiseen tekstimuotoiseen esitykseen.

En kuitenkaan yllätä minua ollenkaan, että XML on suosittu liiketoiminnassa. Syynä tähän on juuri se, että dokumenttimuoto (paperilla) on yrityksille ymmärrettävä ja tuttu, ja he haluavat jatkossakin käyttää tuttua ja ymmärrettävää mallia. Samasta syystä yritykset käyttävät liian usein PDF-dokumentteja koneellisesti luettavien muotojen sijaan - koska ne ovat edelleen sidoksissa tietyn fyysisen kokoisen painetun sivun käsitteeseen. Tämä koskee jopa asiakirjoja, joita ei todennäköisesti koskaan tulosteta (esimerkiksi 8000 XNUMX-sivuinen PDF rekisteriasiakirjoista). Tästä näkökulmasta XML:n käyttö liiketoiminnassa on pohjimmiltaan skeuomorfismin ilmentymä. Ihmiset ymmärtävät metaforisen idean rajoitetun koon painetusta sivusta ja he ymmärtävät kuinka luoda tulostettuihin asiakirjoihin perustuvia liiketoimintaprosesseja. Jos tämä on oppaasi, asiakirjat, joissa ei ole fyysisiä kokorajoituksia ja jotka ovat koneellisesti luettavia – XML-dokumentit – edustavat innovaatiota ja ovat samalla tuttuja ja mukavia asiakirjoja. Tämä ei estä niitä pysymästä virheellisenä ja liian skeuomorfisena tapana esittää dataa.

Toistaiseksi ainoat XML-skeemat, joita tiedän ja joita voin todella kutsua muodon kelvolliseksi käytöksi, ovat XHTML ja DocBook.

Lähde: will.com