Ang wikang XML ay naimbento noong 1996. Sa lalong madaling panahon na ito ay lumitaw na ang mga posibilidad ng aplikasyon nito ay nagsimula nang hindi maunawaan, at para sa mga layunin kung saan sinusubukan nilang iakma ito, hindi ito ang pinakamahusay na pagpipilian.
Hindi pagmamalabis na sabihin na ang karamihan sa mga XML schema na nakita ko ay hindi naaangkop o maling paggamit ng XML. Bukod dito, ang paggamit na ito ng XML ay nagpakita ng isang pangunahing hindi pagkakaunawaan sa kung ano ang XML.
Ang XML ay isang markup language. Hindi ito isang format ng data. Karamihan sa mga XML schema ay tahasang nakaligtaan ang pagkakaibang ito, na nakalilito sa XML sa isang format ng data, na sa huli ay nagreresulta sa isang pagkakamali sa pagpili ng XML dahil ito ang format ng data na talagang kailangan.
Nang walang masyadong maraming detalye, ang XML ay pinakaangkop para sa pag-annotate ng mga bloke ng teksto na may istraktura at metadata. Kung ang iyong pangunahing layunin ay hindi upang gumana sa isang bloke ng teksto, ang pagpili ng XML ay malamang na hindi makatwiran.
Mula sa puntong ito ng view, mayroong isang simpleng paraan upang suriin kung gaano kahusay ginawa ang XML schema. Kunin natin bilang isang halimbawa ang isang dokumento sa nilalayong schema at alisin ang lahat ng mga tag at attribute mula dito. Kung ang natitira ay walang katuturan (o kung may natitira pang blangkong linya), kung gayon ang iyong schema ay hindi nabuo nang tama o hindi ka dapat gumamit ng XML.
Sa ibaba ay magbibigay ako ng ilan sa mga pinakakaraniwang halimbawa ng maling pagkakagawa ng mga circuit.
<roΠΎt>
<item name="name" value="John" />
<item name="city" value="London" />
</roΠΎt>Dito makikita natin ang isang halimbawa ng isang walang batayan at kakaiba (bagaman napakakaraniwan) na pagtatangkang magpahayag ng isang simpleng key-value na diksyunaryo sa XML. Kung aalisin mo ang lahat ng mga tag at attribute, maiiwan ka ng isang walang laman na row. Sa esensya, ang dokumentong ito ay, gaano man ito kabaliwan, isang semantic na anotasyon ng isang walang laman na linya.
<root name="John" city="London" />Ang masama pa nito, hindi lang tayo mayroong semantic na anotasyon ng isang walang laman na string dito bilang isang napakagandang paraan ng pagpapahayag ng isang diksyunaryo - sa pagkakataong ito ang "diksyonaryo" ay direktang naka-encode bilang mga katangian ng elemento ng ugat. Ginagawa nitong hindi natukoy at dynamic ang ibinigay na hanay ng mga pangalan ng attribute sa isang elemento. Dagdag pa rito, ipinapakita nito na ang lahat ng gustong ipahayag ng may-akda ay isang simpleng key-value syntax, ngunit sa halip ay gumawa siya ng ganap na kakaibang desisyon na mag-apply ng XML, na pinilit ang paggamit ng isang walang laman na elemento bilang prefix lamang na gumamit ng attribute syntax. At madalas akong nakatagpo ng mga ganitong scheme.
<roΠΎt>
<item key="name">John</item>
<item key="city">London</item>
</roΠΎt>Ito ay isang bagay na mas mahusay, ngunit ngayon sa ilang kadahilanan ang mga susi ay metadata at ang mga halaga ay hindi. Isang napaka kakaibang pagtingin sa mga diksyunaryo. Kung aalisin mo ang lahat ng mga tag at attribute, mawawala ang kalahati ng impormasyon.
Ang tamang expression ng diksyunaryo sa XML ay magiging ganito:
<roΠΎt>
<item>
<key>Name</key>
<value>John</value>
</item>
<item>
<key>City</key>
<value>London</value>
</item>
</roΠΎt>Ngunit kung ang mga tao ay gumawa ng kakaibang desisyon na gamitin ang XML bilang isang format ng data at pagkatapos ay gamitin ito upang ayusin ang isang bokabularyo, dapat nilang maunawaan na ang kanilang ginagawa ay hindi naaangkop at hindi maginhawa. Karaniwan din para sa mga designer na magkamali sa pagpili ng XML upang likhain ang kanilang mga application. Ngunit mas madalas, pinapalala nila ang mga bagay sa pamamagitan ng walang kabuluhang paggamit ng XML sa isa sa mga form na inilarawan sa itaas, na binabalewala ang katotohanan na ang XML ay sadyang hindi angkop para dito.
Pinakamasamang XML Schema? Sa pamamagitan ng paraan, ang premyo para sa ang pinakamasamang XML schema na nakita ko, Nakukuha ang awtomatikong provisioning configuration file format para sa Polycom IP telephony phone. Ang mga nasabing file ay nangangailangan ng pag-download ng mga XML request file sa pamamagitan ng TFTP, na... Sa pangkalahatan, narito ang isang sipi mula sa isang ganoong file:
<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="..." />Hindi ito masamang biro ng isang tao. At hindi ito ang aking imbensyon:
- Ang mga elemento ay ginagamit lamang bilang isang prefix upang mag-attach ng mga katangian, na may mga hierarchical na pangalan mismo.
- Kung gusto mong magtalaga ng mga halaga sa maraming pagkakataon ng isang partikular na uri ng record, dapat kang gumamit ng mga pangalan ng katangian upang magawa ito. na may mga index.
- Bilang karagdagan, ang mga katangian na nagsisimula sa
softkey., ay dapat ilagay sa mga elemento<softkey/>, mga katangian na nagsisimula safeature., ay dapat ilagay sa mga elemento<feature/>atbp., sa kabila ng katotohanan na ito ay mukhang ganap na hindi kailangan at sa unang tingin ay walang kahulugan. - At sa wakas, kung umaasa kang ang unang bahagi ng isang pangalan ng katangian ay palaging pareho sa pangalan ng elemento - walang ganoon! Halimbawa, mga katangian
up.dapat ikabit sa<userpreferences/>. Ang pagkakasunud-sunod ng paglakip ng mga pangalan ng katangian sa mga elemento ay arbitrary, halos ganap.
Mga dokumento o datos. Paminsan-minsan, may gumagawa ng kakaiba sa pamamagitan ng pagsubok na ihambing ang XML at JSONβat sa gayon ay ipinapakita na hindi rin nila naiintindihan. Ang XML ay isang markup language ng dokumento. Ang JSON ay isang structured na format ng data, kaya ang paghahambing sa mga ito sa isa't isa ay parang sinusubukang ihambing ang mainit sa malambot.
Ang konsepto ng pagkakaiba sa pagitan ng mga dokumento at datos. Bilang isang analogue ng XML, maaari tayong kumuha ng isang dokumentong nababasa ng makina nang may kondisyon. Bagama't nilayon itong maging nababasa ng makina, ito ay tumutukoy sa metaporikal na mga dokumento, at mula sa puntong ito ng view ay talagang maihahambing sa mga dokumentong PDF, na kadalasang hindi nababasa ng makina.
Halimbawa, sa XML ang pagkakasunud-sunod ng mga elemento ay mahalaga. Ngunit sa JSON, ang pagkakasunud-sunod ng mga pares ng key-value sa loob ng mga object ay walang kahulugan at hindi natukoy. Kung gusto mong makakuha ng hindi nakaayos na diksyunaryo ng mga pares ng key-value, hindi mahalaga ang aktwal na pagkakasunud-sunod kung saan lumilitaw ang mga elemento sa file na iyon. Ngunit maaari kang bumuo ng maraming iba't ibang uri ng data mula sa data na ito. dokumento, dahil mayroong isang tiyak na pagkakasunud-sunod sa dokumento. Sa metaporikal, ito ay kahalintulad sa isang dokumento sa papel, bagama't wala itong mga pisikal na sukat, hindi tulad ng isang printout o PDF file.
Ang aking halimbawa ng tamang representasyon ng diksyunaryo ng XML ay nagpapakita ng pagkakasunud-sunod ng mga elemento sa diksyunaryo, kumpara sa representasyon ng JSON. Hindi ko maaaring balewalain ang order na ito: ang linearity na ito ay likas sa modelo ng dokumento at XML na format. Maaaring piliin ng ilan na huwag pansinin ang pagkakasunud-sunod kapag binibigyang kahulugan ang XML na dokumentong ito, ngunit walang punto sa pagtatalo tungkol dito dahil ang isyu ay lampas sa saklaw ng isang talakayan ng format mismo. Bukod dito, kung gagawin mong natitingnan ang dokumento sa browser sa pamamagitan ng pag-attach ng isang cascading style sheet dito, makikita mo na ang mga elemento ng diksyunaryo ay lilitaw sa isang tiyak na pagkakasunud-sunod at wala sa iba.
Sa madaling salita, ang isang diksyunaryo (isang piraso ng structured data) ay maaaring ma-convert sa n iba't ibang posibleng dokumento (sa XML, PDF, papel, atbp.), kung saan n - ang bilang ng mga posibleng kumbinasyon ng mga elemento sa diksyunaryo, at hindi pa namin isinasaalang-alang ang iba pang posibleng mga variable.
Gayunpaman, sinusunod din nito na kung nais mong maglipat lamang ng data, hindi magiging epektibo ang paggamit ng dokumentong nababasa ng makina para dito. Gumagamit ito ng isang modelo, na sa kasong ito ay kalabisan; ito ay makakasagabal lamang. Bilang karagdagan, upang kunin ang pinagmulan ng data, kakailanganin mong magsulat ng isang programa. Halos walang punto sa paggamit ng XML para sa isang bagay na hindi mapo-format bilang isang dokumento sa isang punto (sabihin, gamit ang CSS o XSLT, o pareho), dahil iyon ang pangunahing (kung hindi lamang) dahilan para gawin ito. upang sumunod sa modelo ng dokumento.
Bukod dito, dahil ang XML ay walang konsepto ng mga numero (o Boolean expression, o iba pang mga uri ng data), ang lahat ng mga numerong kinakatawan sa format na ito ay itinuturing na karagdagang teksto lamang. Upang kunin ang data, dapat malaman ang schema at ang kaugnayan nito sa kaukulang data na ipinapahayag. Kailangan mo ring malaman kung kailan, batay sa konteksto, ang isang partikular na elemento ng teksto ay kumakatawan sa isang numero at dapat na i-convert sa isang numero, atbp.
Kaya, ang proseso ng pagkuha ng data mula sa mga dokumentong XML ay hindi gaanong naiiba sa proseso ng pagkilala sa mga na-scan na dokumento na naglalaman, halimbawa, mga talahanayan na bumubuo ng maraming mga pahina ng numerical na data. Oo, posible na gawin ito sa prinsipyo, ngunit hindi ito ang pinakamainam na paraan, maliban bilang isang huling paraan, kapag walang ganap na iba pang mga pagpipilian. Ang isang makatwirang solusyon ay ang simpleng paghahanap ng digital na kopya ng orihinal na data na hindi naka-embed sa isang modelo ng dokumento na pinagsasama ang data sa partikular na representasyong tekstuwal nito.
Iyon ay sinabi, hindi ako nakakagulat na ang XML ay sikat sa negosyo. Ang dahilan nito ay tiyak na ang format ng dokumento (sa papel) ay nauunawaan at pamilyar sa negosyo, at gusto nilang patuloy na gumamit ng pamilyar at nauunawaan na modelo. Para sa parehong dahilan, ang mga negosyo ay masyadong madalas na gumagamit ng mga PDF na dokumento sa halip na mas maraming nababasa ng makina na mga format - dahil nakatali pa rin sila sa konsepto ng isang naka-print na pahina na may partikular na pisikal na laki. Nalalapat pa ito sa mga dokumentong malamang na hindi mai-print (halimbawa, isang 8000-pahinang PDF ng dokumentasyon ng pagpapatala). Mula sa puntong ito ng view, ang paggamit ng XML sa negosyo ay mahalagang pagpapakita ng skeuomorphism. Naiintindihan ng mga tao ang metaporikal na ideya ng isang naka-print na pahina na may limitadong laki, at naiintindihan nila kung paano lumikha ng mga proseso ng negosyo batay sa mga naka-print na dokumento. Kung iyon ang iyong gabay, ang mga dokumentong walang limitasyon sa pisikal na laki na nababasa ng makinaβmga XML na dokumentoβay kumakatawan sa pagbabago habang pamilyar at komportableng katapat ng dokumento. Hindi nito pinipigilan ang mga ito na manatili sa isang hindi tama at sobrang skeuomorphic na paraan ng pagpapakita ng data.
Sa ngayon, ang tanging XML schema na alam ko na talagang matatawag kong wastong paggamit ng format ay XHTML at DocBook.
Pinagmulan: www.habr.com