XML beveik visada naudojamas netinkamai

XML beveik visada naudojamas netinkamai
XML kalba buvo išrasta 1996 m. Vos jis pasirodė, jo taikymo galimybės jau buvo pradėtos neteisingai suprasti, o tikslams, kuriems buvo bandoma pritaikyti, tai nebuvo pats geriausias pasirinkimas.

Neperdedame teigti, kad didžioji dauguma XML schemų, kurias mačiau, yra netinkamas arba neteisingas XML naudojimas. Be to, šis XML naudojimas parodė esminį nesusipratimą, kas yra XML.

XML yra žymėjimo kalba. Tai nėra duomenų formatas. Daugumoje XML schemų šis skirtumas buvo aiškiai nepastebėtas, supainiojus XML su duomenų formatu, o tai galiausiai lemia XML pasirinkimą, nes iš tikrųjų reikia duomenų formato.

Per daug nesigilinant į detales, XML geriausiai tinka komentuoti teksto blokus su struktūra ir metaduomenimis. Jei jūsų pagrindinis tikslas nėra dirbti su teksto bloku, vargu ar bus pagrįstas XML pasirinkimas.

Šiuo požiūriu yra paprastas būdas patikrinti, kaip gerai sukurta XML schema. Paimkime kaip pavyzdį dokumentą numatytoje schemoje ir pašalinkime iš jo visas žymas ir atributus. Jei tai, kas liko, nėra prasminga (arba jei liko tuščia eilutė), jūsų schema sukurta netinkamai arba tiesiog neturėjote naudoti XML.

Žemiau pateiksiu keletą dažniausiai pasitaikančių neteisingai sukonstruotų grandinių pavyzdžių.

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

Čia matome nepagrįsto ir keisto (nors labai dažno) bandymo XML formatu išreikšti paprastą raktinių reikšmių žodyną pavyzdį. Jei pašalinsite visas žymas ir atributus, liksite tuščia eilutė. Iš esmės šis dokumentas, kad ir kaip absurdiškai skambėtų, yra semantinė tuščios eilutės anotacija.

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

Dar blogiau, kad čia ne tik tuščios eilutės semantinė anotacija kaip ekstravagantiškas žodyno išraiškos būdas – šį kartą „žodynas“ yra tiesiogiai užkoduotas kaip šakninio elemento atributai. Dėl to nurodytas elemento atributų pavadinimų rinkinys yra neapibrėžtas ir dinamiškas. Be to, tai rodo, kad viskas, ką autorius iš tikrųjų norėjo išreikšti, buvo paprasta rakto reikšmės sintaksė, tačiau vietoj to jis priėmė visiškai keistą sprendimą pritaikyti XML, priversdamas naudoti vieną tuščią elementą tiesiog kaip priešdėlį ir naudoti atributo sintaksę. Ir su tokiomis schemomis susiduriu labai dažnai.

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

Tai kažkas geresnio, bet dabar dėl tam tikrų priežasčių raktai yra metaduomenys, o reikšmės ne. Labai keistas žvilgsnis į žodynus. Jei pašalinsite visas žymas ir atributus, pusė informacijos bus prarasta.

Teisinga žodyno išraiška XML formatu atrodytų maždaug taip:

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

Tačiau jei žmonės priėmė keistą sprendimą naudoti XML kaip duomenų formatą ir naudoti jį žodynui tvarkyti, jie turėtų suprasti, kad tai, ką jie daro, yra netinkama ir nėra patogu. Taip pat dažnai dizaineriai klaidingai pasirenka XML kurdami savo programas. Tačiau dar dažniau jie pablogina padėtį, nes beprasmiškai naudoja XML viena iš aukščiau aprašytų formų, neatsižvelgiant į tai, kad XML tam tiesiog netinka.

Blogiausia XML schema? Beje, prizas už blogiausia XML schema, kurią aš kada nors mačiau, Gauna automatinio aprūpinimo konfigūracijos failo formatą, skirtą „Polycom“ IP telefonijos telefonams. Tokiems failams reikia atsisiųsti XML užklausų failus per TFTP, kuris... Apskritai, čia yra ištrauka iš vieno tokio failo:

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

Tai nėra kažkieno blogas pokštas. Ir čia ne mano išradimas:

  • elementai tiesiog naudojami kaip priešdėlis, norint pridėti atributus, kurie patys turi hierarchinius pavadinimus.
  • Jei norite priskirti reikšmes keliems tam tikro tipo įrašo egzemplioriams, tai turite naudoti atributų pavadinimus. kurios turi indeksus.
  • Be to, atributai prasidedantys softkey., turi būti dedamas ant elementų <softkey/>, atributai prasidedantys feature., turi būti dedamas ant elementų <feature/> ir pan., nepaisant to, kad tai atrodo visiškai nereikalinga ir iš pirmo žvilgsnio beprasmiška.
  • Ir galiausiai, jei tikėjotės, kad pirmasis atributo pavadinimo komponentas visada bus toks pat kaip elemento pavadinimas – nieko panašaus! Pavyzdžiui, atributai up. turi būti pritvirtintas prie <userpreferences/>. Atributų pavadinimų pridėjimo prie elementų tvarka yra savavališka, beveik visiškai.

Dokumentai ar duomenys. Retkarčiais kas nors padaro ką nors visiškai keisto, bandydamas palyginti XML ir JSON ir taip parodydamas, kad taip pat nesupranta. XML yra dokumentų žymėjimo kalba. JSON yra struktūrinių duomenų formatas, todėl lyginant juos vienas su kitu, panašu į bandymą palyginti šiltą su minkštu.

Skirtumo samprata tarp dokumentus ir duomenis. Kaip XML analogą galime sąlygiškai paimti mašininiu būdu skaitomą dokumentą. Nors jis skirtas mašininiam skaitymui, jis metaforiškai nurodo dokumentus ir šiuo požiūriu iš tikrųjų yra panašus į PDF dokumentus, kurie dažniausiai nėra nuskaitomi mašininiu būdu.

Pavyzdžiui, XML yra svarbi elementų tvarka. Tačiau JSON raktų ir reikšmių porų tvarka objektuose yra beprasmė ir neapibrėžta. Jei norite gauti nesutvarkytą raktų ir reikšmių porų žodyną, faktinė elementų rodymo tame faile tvarka neturi reikšmės. Tačiau iš šių duomenų galite sudaryti įvairių tipų duomenis. dokumentų, nes dokumente yra tam tikra tvarka. Metaforiškai jis yra analogiškas popieriniam dokumentui, nors neturi fizinių matmenų, skirtingai nei spaudinys ar PDF failas.

Mano tinkamo XML žodyno vaizdavimo pavyzdys rodo elementų tvarką žodyne, o ne JSON. Negaliu ignoruoti šios tvarkos: šis tiesiškumas būdingas dokumento modeliui ir XML formatui. Kai kurie gali nuspręsti nepaisyti tvarkos aiškindami šį XML dokumentą, tačiau nėra prasmės dėl to ginčytis, nes šis klausimas nepatenka į paties formato diskusijų sritį. Be to, jei padarysite dokumentą matomą naršyklėje, pridėdami prie jo pakopinį stiliaus lapą, pamatysite, kad žodyno elementai rodomi tam tikra tvarka, o ne kita.

Kitaip tariant, žodyną (struktūrinių duomenų dalį) galima konvertuoti į n įvairūs galimi dokumentai (XML, PDF, popieriniai ir kt.), kur n - galimų elementų kombinacijų skaičius žodyne, o į kitus galimus kintamuosius dar neatsižvelgėme.

Tačiau iš to taip pat išplaukia, kad jei norite perkelti tik duomenis, naudojant mašininio skaitomo dokumentą tai nebus veiksminga. Jis naudoja modelį, kuris šiuo atveju yra nereikalingas, jis tik trukdys. Be to, norint išgauti šaltinio duomenis, reikės parašyti programą. Vargu ar yra prasmės naudoti XML tam, kas tam tikru momentu nebus suformatuotas kaip dokumentas (tarkime, naudojant CSS arba XSLT, arba abu), nes tai yra pagrindinė (jei ne vienintelė) priežastis, kodėl taip reikia. prie dokumento modelio.

Be to, kadangi XML neturi skaičių (arba Būlio išraiškų ar kitų duomenų tipų) sąvokos, visi šiuo formatu pateikti skaičiai laikomi tik papildomu tekstu. Norint išgauti duomenis, turi būti žinoma schema ir jos ryšys su atitinkamais išreiškiamais duomenimis. Taip pat turite žinoti, kada, atsižvelgiant į kontekstą, tam tikras teksto elementas reiškia skaičių ir turi būti konvertuojamas į skaičių ir pan.

Taigi duomenų ištraukimo iš XML dokumentų procesas nelabai skiriasi nuo nuskaitytų dokumentų, kuriuose yra, pavyzdžiui, lentelių, sudarančių daug puslapių skaitinių duomenų, atpažinimo. Taip, iš principo tai padaryti galima, tačiau tai nėra pats optimaliausias būdas, nebent kraštutiniu atveju, kai visiškai nėra kitų galimybių. Tinkamas sprendimas yra tiesiog rasti skaitmeninę originalių duomenų kopiją, kuri nėra įterpta į dokumento modelį, kuriame duomenys sujungiami su specifiniu tekstiniu vaizdu.

Vis dėlto manęs visai nestebina, kad XML yra populiarus versle. To priežastis yra būtent tai, kad dokumento formatas (popieriuje) yra suprantamas ir pažįstamas verslui, todėl norima ir toliau naudoti pažįstamą ir suprantamą modelį. Dėl tos pačios priežasties įmonės per dažnai naudoja PDF dokumentus, o ne labiau mašininiu būdu nuskaitomus formatus, nes jie vis dar yra susieti su konkretaus fizinio dydžio spausdinto puslapio koncepcija. Tai netgi taikoma dokumentams, kurie greičiausiai niekada nebus atspausdinti (pvz., 8000 XNUMX puslapių registro dokumentų PDF). Šiuo požiūriu XML naudojimas versle iš esmės yra skeuomorfizmo apraiška. Žmonės supranta metaforinę riboto dydžio spausdinto puslapio idėją ir supranta, kaip kurti verslo procesus remiantis spausdintais dokumentais. Jei tai yra jūsų vadovas, dokumentai be fizinio dydžio apribojimų, kuriuos galima nuskaityti mašininiu būdu – XML dokumentai – yra naujovės, o kartu yra pažįstamas ir patogus dokumentų atitikmuo. Tai netrukdo jiems likti neteisingu ir pernelyg skeuomorfišku duomenų pateikimo būdu.

Iki šiol vienintelės žinomos XML schemos, kurias tikrai galiu pavadinti tinkamu formato naudojimu, yra XHTML ir DocBook.

Šaltinis: www.habr.com

Добавить комментарий