XML 1996an asmatu zen. Ia desagertu zenean, bere aplikazioak gaizki ulertu ziren eta ez zen aukerarik onena egokitu zen helburuetarako.
Ez da gehiegikeria esatea ikusi ditudan XML eskema gehienek XMLren erabilera desegokiak edo okerrak irudikatzen dituztela. Gainera, XMLren erabilera horiek XML zer den ulertzeko oinarrizko gaizki-ulertua erakusten dute.
XML markaketa-lengoaia bat da. Hau ez da datu formatu batXML eskema gehienek ez zuten bereizketa hau kontuan hartzen, XML datu-formatu batekin nahastuz, eta horrek azkenean XML aukeratzerakoan akats bat ekarri zuen, benetan behar zena datu-formatu bat baitzen.
Xehetasun gehiegi eman gabe, XML da egokiena testu-blokeak egitura eta metadatuekin anotatzeko. Zure helburu nagusia testu-blokeekin lan egitea ez bada, XML aukeratzea ez da justifikatuta egongo.
Ikuspegi honetatik, XML eskema bat zein ondo diseinatuta dagoen probatzeko modu erraz bat dago. Hartu proposatutako eskemako dokumentu bat eta kendu etiketa eta atributu guztiak. Geratzen denak ez badu zentzurik (edo lerro huts bat geratzen bazaizu), orduan zure eskema okerra da edo, besterik gabe, ez zenuen XML erabili behar.
Jarraian, gaizki eraikitako zirkuituen adibide ohikoenetako batzuk emango ditut.
<roоt>
<item name="name" value="John" />
<item name="city" value="London" />
</roоt>Hemen XMLn gako-balio hiztegi sinple bat adierazteko saiakera oinarririk gabeko eta bitxi baten (nahiko ohikoa den arren) adibide bat ikusten dugu. Etiketa eta atributu guztiak kentzen badituzu, kate huts bat geratzen zaizu. Funtsean, dokumentu hau, absurdua badirudi ere, kate huts baten oharpen semantikoa da.
<root name="John" city="London" />Are okerrago, ez dugu hemen kate huts baten oharpen semantiko bat hiztegia adierazteko modu xalo gisa soilik; oraingoan, "hiztegia" zuzenean kodetuta dago erro elementuaren atributu gisa. Horrek elementuaren atributu-izen multzoa definitu gabe eta dinamiko bihurtzen du. Gainera, hemendik argi dago egileak benetan adierazi nahi zuen guztia gako-balio sintaxi sinple bat zela, baina horren ordez, XML erabiltzeko erabaki guztiz bitxia hartu zuten, elementu huts bakarra atributu sintaxiaren aurrizki gisa erabiltzera behartuz. Eta horrelako ereduak etengabe ikusten ditut.
<roоt>
<item key="name">John</item>
<item key="city">London</item>
</roоt>Hau pixka bat hobea da, baina arrazoiren batengatik, gakoak metadatuak dira orain, baina balioak ez. Hiztegiak ikusteko modu oso arraroa da. Etiketa eta atributu guztiak kentzen badituzu, informazioaren erdia galduko duzu.
XML-n hiztegi-adierazpen baliodun batek honelako zerbait izango luke:
<roоt>
<item>
<key>Name</key>
<value>John</value>
</item>
<item>
<key>City</key>
<value>London</value>
</item>
</roоt>Baina jendeak XML datu-formatu gisa erabiltzeko erabaki arraroa hartu badu eta gero hiztegia antolatzeko erabiltzen badu, ulertu beharko luke egiten ari direna desegokia eta deserosoa dela. Diseinatzaileek askotan XML aukeratzen dute oker, beren aplikazioak eraikitzeko. Baina are maizago, gauzak okerrera egiten dituzte XML zentzugabeki erabiliz goian deskribatutako formatan, XML ez dela egokia helburu horretarako alde batera utzita.
XML eskema okerrena? Bide batez, saria inoiz ikusi dudan XML eskemarik txarrena, Polycom IP telefonia telefonoetarako baliabideen hornidura automatikoaren konfigurazio fitxategi formatua jasotzen du. Fitxategi horiek XML eskaera fitxategiak TFTP bidez deskargatzea eskatzen dute, eta... Beno, hona hemen fitxategi horietako baten zati bat:
<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="..." />Hau ez da inoren txiste txarra. Eta ez da nire asmakizuna:
- elementuak aurrizki gisa erabiltzen dira atributuak eransteko, eta hauek beraiek izen hierarkikoak dituzte.
- Mota jakin bateko erregistro baten hainbat instantziari balioak esleitu behar badizkiezu, atributu-izenak erabili behar dituzu, indizeak dituztenak..
- Gainera, hauekin hasten diren atributuak
softkey.elementuen gainean jarri behar da<softkey/>, atributuak hasten dirafeature.elementuen gainean jarri behar da<feature/>etab., hau guztiz alferrikakoa eta lehen begiratuan zentzurik gabekoa iruditu arren. - Eta azkenik, atributu-izenaren lehen osagaia elementu-izenarekin bat etortzea espero bazenuen, ez zen zorterik izan! Adibidez, atributuak
up.erantsi behar zaio<userpreferences/>Atributu-izenak elementuei eransteko ordena arbitrarioa da, ia erabat.
Dokumentuak edo datuakNoizean behin, norbaitek zerbait guztiz arraroa egiten du XML eta JSON alderatzen saiatzean, horrela erakutsiz ez duela bata ez bestea ulertzen. XML dokumentuen markaketa-lengoaia bat da. JSON datu egituratuen formatu bat da, beraz, alderatzea zerbait beroa zerbait bigunarekin alderatzen saiatzea bezalakoa da.
bien arteko aldea ulertzeak hau ulertzen lagunduko dizu dokumentuak eta datuakMakinaz irakur daitekeen dokumentua XMLren analogotzat har daiteke. Makinek irakurtzeko pentsatuta dagoen arren, metaforikoki dokumentutzat hartzen da, eta ikuspuntu honetatik, funtsean PDF dokumentuekin konparagarria da, askotan makinaz irakur daitezkeenak ez direnak.
Adibidez, XML-n, elementuen ordenak garrantzia du. Baina JSON-en, objektuen barruko gako-balio bikoteen ordena ez du zentzurik eta zehaztu gabe dago. Gako-balio bikoteen hiztegi ordenatu gabe bat lortu nahi baduzu, fitxategi horretako elementuen benetako ordenak ez du axola. Baina datu horietatik objektu asko sor ditzakezu. dokumentuen, dokumentuak ordena jakin bat duelako. Metaforikoki, paperezko dokumentu baten analogoa da, nahiz eta ez duen inprimaketa edo PDF fitxategi baten neurri fisikoak.
Nire XML hiztegi-errepresentazio egokiaren adibideak hiztegi-elementuen ordena erakusten du, JSON errepresentazioaren aldean. Ezin dut ordena hau alde batera utzi: linealtasun hori dokumentu-ereduari eta XML formatuari dagokio. XML dokumentu hau interpretatzen duen norbaitek ordena hori alde batera uztea erabaki dezake, baina honi buruz eztabaidatzea alferrikakoa da, formatuaren beraren esparrutik haratago doalako. Gainera, dokumentua arakatzaile batean ikusgai egiten baduzu estilo-orri kaskada bat erantsiz, ikusiko duzu hiztegi-elementuek ordena zehatz bat jarraitzen dutela, eta ez beste bat.
Beste era batera esanda, hiztegi bat (datu egituratu bat) bihur daiteke n hainbat dokumentu posible (XML formatuan, PDFan, paperean, etab.), non n — hiztegian dauden elementuen konbinazio posibleen kopurua, eta oraindik ez ditugu kontuan hartu beste aldagai posibleak ere.
Hala ere, horrek esan nahi du datuak soilik transmititu nahi badituzu, makina batek irakur dezakeen dokumentu bat erabiltzea ez dela eraginkorra. Eredu erredundante bat erabiltzen du, eta oztopo baino ez du sortuko. Gainera, datu gordinak ateratzeak programazioa eskatzen du. Ez du zentzurik XML erabiltzea noizbait dokumentu gisa formateatu ez den ezertarako (adibidez, CSS edo XSLT erabiliz, edo biak), hau baita dokumentu-eredu bati eusteko arrazoi nagusia (bakarra ez bada).
Gainera, XML-k ez duenez zenbakien kontzepturik (edo adierazpen boolearrak, edo beste datu mota batzuk), formatu honetan adierazitako zenbaki guztiak testu gehigarri gisa hartzen dira. Datuak ateratzeko, eskema eta adierazten diren datuekin duen erlazioa ezagutu behar dira. Halaber, jakin behar da noiz, testuinguruaren arabera, testu-elementu jakin batek zenbaki bat adierazten duen eta zenbaki batera bihurtu behar den, eta abar.
Beraz, XML dokumentuetatik datuak ateratzeko prozesua ez da oso desberdina, adibidez, datu numerikoz osatutako hainbat orrialdeko taulak dituzten eskaneatutako dokumentuak ezagutzeko prozesutik. Printzipioz posible den arren, ez da ikuspegirik egokiena, agian azken aukera bat ez bada behintzat, beste aukerarik ez dagoenean. Irtenbide arrazoizko bat jatorrizko datuen kopia digital bat aurkitzea litzateke, datuak bere testu-adierazpen espezifikoarekin konbinatzen dituen dokumentu-eredu batean txertatu gabe.
Hala ere, ez nau batere harritzen XML negozioetan ezaguna izatea. Hain zuzen ere, dokumentuaren formatua (paperean) enpresentzat ulergarria eta ezaguna delako gertatzen da hori, eta eredu ezagun eta ulergarri hau erabiltzen jarraitu nahi dutelako. Arrazoi beragatik, enpresek askotan PDF dokumentuak erabiltzen dituzte makinak irakurtzeko moduko formatuagoen ordez, tamaina fisiko jakin bateko orrialde inprimatu baten nozioari lotuta jarraitzen dutelako. Hori inoiz inprimatuko ez diren dokumentuei ere aplikatzen zaie (adibidez, 8000 orrialdeko erregistro-dokumentazioaren PDF fitxategi bati). Ikuspegi honetatik, XML negozioetan erabiltzea funtsean eskeuomorfismoaren adierazpena da. Jendeak tamaina mugatuko orrialde inprimatu baten ideia metaforikoa ulertzen du, eta ulertzen du nola eraiki negozio-prozesuak dokumentu inprimatuetan oinarrituta. Hau zure gida bada, tamaina fisikoko mugarik gabeko dokumentuek, makinak irakurtzeko modukoak direnek, —XML dokumentuek— berrikuntza adierazten dute, dokumentu baten baliokide ezagun eta erosoa izaten jarraitzen duten bitartean. Horrek ez ditu eragozten datuak aurkezteko modu oker eta eskeuomorfiko gehiegi izaten jarraitzea.
Gaur egun, ezagutzen ditudan XML eskema bakarrak eta formatuaren aplikazio egoki dei ditzakedanak XHTML eta DocBook dira.
Iturria: www.habr.com
