De XML-taal waard útfûn yn 1996. Net earder hie it bliken dien as de mooglikheden fan syn tapassing al begûn te wurden ferkeard begrepen, en foar de doelen dêr't se besocht te passen it, it wie net de bêste kar.
It is gjin oerdriuwing om te sizzen dat de grutte mearderheid fan XML-skema's dy't ik haw sjoen ûngeskikt of ferkeard gebrûk fan XML is. Boppedat toande dit gebrûk fan XML in fûnemintele misferstân fan wêr't XML oer gie.
XML is in opmaaktaal. Dit is gjin gegevensformaat. De measte XML-skema's hawwe dizze ûnderskieding eksplisyt oersjoen, wêrtroch XML mei in gegevensformaat betiizje, wat úteinlik resulteart yn in flater by it kiezen fan XML, om't it it gegevensformaat is dat eins nedich is.
Sûnder te folle detail yn te gean, is XML it bêste geskikt foar it annotearjen fan tekstblokken mei struktuer en metadata. As jo haaddoel net is om te wurkjen mei in tekstblok, is it kiezen fan XML wierskynlik net rjochtfeardige.
Fanút dit eachpunt is d'r in ienfâldige manier om te kontrolearjen hoe goed it XML-skema is makke. Litte wy as foarbyld in dokumint nimme yn it bedoelde skema en alle tags en attributen derút fuortsmite. As wat oerbleaun is gjin sin (of as der in lege rigel oer is), dan is jo skema net goed boud of jo soene gewoan gjin XML moatte hawwe brûkt.
Hjirûnder sil ik guon fan 'e meast foarkommende foarbylden jaan fan ferkeard konstruearre circuits.
<roоt>
<item name="name" value="John" />
<item name="city" value="London" />
</roоt>Hjir sjogge wy in foarbyld fan in ûnbegrûne en nuvere (hoewol heul gewoan) besykjen om in ienfâldich kaaiwurdwurdboek yn XML út te drukken. As jo alle tags en attributen fuortsmite, sille jo in lege rige oerlitte. Yn wêzen is dit dokumint, hoe absurd it ek klinke kin, in semantyske annotaasje fan in lege rigel.
<root name="John" city="London" />Om it noch slimmer te meitsjen, hawwe wy hjir net allinnich in semantyske annotaasje fan in lege tekenrige as in ekstravagante manier om in wurdboek út te drukken - dizze kear wurdt it "wurdboek" direkt kodearre as attributen fan it root-elemint. Dit makket de opjûne set fan attribútnammen op in elemint ûndefinieare en dynamysk. Boppedat lit it sjen dat alles wat de auteur wirklik útdrukke woe, in ienfâldige kaai-wearde-syntaksis wie, mar ynstee naam hy it absolút bizarre beslút om XML oan te passen, wêrtroch it gebrûk fan in inkeld leech elemint gewoan as foarheaksel om attribuutsyntaksis te brûken. En sokke regelingen kom ik hiel faak tsjin.
<roоt>
<item key="name">John</item>
<item key="city">London</item>
</roоt>Dit is wat better, mar no binne de kaaien om ien of oare reden metadata en de wearden net. In hiel nuvere blik op wurdboeken. As jo alle tags en attributen fuortsmite, sil de helte fan de ynformaasje ferlern gean.
In korrekte wurdboekekspresje yn XML soe der sa útsjen:
<roоt>
<item>
<key>Name</key>
<value>John</value>
</item>
<item>
<key>City</key>
<value>London</value>
</item>
</roоt>Mar as minsken it nuvere beslút makke hawwe om XML as gegevensformaat te brûken en it dan te brûken om in wurdskat te organisearjen, dan moatte se begripe dat wat se dogge net geskikt en net handich is. It is ek gewoan dat ûntwerpers ferkeard XML kieze om har applikaasjes te meitsjen. Mar noch faker meitsje se de saken slimmer troch it sinleas gebrûk fan XML yn ien fan 'e hjirboppe beskreaune foarmen, negearje it feit dat XML hjir gewoan net geskikt foar is.
Slimste XML-skema? Troch de wei, de priis foar it slimste XML-skema dat ik ea sjoen haw, Krijt it automatyske konfiguraasjebestânformaat foar foarsjenning foar Polycom IP-tillefoans. Sokke bestannen fereaskje it ynladen fan XML-oanfraachbestannen fia TFTP, dy't ... Yn 't algemien is hjir in úttreksel fan sa'n bestân:
<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 gjin minne grap fan ien. En dit is net myn útfining:
- eleminten wurde gewoan brûkt as foarheaksel om attributen te heakjen, dy't sels hiërargyske nammen hawwe.
- As jo wearden wolle tawize oan meardere eksimplaren fan in bepaald type record, moatte jo attribútnammen brûke om dit te dwaan. dy't yndeksen hawwe.
- Dêrneist attributen begjinnend mei
softkey., moat wurde pleatst op eleminten<softkey/>, attributen begjinnend meifeature., moat wurde pleatst op eleminten<feature/>ensfh., nettsjinsteande it feit dat it der folslein ûnnedich en op it earste eachopslach sûnder sin liket. - En úteinlik, as jo hopen dat de earste komponint fan in attribuutnamme altyd itselde wêze soe as de elemintnamme - neat as dat! Bygelyks, attributen
up.moat wurde ferbûn oan<userpreferences/>. De folchoarder fan it heakjen fan attribútnammen oan eleminten is willekeurich, hast folslein.
Dokuminten of gegevens. Sa no en dan docht immen wat folslein raar troch te besykjen XML en JSON te fergelykjen - en dus sjen te litten dat se it ek net begripe. XML is in dokumintmarkearringstaal. JSON is in strukturearre gegevensformaat, dus fergelykje se mei elkoar is as besykje waarm te fergelykjen mei sêft.
It konsept fan it ferskil tusken dokuminten en gegevens. As analoog fan XML kinne wy betingst nimme in masine-lêsber dokumint. Hoewol it bedoeld is om masine lêsber te wêzen, ferwiist it metafoarysk nei dokuminten, en is fanút dit eachpunt eins te fergelykjen mei PDF-dokuminten, dy't meastentiids net masine lêsber binne.
Bygelyks, yn XML is de folchoarder fan eleminten fan belang. Mar yn JSON is de folchoarder fan kaai-wearde-pearen binnen objekten sinleas en net definieare. As jo in net-oardere wurdboek fan kaai-wearde-pearen krije wolle, makket de eigentlike folchoarder wêryn't de eleminten yn dat bestân ferskine net út. Mar jo kinne in protte ferskillende soarten gegevens út dizze gegevens foarmje. fan dokuminten, om't der in bepaalde folchoarder is yn it dokumint. Metafoarysk is it analoog oan in dokumint op papier, hoewol it gjin fysike dimensjes hat, yn tsjinstelling ta in ôfdruk of PDF-bestân.
Myn foarbyld fan in goede XML-wurdboekfertsjintwurdiging toant de folchoarder fan 'e eleminten yn it wurdboek, yn tsjinstelling ta de JSON-fertsjintwurdiging. Ik kin dizze folchoarder net negearje: dizze linigens is ynherint yn it dokumintmodel en XML-formaat. Guon kinne der foar kieze om de folchoarder te negearjen by it ynterpretearjen fan dit XML-dokumint, mar d'r is gjin punt om hjiroer te argumintearjen, om't it probleem bûten it ramt fan in diskusje oer it formaat sels leit. Boppedat, as jo it dokumint sichtber meitsje yn 'e blêder troch der in cascadearjende stylblêd oan te heakjen, sille jo sjen dat de wurdboekeleminten yn in bepaalde folchoarder ferskine en yn gjin oare.
Mei oare wurden, in wurdboek (in stik strukturearre gegevens) kin omset wurde yn n ferskate mooglike dokuminten (yn XML, PDF, papier, ensfh), wêr n - it oantal mooglike kombinaasjes fan eleminten yn it wurdboek, en wy hawwe noch gjin rekken hâlden mei oare mooglike fariabelen.
It folget lykwols ek dat as jo allinich gegevens wolle oerdrage, dan sil it gebrûk fan in masine-lêsber dokumint hjirfoar net effektyf wêze. It brûkt in model, dat yn dit gefal oerstallich is; it sil allinich yn 'e wei komme. Derneist, om de boarnegegevens te ekstrahearjen, moatte jo in programma skriuwe. D'r hat amper gjin sin om XML te brûken foar iets dat op in stuit net as dokumint opmakke wurdt (bygelyks, mei CSS of XSLT, of beide), om't dat de wichtichste (as net de ienige) reden is om dat te dwaan. nei it dokumintmodel.
Boppedat, om't XML gjin konsept fan getallen hat (of Booleaanske útdrukkingen, of oare gegevenstypen), wurde alle nûmers fertsjintwurdige yn dit formaat as gewoan ekstra tekst beskôge. Om gegevens te ekstrahearjen, moatte it skema en har relaasje mei de oerienkommende gegevens dy't útdrukt wurde bekend wêze. Jo moatte ek witte wannear't, basearre op 'e kontekst, in bepaald tekstelemint in nûmer fertsjintwurdiget en moat wurde omboud ta in nûmer, ensfh.
Sa is it proses fan it ekstrahearjen fan gegevens út XML-dokuminten net sa oars as it proses fan it erkennen fan skande dokuminten dy't bygelyks tabellen befetsje dy't in protte siden mei numerike gegevens foarmje. Ja, it is mooglik om dit yn prinsipe te dwaan, mar dit is net de meast optimale manier, útsein as lêste ynstânsje, as d'r absolút gjin oare opsjes binne. In ridlike oplossing is gewoan in digitale kopy fan 'e orizjinele gegevens te finen dy't net ynbêde is yn in dokumintmodel dat de gegevens kombinearret mei har spesifike tekstfoarstelling.
Dat sei, it fernuveret my hielendal net dat XML populêr is yn bedriuw. De reden hjirfoar is krekt dat it dokumintformaat (op papier) begryplik en fertroud is foar bedriuwen, en se wolle trochgean mei it brûken fan in fertroud en begryplik model. Om deselde reden brûke bedriuwen te faak PDF-dokuminten ynstee fan mear masine-lêsbere formaten - om't se noch altyd bûn binne oan it konsept fan in printe side mei in spesifike fysike grutte. Dit jildt sels foar dokuminten dy't net wierskynlik oait wurde printe (bygelyks in 8000-pagina PDF fan registerdokumintaasje). Fanút dit eachpunt is it gebrûk fan XML yn bedriuw yn essinsje in manifestaasje fan skeuomorphisme. Minsken begripe it metafoaryske idee fan in printe side fan beheinde grutte, en se begripe hoe't jo saaklike prosessen kinne oanmeitsje op basis fan printe dokuminten. As dat jo hantlieding is, fertsjinwurdigje dokuminten sûnder beheiningen foar fysike grutte dy't masinelêsber binne - XML-dokuminten - ynnovaasje, wylst se in fertroud en noflik dokumint tsjinhinger binne. Dit foarkomt net dat se in ferkearde en al te skeuomorphyske manier bliuwe fan it presintearjen fan gegevens.
Oant no ta binne de ienige XML-skema's dy't ik wit fan dat ik wirklik in jildich gebrûk fan it formaat kin neame XHTML en DocBook.
Boarne: www.habr.com