XML estas preskaŭ ĉiam misuzata

La XML-lingvo estis inventita en 1996. Apenaŭ ĝi aperis, la eblecoj de ĝia aplikado jam komencis esti miskomprenitaj, kaj por la celoj, al kiuj oni klopodis adapti ĝin, ĝi ne estis la plej bona elekto.

Ne estas troigo diri, ke la granda plimulto de XML-skemoj, kiujn mi vidis, estas netaŭgaj aŭ malĝustaj uzoj de XML. Krome, ĉi tiu uzo de XML montris fundamentan miskomprenon pri kio XML temis.

XML estas marka lingvo. Ĉi tio ne estas datumformato. La plej multaj XML-skemoj eksplicite preteratentis tiun distingon, konfuzante XML kun datumformato, kiu finfine rezultigas eraron en elektado de XML ĉar ĝi estas la datumformato kiu estas fakte bezonata.

Sen eniri tro da detaloj, XML plej taŭgas por komentarii tekstoblokojn kun strukturo kaj metadatenoj. Se via ĉefa celo estas ne labori kun bloko de teksto, elektado de XML verŝajne ne praviĝos.

De ĉi tiu vidpunkto, estas simpla maniero kontroli kiom bone la XML-skemo estas farita. Ni prenu kiel ekzemplon dokumenton en la celita skemo kaj forigu ĉiujn etikedojn kaj atributojn de ĝi. Se kio restas ne havas sencon (aŭ se restas malplena linio), tiam aŭ via skemo ne estas konstruita ĝuste aŭ vi simple ne devus uzi XML.

Malsupre mi donos kelkajn el la plej oftaj ekzemploj de malĝuste konstruitaj cirkvitoj.

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

Ĉi tie ni vidas ekzemplon de senbaza kaj stranga (kvankam tre ofta) provo esprimi simplan ŝlosilvaloran vortaron en XML. Se vi forigas ĉiujn etikedojn kaj atributojn, vi restos kun malplena vico. Esence, ĉi tiu dokumento estas, kiom ajn absurda ĝi sonas, semantika komentario de malplena linio.

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

Por plimalbonigi la aferojn, ni ne havas ĉi tie nur semantikan komentarion de malplena ĉeno kiel ekstravagancan manieron esprimi vortaron - ĉi-foje la "vortaro" estas rekte kodita kiel atributoj de la radika elemento. Ĉi tio faras la donitan aron de atributonomoj sur elemento nedifinita kaj dinamika. Plie, ĝi montras, ke ĉio, kion la aŭtoro vere volis esprimi, estis simpla ŝlosilvalora sintakso, sed anstataŭe li faris la absolute bizaran decidon apliki XML, devigante la uzon de ununura malplena elemento simple kiel prefikso por uzi atributan sintakson. Kaj mi renkontas tiajn skemojn tre ofte.

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

Ĉi tio estas io pli bona, sed nun ial la ŝlosiloj estas metadatenoj kaj la valoroj ne. Tre stranga rigardo al vortaroj. Se vi forigas ĉiujn etikedojn kaj atributojn, duono de la informoj perdiĝos.

Ĝusta vortara esprimo en XML aspektus kiel ĉi tio:

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

Sed se homoj faris la strangan decidon uzi XML kiel datumformaton kaj poste uzi ĝin por organizi vortprovizon, tiam ili komprenu, ke tio, kion ili faras, estas netaŭga kaj ne oportuna. Ankaŭ kutimas ke dizajnistoj erare elektas XML por krei siajn aplikaĵojn. Sed eĉ pli ofte, ili plimalbonigas la aferon per sensenca uzado de XML en unu el la supre priskribitaj formoj, ignorante la fakton, ke XML simple ne taŭgas por tio.

Plej malbona XML-skemo? Cetere, la premio por la plej malbona XML-skemo, kiun mi iam vidis, Akiras la aŭtomatan provizoran agordan dosierformaton por Polycom IP-telefonaj telefonoj. Tiaj dosieroj postulas elŝuti XML-petajn dosierojn per TFTP, kio... Ĝenerale, jen eltiraĵo de unu tia dosiero:

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

Ĉi tio ne estas ies malbona ŝerco. Kaj ĉi tio ne estas mia invento:

• elementoj estas simple uzataj kiel prefikso por alkroĉi atributojn, kiuj mem havas hierarkiajn nomojn.
• Se vi volas asigni valorojn al pluraj okazoj de aparta tipo de registro, vi devas uzi atributajn nomojn por fari tion. kiuj havas indeksojn.
• Krome, atributoj komencante per softkey., devas esti metita sur elementojn <softkey/>, atributoj komencante per feature., devas esti metita sur elementojn <feature/> ktp., malgraŭ tio, ke ĝi aspektas tute nenecesa kaj unuavide sensenca.
• Kaj finfine, se vi esperus, ke la unua komponanto de atributnomo ĉiam estus la sama kiel la elementonomo - nenio tia! Ekzemple, atributoj up. devas esti alkroĉita al <userpreferences/>. La ordo de aldono de atributonomoj al elementoj estas arbitra, preskaŭ tute.

Dokumentoj aŭ datumoj. De tempo al tempo, iu faras ion tute strangan provante kompari XML kaj JSON—kaj tiel montrante, ke ili ankaŭ ne komprenas. XML estas dokumentmarklingvo. JSON estas strukturita datumformato, do kompari ilin unu kun la alia estas kiel provi kompari varman kun mola.

La koncepto de la diferenco inter dokumentoj kaj datumoj. Kiel analogo de XML, ni povas kondiĉe preni maŝinlegeblan dokumenton. Kvankam ĝi celas esti maŝinlegebla, ĝi rilatas metafore al dokumentoj, kaj el ĉi tiu vidpunkto fakte estas komparebla al PDF-dokumentoj, kiuj plej ofte ne estas maŝinlegeblaj.

Ekzemple, en XML gravas la ordo de elementoj. Sed en JSON, la ordo de ŝlosil-valoraj paroj ene de objektoj estas sensignifa kaj nedifinita. Se vi volas akiri neordigitan vortaron de ŝlosil-valoraj paroj, la reala ordo en kiu la elementoj aperas en tiu dosiero ne gravas. Sed vi povas formi multajn malsamajn specojn de datumoj el ĉi tiuj datumoj. de dokumentoj, ĉar estas certa ordo en la dokumento. Metafore, ĝi estas analoga al dokumento sur papero, kvankam ĝi ne havas fizikajn dimensiojn, male al printaĵo aŭ PDF-dosiero.

Mia ekzemplo de taŭga XML-vortara reprezento montras la ordon de la elementoj en la vortaro, kontraste al la JSON-reprezento. Mi ne povas ignori ĉi tiun ordon: ĉi tiu lineareco estas propra al la dokumentmodelo kaj XML-formato. Iuj eble elektos ignori la ordon dum interpretado de ĉi tiu XML-dokumento, sed ne utilas argumenti pri tio ĉar la afero estas preter la amplekso de diskuto pri la formato mem. Cetere, se vi igas la dokumenton videbla en la retumilo alkirante al ĝi kaskadan stilfolion, vi vidos, ke la vortarelementoj aperas en certa ordo kaj en neniu alia.

Alivorte, vortaro (peco de strukturita datumo) povas esti konvertita en n diversaj eblaj dokumentoj (en XML, PDF, papero, ktp.), kie n - la nombro de eblaj kombinaĵoj de elementoj en la vortaro, kaj ni ankoraŭ ne konsideris aliajn eblajn variablojn.

Tamen ankaŭ sekvas, ke se vi volas transdoni nur datumojn, tiam uzi maŝinlegeblan dokumenton por tio ne estos efika. Ĝi uzas modelon, kiu ĉi-kaze estas superflua; ĝi nur malhelpos. Krome, por ĉerpi la fontajn datumojn, vi devos verki programon. Apenaŭ utilas uzi XML por io, kio iam ne estos formatita kiel dokumento (ekzemple, uzante CSS aŭ XSLT aŭ ambaŭ), ĉar tio estas la ĉefa (se ne la sola) kialo por fari tion. al la dokumentmodelo.

Krome, ĉar XML ne havas koncepton de nombroj (aŭ Buoleaj esprimoj, aŭ aliajn datumtipojn), ĉiuj nombroj reprezentitaj en ĉi tiu formato estas konsiderataj nur kroma teksto. Por ĉerpi datumojn, la skemo kaj ĝia rilato al la respondaj datumoj esprimitaj devas esti konataj. Vi ankaŭ devas scii kiam, surbaze de la kunteksto, aparta teksta elemento reprezentas nombron kaj devus esti konvertita al nombro, ktp.

Tiel, la procezo ĉerpi datumojn el XML-dokumentoj ne tiom diferencas de la procezo rekoni skanitajn dokumentojn enhavantajn, ekzemple, tabelojn formantajn multajn paĝojn de nombraj datumoj. Jes, principe eblas fari ĉi tion, sed ĉi tio ne estas la plej optimuma maniero, krom kiel lasta rimedo, kiam absolute ne ekzistas aliaj ebloj. Akceptebla solvo estas simple trovi ciferecan kopion de la originaj datumoj, kiu ne estas enigita en dokumentmodelo kiu kombinas la datumojn kun sia specifa teksta reprezentado.

Dirite, tute ne surprizas min, ke XML estas populara en komerco. La kialo de tio estas ĝuste ke la dokumentformato (surpapere) estas komprenebla kaj konata al komerco, kaj ili volas daŭre uzi konatan kaj kompreneblan modelon. Pro la sama kialo, entreprenoj tro ofte uzas PDF-dokumentojn anstataŭ pli maŝinlegeblajn formatojn - ĉar ili ankoraŭ estas ligitaj al la koncepto de presita paĝo kun specifa fizika grandeco. Ĉi tio eĉ validas por dokumentoj, kiuj verŝajne neniam estos presitaj (ekzemple, 8000-paĝa PDF de registra dokumentaro). De ĉi tiu vidpunkto, la uzo de XML en komerco estas esence manifestiĝo de skeuomorfismo. Homoj komprenas la metaforan ideon de presita paĝo de limigita grandeco, kaj ili komprenas kiel krei komercajn procezojn bazitajn sur presitaj dokumentoj. Se tio estas via gvidilo, dokumentoj sen fizikaj grandecaj limigoj, kiuj estas maŝinlegeblaj—XML-dokumentoj—reprezentas novigon estante konata kaj komforta dokumentekvivalento. Ĉi tio ne malhelpas ilin resti malĝusta kaj tro skeuomorfa maniero prezenti datumojn.

Ĝis nun, la nuraj XML-skemoj pri kiuj mi konas, kiujn mi povas vere nomi valida uzo de la formato, estas XHTML kaj DocBook.

fonto: www.habr.com