ProHoster > Blogs > Administrācija > XML gandrīz vienmēr tiek izmantots nepareizi

XML gandrīz vienmēr tiek izmantots nepareizi

XML gandrīz vienmēr tiek izmantots nepareizi
XML valoda tika izgudrota 1996. gadā. TiklÄ«dz tas parādÄ«jās, tā pielietoÅ”anas iespējas jau bija sākuÅ”as pārprast, un mērÄ·iem, kādiem viņi to mēģināja pielāgot, tā nebija labākā izvēle.

Nav pārspÄ«lēts teikt, ka lielākā daļa XML shēmu, ko esmu redzējis, bija neatbilstoÅ”s vai nepareizs XML lietojums. Turklāt Ŕī XML izmantoÅ”ana parādÄ«ja bÅ«tisku pārpratumu par XML bÅ«tÄ«bu.

XML ir iezÄ«mÄ“Å”anas valoda. Å is nav datu formāts. Lielākā daļa XML shēmu ir nepārprotami ignorējuÅ”as Å”o atŔķirÄ«bu, sajaucot XML ar datu formātu, kas galu galā rada kļūdu, izvēloties XML, jo tas ir datu formāts, kas patiesÄ«bā ir vajadzÄ«gs.

Neiedziļinoties detaļās, XML ir vislabāk piemērots teksta bloku anotÄ“Å”anai ar struktÅ«ru un metadatiem. Ja jÅ«su galvenais mērÄ·is nav strādāt ar teksta bloku, XML izvēle, visticamāk, nebÅ«s pamatota.

No Ŕī viedokļa ir vienkārÅ”s veids, kā pārbaudÄ«t, cik labi ir izveidota XML shēma. Ņemsim par piemēru dokumentu iecerētajā shēmā un noņemsim no tā visus tagus un atribÅ«tus. Ja tam, kas ir palicis, nav jēgas (vai ja ir palikusi tukÅ”a rindiņa), vai nu shēma nav izveidota pareizi, vai arÄ« jums vienkārÅ”i nevajadzēja izmantot XML.

Tālāk es sniegÅ”u dažus no visbiežāk sastopamajiem nepareizi konstruētu ķēžu piemēriem.

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

Å eit mēs redzam piemēru nepamatotam un dÄ«vainam (lai gan ļoti izplatÄ«tam) mēģinājumam izteikt vienkārÅ”u atslēgas vērtÄ«bu vārdnÄ«cu XML formātā. Ja noņemsit visus tagus un atribÅ«tus, tiks atstāta tukÅ”a rinda. BÅ«tÄ«bā Å”is dokuments, lai arÄ« cik absurdi tas neizklausÄ«tos, ir tukÅ”as rindas semantiskā anotācija.

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

Lai padarÄ«tu situāciju vēl ļaunāku, mums Å”eit ir ne tikai tukÅ”as virknes semantiskā anotācija kā ekstravagants vārdnÄ«cas izteiksmes veids - Å”oreiz "vārdnÄ«ca" ir tieÅ”i kodēta kā saknes elementa atribÅ«ti. Tas padara norādÄ«to elementa atribÅ«tu nosaukumu kopu nedefinētu un dinamisku. Turklāt tas parāda, ka viss, ko autors patieŔām vēlējās izteikt, bija vienkārÅ”a atslēgas vērtÄ«bas sintaksi, bet tā vietā viņŔ pieņēma absolÅ«ti dÄ«vainu lēmumu lietot XML, liekot izmantot vienu tukÅ”u elementu vienkārÅ”i kā prefiksu, lai izmantotu atribÅ«tu sintaksi. Un ar Ŕādām shēmām es sastopos ļoti bieži.

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

Tas ir kaut kas labāks, taču tagad kaut kādu iemeslu dēļ atslēgas ir metadati, bet vērtības nav. Ļoti dīvains skats uz vārdnīcām. Ja noņemsit visus tagus un atribūtus, puse informācijas tiks zaudēta.

Pareiza vārdnÄ«cas izteiksme XML formātā izskatÄ«tos apmēram Ŕādi:

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

Bet, ja cilvēki ir pieņēmuÅ”i dÄ«vainu lēmumu izmantot XML kā datu formātu un pēc tam to izmantot, lai sakārtotu vārdu krājumu, tad viņiem vajadzētu saprast, ka tas, ko viņi dara, ir nepiemēroti un nav ērti. Tāpat bieži vien dizaineri kļūdaini izvēlas XML, lai izveidotu savas lietojumprogrammas. Bet vēl biežāk tie pasliktina situāciju, bezjēdzÄ«gi izmantojot XML kādā no iepriekÅ” aprakstÄ«tajām formām, ignorējot faktu, ka XML tam vienkārÅ”i nav piemērots.

Sliktākā XML shēma? Starp citu, balva par sliktākā XML shēma, ko esmu redzējis, IegÅ«st automātiskās nodroÅ”ināŔanas konfigurācijas faila formātu Polycom IP telefonijas tālruņiem. Šādiem failiem ir nepiecieÅ”ams lejupielādēt XML pieprasÄ«juma failus, izmantojot TFTP, kas... Kopumā Å”eit ir izvilkums no viena Ŕāda faila:

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

Tas nav neviena slikta joks. Un tas nav mans izgudrojums:

  • elementi tiek vienkārÅ”i izmantoti kā prefikss, lai pievienotu atribÅ«tus, kuriem paÅ”iem ir hierarhiski nosaukumi.
  • Ja vēlaties pieŔķirt vērtÄ«bas vairākiem noteikta veida ieraksta gadÄ«jumiem, jums ir jāizmanto atribÅ«tu nosaukumi. kuriem ir indeksi.
  • Turklāt atribÅ«ti, kas sākas ar softkey., jānovieto uz elementiem <softkey/>, atribÅ«ti, sākot ar feature., jānovieto uz elementiem <feature/> utt., neskatoties uz to, ka tas izskatās pilnÄ«gi nevajadzÄ«gi un no pirmā acu uzmetiena bezjēdzÄ«gi.
  • Un visbeidzot, ja jÅ«s cerat, ka atribÅ«ta nosaukuma pirmais komponents vienmēr bÅ«s tāds pats kā elementa nosaukums - nekas tamlÄ«dzÄ«gs! Piemēram, atribÅ«ti up. ir jāpievieno <userpreferences/>. AtribÅ«tu nosaukumu pievienoÅ”anas secÄ«ba elementiem ir patvaļīga, gandrÄ«z pilnÄ«ga.

Dokumenti vai dati. Ik pa laikam kāds izdara kaut ko pavisam dÄ«vainu, mēģinot salÄ«dzināt XML un JSON, tādējādi parādot, ka arÄ« nesaprot. XML ir dokumentu iezÄ«mÄ“Å”anas valoda. JSON ir strukturēts datu formāts, tāpēc to salÄ«dzināŔana ir kā mēģinājums salÄ«dzināt silto ar mÄ«kstu.

Jēdziens par atŔķirÄ«bu starp dokumentus un datus. Kā XML analogu mēs varam nosacÄ«ti ņemt maŔīnlasāmu dokumentu. Lai gan tas ir paredzēts kā maŔīnlasāms, tas metaforiski attiecas uz dokumentiem, un no Ŕī viedokļa faktiski ir salÄ«dzināms ar PDF dokumentiem, kas visbiežāk nav maŔīnlasāmi.

Piemēram, XML ir svarÄ«ga elementu secÄ«ba. Taču JSON atslēgu un vērtÄ«bu pāru secÄ«ba objektos ir bezjēdzÄ«ga un nenoteikta. Ja vēlaties iegÅ«t nesakārtotu atslēgu un vērtÄ«bu pāru vārdnÄ«cu, faktiskajai secÄ«bai, kādā elementi tiek parādÄ«ti Å”ajā failā, nav nozÄ«mes. Taču no Å”iem datiem varat veidot dažādu veidu datus. dokumentus, jo dokumentā ir noteikta kārtÄ«ba. Metaforiski tas ir lÄ«dzÄ«gs dokumentam uz papÄ«ra, lai gan tam nav fizisko izmēru, atŔķirÄ«bā no izdrukas vai PDF faila.

Mans pareizas XML vārdnÄ«cas attēlojuma piemērs parāda elementu secÄ«bu vārdnÄ«cā pretstatā JSON attēlojumam. Es nevaru ignorēt Å”o secÄ«bu: Ŕī linearitāte ir raksturÄ«ga dokumenta modelim un XML formātam. Daži, interpretējot Å”o XML dokumentu, var izvēlēties ignorēt Å”o secÄ«bu, taču nav jēgas par to strÄ«dēties, jo Ŕī problēma neietilpst diskusijā par paÅ”u formātu. Turklāt, ja padarÄ«sit dokumentu skatāmu pārlÅ«kprogrammā, pievienojot tam kaskādes stila lapu, redzēsit, ka vārdnÄ«cas elementi parādās noteiktā secÄ«bā, nevis citā.

Citiem vārdiem sakot, vārdnÄ«cu (strukturētu datu daļu) var pārveidot par n dažādi iespējamie dokumenti (XML, PDF, papÄ«ra utt.), kur n - iespējamo elementu kombināciju skaits vārdnÄ«cā, un mēs vēl neesam ņēmuÅ”i vērā citus iespējamos mainÄ«gos.

Tomēr no tā izriet arÄ« tas, ka, ja vēlaties pārsÅ«tÄ«t tikai datus, maŔīnlasāma dokumenta izmantoÅ”ana Å”im nolÅ«kam nebÅ«s efektÄ«va. Tas izmanto modeli, kas Å”ajā gadÄ«jumā ir lieks, tas tikai traucēs. Turklāt, lai iegÅ«tu avota datus, jums bÅ«s jāraksta programma. Diez vai ir jēgas izmantot XML kaut kam, kas kādā brÄ«dÄ« netiks formatēts kā dokuments (piemēram, izmantojot CSS vai XSLT, vai abus), jo tas ir galvenais (ja ne vienÄ«gais) iemesls to darÄ«t. uz dokumenta modeli.

Turklāt, tā kā XML nav skaitļu (vai BÅ«la izteiksmju vai citu datu tipu) jēdziena, visi Å”ajā formātā attēlotie skaitļi tiek uzskatÄ«ti tikai par papildu tekstu. Lai iegÅ«tu datus, ir jāzina shēma un tās saistÄ«ba ar attiecÄ«gajiem izteiktajiem datiem. Jums arÄ« jāzina, kad, pamatojoties uz kontekstu, konkrēts teksta elements apzÄ«mē skaitli un ir jāpārvērÅ” par skaitli utt.

Tādējādi datu iegÅ«Å”anas process no XML dokumentiem tik ļoti neatŔķiras no skenētu dokumentu atpazÄ«Å”anas procesa, kas satur, piemēram, tabulas, kas veido daudzas skaitlisku datu lappuses. Jā, principā to ir iespējams izdarÄ«t, taču tas nav optimālākais veids, izņemot kā pēdējo lÄ«dzekli, kad nav absolÅ«ti nekādu citu iespēju. SaprātÄ«gs risinājums ir vienkārÅ”i atrast oriÄ£inālo datu digitālu kopiju, kas nav iegulta dokumenta modelÄ«, kas apvieno datus ar to specifisko teksta attēlojumu.

To sakot, mani nemaz nepārsteidz, ka XML ir populārs biznesā. Iemesls tam ir tieÅ”i tas, ka dokumenta formāts (uz papÄ«ra) ir uzņēmējiem saprotams un pazÄ«stams, un viņi vēlas arÄ« turpmāk izmantot pazÄ«stamu un saprotamu modeli. Tā paÅ”a iemesla dēļ uzņēmumi pārāk bieži izmanto PDF dokumentus, nevis maŔīnlasāmākus formātus, jo tie joprojām ir saistÄ«ti ar drukātas lapas jēdzienu ar noteiktu fizisko izmēru. Tas attiecas pat uz dokumentiem, kuri, visticamāk, nekad netiks izdrukāti (piemēram, 8000 lappuÅ”u reÄ£istra dokumentācijas PDF). No Ŕī viedokļa XML izmantoÅ”ana uzņēmējdarbÄ«bā bÅ«tÄ«bā ir skeuomorfisma izpausme. Cilvēki saprot metaforisko ideju par ierobežota izmēra drukātu lapu un saprot, kā izveidot biznesa procesus, pamatojoties uz drukātiem dokumentiem. Ja tas ir jÅ«su ceļvedis, dokumenti bez fiziska izmēra ierobežojumiem, kas ir maŔīnlasāmi ā€” XML dokumenti ā€” ir jauninājumi, vienlaikus labi pazÄ«stami un ērti dokumenti. Tas neliedz tiem palikt par nepareizu un pārāk skeuomorfisku datu prezentÄ“Å”anas veidu.

LÄ«dz Å”im vienÄ«gās XML shēmas, kuras es zinu, ko es patieŔām varu saukt par derÄ«gu formāta lietojumu, ir XHTML un DocBook.

Avots: www.habr.com

Pievieno komentāru