Die XML-taal is in 1996 uitgevind. Nie gou het dit verskyn nie of die moontlikhede van die toepassing daarvan het reeds begin misverstaan, en vir die doeleindes waarby hulle dit probeer aanpas het, was dit nie die beste keuse nie.
Dit is geen oordrywing om te sê dat die oorgrote meerderheid van XML-skemas wat ek gesien het, onvanpaste of verkeerde gebruike van XML is nie. Boonop het hierdie gebruik van XML 'n fundamentele misverstand getoon van waaroor XML gaan.
XML is 'n opmerktaal. Dit is nie 'n dataformaat nie. Die meeste XML-skemas het hierdie onderskeid uitdruklik oor die hoof gesien, wat XML met 'n dataformaat verwar, wat uiteindelik lei tot 'n fout met die keuse van XML omdat dit die dataformaat is wat eintlik nodig is.
Sonder om in te veel besonderhede in te gaan, is XML die beste geskik vir die annotasie van blokke teks met struktuur en metadata. As jou hoofdoel nie is om met 'n blok teks te werk nie, is dit onwaarskynlik dat die keuse van XML geregverdig sal wees.
Vanuit hierdie oogpunt is daar 'n eenvoudige manier om te kyk hoe goed die XML-skema gemaak is. Kom ons neem as 'n voorbeeld 'n dokument in die beoogde skema en verwyder alle etikette en eienskappe daarvan. As dit wat oorbly nie sin maak nie (of as daar 'n leë reël oor is), dan is óf jou skema nie korrek gebou nie óf jy moes eenvoudig nie XML gebruik het nie.
Hieronder gee ek 'n paar van die mees algemene voorbeelde van verkeerd saamgestelde stroombane.
<roоt>
<item name="name" value="John" />
<item name="city" value="London" />
</roоt>Hier sien ons 'n voorbeeld van 'n ongegronde en vreemde (alhoewel baie algemene) poging om 'n eenvoudige sleutelwaarde-woordeboek in XML uit te druk. As jy alle merkers en kenmerke verwyder, sal jy met 'n leë ry gelaat word. In wese is hierdie dokument, hoe absurd dit ook al mag klink, 'n semantiese annotasie van 'n leë reël.
<root name="John" city="London" />Om sake te vererger, het ons nie net 'n semantiese annotasie van 'n leë string hier as 'n uitspattige manier om 'n woordeboek uit te druk nie - hierdie keer word die "woordeboek" direk geënkodeer as eienskappe van die stamelement. Dit maak die gegewe stel kenmerkname op 'n element ongedefinieerd en dinamies. Boonop wys dit dat al wat die skrywer regtig wou uitdruk 'n eenvoudige sleutel-waarde-sintaksis was, maar in plaas daarvan het hy die absoluut bisarre besluit geneem om XML toe te pas, wat die gebruik van 'n enkele leë element bloot as 'n voorvoegsel gedwing het om kenmerksintaksis te gebruik. En ek kom baie gereeld sulke skemas teë.
<roоt>
<item key="name">John</item>
<item key="city">London</item>
</roоt>Dit is iets beter, maar nou is die sleutels om een of ander rede metadata en die waardes nie. 'n Baie vreemde blik op woordeboeke. As jy alle merkers en eienskappe verwyder, sal die helfte van die inligting verlore gaan.
'n Korrekte woordeboekuitdrukking in XML sal iets soos volg lyk:
<roоt>
<item>
<key>Name</key>
<value>John</value>
</item>
<item>
<key>City</key>
<value>London</value>
</item>
</roоt>Maar as mense die vreemde besluit geneem het om XML as 'n dataformaat te gebruik en dit dan te gebruik om 'n woordeskat te organiseer, dan moet hulle verstaan dat wat hulle doen, onvanpas en nie gerieflik is nie. Dit is ook algemeen dat ontwerpers verkeerdelik XML kies om hul toepassings te skep. Maar selfs meer dikwels maak hulle sake erger deur XML betekenisloos te gebruik in een van die vorms wat hierbo beskryf word, en ignoreer die feit dat XML eenvoudig nie hiervoor geskik is nie.
Slegste XML-skema? Terloops, die prys vir die slegste XML-skema wat ek nog ooit gesien het, Kry die outomatiese voorsiening-konfigurasielêerformaat vir Polycom IP-telefoniefone. Sulke lêers vereis die aflaai van XML-versoeklêers via TFTP, wat... Oor die algemeen is hier 'n uittreksel uit een so 'n lêer:
<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="..." />Dit is nie iemand se slegte grap nie. En dit is nie my uitvinding nie:
- elemente word bloot as 'n voorvoegsel gebruik om eienskappe aan te heg, wat self hiërargiese name het.
- As u waardes aan veelvuldige gevalle van 'n spesifieke tipe rekord wil toeken, moet u kenmerkname gebruik om dit te doen. wat indekse het.
- Daarbenewens kenmerke wat begin met
softkey., moet op elemente geplaas word<softkey/>, eienskappe wat begin metfeature., moet op elemente geplaas word<feature/>ens., ten spyte daarvan dat dit heeltemal onnodig en met die eerste oogopslag betekenisloos lyk. - En ten slotte, as jy gehoop het dat die eerste komponent van 'n kenmerknaam altyd dieselfde as die elementnaam sou wees - niks soos dit nie! Byvoorbeeld, eienskappe
up.moet geheg word aan<userpreferences/>. Die volgorde van die heg van kenmerkname aan elemente is arbitrêr, amper heeltemal.
Dokumente of data. Elke kort-kort doen iemand iets heeltemal vreemd deur XML en JSON te probeer vergelyk—en sodoende te wys dat hulle ook nie verstaan nie. XML is 'n dokumentopmerktaal. JSON is 'n gestruktureerde dataformaat, so om hulle met mekaar te vergelyk is soos om warm met sag te probeer vergelyk.
Die konsep van die verskil tussen dokumente en data. As 'n analoog van XML, kan ons voorwaardelik 'n masjienleesbare dokument neem. Alhoewel dit bedoel is om masjienleesbaar te wees, verwys dit metafories na dokumente, en is vanuit hierdie oogpunt eintlik vergelykbaar met PDF-dokumente, wat meestal nie masjienleesbaar is nie.
Byvoorbeeld, in XML is die volgorde van elemente belangrik. Maar in JSON is die volgorde van sleutel-waarde-pare binne voorwerpe betekenisloos en ongedefinieerd. As jy 'n ongeordende woordeboek van sleutel-waarde-pare wil kry, maak die werklike volgorde waarin die elemente in daardie lêer verskyn nie saak nie. Maar jy kan baie verskillende tipes data uit hierdie data vorm. van dokumente, want daar is 'n sekere volgorde in die dokument. Metafories is dit analoog aan 'n dokument op papier, hoewel dit nie fisiese afmetings het nie, anders as 'n drukstuk of PDF-lêer.
My voorbeeld van 'n behoorlike XML-woordeboekvoorstelling toon die volgorde van die elemente in die woordeboek, in teenstelling met die JSON-voorstelling. Ek kan nie hierdie volgorde ignoreer nie: hierdie lineariteit is inherent aan die dokumentmodel en XML-formaat. Sommige kan kies om die volgorde te ignoreer wanneer hierdie XML-dokument geïnterpreteer word, maar dit is geen sin om hieroor te stry nie, aangesien die kwessie buite die bestek van 'n bespreking van die formaat self val. Verder, as jy die dokument in die blaaier sigbaar maak deur 'n trapstylblad daaraan te heg, sal jy sien dat die woordeboekelemente in 'n sekere volgorde verskyn en in geen ander nie.
Met ander woorde, 'n woordeboek ('n stuk gestruktureerde data) kan in omgeskakel word n verskeie moontlike dokumente (in XML, PDF, papier, ens.), waar n - die aantal moontlike kombinasies van elemente in die woordeboek, en ons het nog nie ander moontlike veranderlikes in ag geneem nie.
Dit volg egter ook dat as jy slegs data wil oordra, die gebruik van 'n masjienleesbare dokument hiervoor nie effektief sal wees nie. Dit gebruik 'n model, wat in hierdie geval oorbodig is; dit sal net in die pad staan. Daarbenewens, om die brondata te onttrek, sal jy 'n program moet skryf. Daar is skaars sin om XML te gebruik vir iets wat nie een of ander tyd as 'n dokument geformateer sal word nie (sê, met behulp van CSS of XSLT, of albei), aangesien dit die hoof (indien nie die enigste) rede is om dit te doen nie. na die dokumentmodel.
Boonop, aangesien XML geen konsep van getalle (of Boole-uitdrukkings of ander datatipes) het nie, word alle getalle wat in hierdie formaat voorgestel word, as net addisionele teks beskou. Om data te onttrek, moet die skema en sy verhouding tot die ooreenstemmende data wat uitgedruk word, bekend wees. Jy moet ook weet wanneer, gebaseer op die konteks, 'n spesifieke tekselement 'n getal verteenwoordig en na 'n getal omgeskakel moet word, ens.
Die proses om data uit XML-dokumente te onttrek is dus nie so anders as die proses om geskandeerde dokumente te herken wat byvoorbeeld tabelle bevat wat baie bladsye van numeriese data vorm nie. Ja, dit is moontlik om dit in beginsel te doen, maar dit is nie die mees optimale manier nie, behalwe as 'n laaste uitweg, wanneer daar absoluut geen ander opsies is nie. 'n Redelike oplossing is om bloot 'n digitale kopie van die oorspronklike data te vind wat nie in 'n dokumentmodel ingebed is nie wat die data kombineer met sy spesifieke tekstuele voorstelling.
Dit gesê, dit verbaas my glad nie dat XML gewild is in besigheid nie. Die rede hiervoor is juis dat die dokumentformaat (op papier) verstaanbaar en bekend vir sakeondernemings is, en hulle wil voortgaan om 'n bekende en verstaanbare model te gebruik. Om dieselfde rede gebruik ondernemings te dikwels PDF-dokumente in plaas van meer masjienleesbare formate – omdat dit steeds gekoppel is aan die konsep van 'n gedrukte bladsy met 'n spesifieke fisiese grootte. Dit geld selfs vir dokumente wat waarskynlik nie ooit gedruk sal word nie (byvoorbeeld 'n PDF van 8000 XNUMX bladsye van registerdokumentasie). Vanuit hierdie oogpunt is die gebruik van XML in besigheid in wese 'n manifestasie van skeuomorfisme. Mense verstaan die metaforiese idee van 'n gedrukte bladsy van beperkte grootte, en hulle verstaan hoe om besigheidsprosesse te skep gebaseer op gedrukte dokumente. As dit jou gids is, verteenwoordig dokumente sonder fisiese groottebeperkings wat masjienleesbaar is—XML-dokumente—innovasie terwyl dit 'n bekende en gemaklike dokument-eweknie is. Dit verhoed nie dat hulle 'n verkeerde en oordrewe skeuomorfiese manier bly om data aan te bied nie.
Tot op datum is die enigste XML-skemas waarvan ek weet wat ek werklik 'n geldige gebruik van die formaat kan noem, XHTML en DocBook.
Bron: will.com