ProHoster > Blog > administratë > XML pothuajse gjithmonë keqpërdoret

XML pothuajse gjithmonë keqpërdoret

XML pothuajse gjithmonë keqpërdoret
Gjuha XML u shpik në vitin 1996. Sapo u shfaq, mundësitë e zbatimit të tij tashmë kishin filluar të keqkuptoheshin dhe për qëllimet me të cilat ata po përpiqeshin ta përshtatnin, nuk ishte zgjidhja më e mirë.

Nuk është ekzagjerim të thuhet se shumica dërrmuese e skemave XML që kam parë janë përdorime të papërshtatshme ose të pasakta të XML. Për më tepër, ky përdorim i XML-së demonstroi një keqkuptim themelor të asaj që kishte të bënte XML.

XML është një gjuhë shënjimi. Ky nuk është një format të dhënash. Shumica e skemave XML e kanë anashkaluar në mënyrë eksplicite këtë dallim, duke ngatërruar XML me një format të dhënash, gjë që përfundimisht rezulton në një gabim në zgjedhjen e XML sepse është formati i të dhënave që nevojitet në të vërtetë.

Pa hyrë në shumë detaje, XML është më i përshtatshmi për shënimin e blloqeve të tekstit me strukturë dhe meta të dhëna. Nëse qëllimi juaj kryesor nuk është të punoni me një bllok teksti, zgjedhja e XML nuk ka gjasa të justifikohet.

Nga ky këndvështrim, ekziston një mënyrë e thjeshtë për të kontrolluar se sa mirë është bërë skema XML. Le të marrim si shembull një dokument në skemën e synuar dhe të heqim të gjitha etiketat dhe atributet prej tij. Nëse ajo që ka mbetur nuk ka kuptim (ose nëse ka mbetur një rresht bosh), atëherë ose skema juaj nuk është ndërtuar si duhet ose thjesht nuk duhet të kishit përdorur XML.

Më poshtë do të jap disa nga shembujt më të zakonshëm të qarqeve të ndërtuara gabimisht.

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

Këtu shohim një shembull të një përpjekjeje të pabazë dhe të çuditshme (megjithëse shumë të zakonshme) për të shprehur një fjalor të thjeshtë me vlerë kyçe në XML. Nëse hiqni të gjitha etiketat dhe atributet, do të mbeteni me një rresht bosh. Në thelb, ky dokument është, sado absurd të duket, një shënim semantik i një rreshti bosh.

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

Për t'i bërë gjërat edhe më keq, ne nuk kemi vetëm një shënim semantik të një vargu bosh këtu si një mënyrë ekstravagante për të shprehur një fjalor - këtë herë "fjalori" është i koduar drejtpërdrejt si atribute të elementit rrënjë. Kjo e bën grupin e dhënë të emrave të atributeve në një element të papërcaktuar dhe dinamik. Për më tepër, tregon se gjithçka që autori dëshironte vërtet të shprehte ishte një sintaksë e thjeshtë me vlerë kyçe, por në vend të kësaj ai mori vendimin absolutisht të çuditshëm për të aplikuar XML, duke detyruar përdorimin e një elementi të vetëm bosh thjesht si një parashtesë për të përdorur sintaksën e atributeve. Dhe skema të tilla i has shumë shpesh.

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

Kjo është diçka më e mirë, por tani për disa arsye çelësat janë meta të dhëna dhe vlerat jo. Një vështrim shumë i çuditshëm në fjalorë. Nëse hiqni të gjitha etiketat dhe atributet, gjysma e informacionit do të humbet.

Një shprehje e saktë e fjalorit në XML do të dukej diçka si kjo:

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

Por nëse njerëzit kanë marrë vendimin e çuditshëm për të përdorur XML si një format të dhënash dhe më pas e përdorin atë për të organizuar një fjalor, atëherë ata duhet të kuptojnë se ajo që po bëjnë është e papërshtatshme dhe jo e përshtatshme. Është gjithashtu e zakonshme që projektuesit të zgjedhin gabimisht XML për të krijuar aplikacionet e tyre. Por edhe më shpesh, ata i bëjnë gjërat më keq duke përdorur në mënyrë të pakuptimtë XML në një nga format e përshkruara më sipër, duke injoruar faktin se XML thjesht nuk është i përshtatshëm për këtë.

Skema më e keqe XML? Nga rruga, çmimi për skema më e keqe XML që kam parë ndonjëherë, Merr formatin e skedarit të konfigurimit të sigurimit automatik për telefonat e telefonisë IP Polycom. Skedarë të tillë kërkojnë shkarkimin e skedarëve të kërkesës XML përmes TFTP, gjë që... Në përgjithësi, këtu është një fragment nga një skedar i tillë:

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

Kjo nuk është shaka e keqe e dikujt. Dhe kjo nuk është shpikja ime:

  • elementet përdoren thjesht si parashtesë për të bashkangjitur atributet, të cilat vetë kanë emra hierarkikë.
  • Nëse dëshironi të caktoni vlera në instanca të shumta të një lloji të caktuar regjistrimi, duhet të përdorni emrat e atributeve për ta bërë këtë. të cilat kanë indekse.
  • Përveç kësaj, atributet duke filluar me softkey., duhet të vendosen mbi elementë <softkey/>, atributet duke filluar me feature., duhet të vendosen mbi elementë <feature/> etj., pavarësisht se duket krejtësisht e panevojshme dhe në pamje të parë e pakuptimtë.
  • Dhe së fundi, nëse do të shpresonit që komponenti i parë i një emri atributi do të ishte gjithmonë i njëjtë me emrin e elementit - asgjë si kjo! Për shembull, atributet up. duhet t'i bashkëngjitet <userpreferences/>. Rendi i bashkëngjitjes së emrave të atributeve tek elementët është arbitrar, pothuajse plotësisht.

Dokumentet ose të dhënat. Herë pas here, dikush bën diçka krejtësisht të çuditshme duke u përpjekur të krahasojë XML dhe JSON—dhe duke treguar kështu se as ata nuk e kuptojnë. XML është një gjuhë shënjimi e dokumentit. JSON është një format i strukturuar i të dhënave, kështu që krahasimi i tyre me njëri-tjetrin është si të përpiqesh të krahasosh të ngrohtë me të butë.

Koncepti i ndryshimit midis dokumente dhe të dhëna. Si një analog i XML, ne mund të marrim me kusht një dokument të lexueshëm nga makina. Megjithëse synohet të jetë i lexueshëm nga makineri, ai i referohet në mënyrë metaforike dokumenteve dhe nga ky këndvështrim është në të vërtetë i krahasueshëm me dokumentet PDF, të cilat më shpesh nuk janë të lexueshme me makinë.

Për shembull, në XML renditja e elementeve ka rëndësi. Por në JSON, rendi i çifteve çelës-vlerë brenda objekteve është i pakuptimtë dhe i papërcaktuar. Nëse dëshironi të merrni një fjalor të parregulluar të çifteve të vlerave kyçe, rendi aktual në të cilin shfaqen elementët në atë skedar nuk ka rëndësi. Por ju mund të formoni shumë lloje të ndryshme të dhënash nga këto të dhëna. të dokumenteve, sepse ka një rend të caktuar në dokument. Metaforikisht, ai është analog me një dokument në letër, megjithëse nuk ka dimensione fizike, ndryshe nga një skedar i printuar ose PDF.

Shembulli im i një përfaqësimi të duhur të fjalorit XML tregon rendin e elementeve në fjalor, në krahasim me paraqitjen JSON. Nuk mund ta injoroj këtë renditje: ky linearitet është i natyrshëm në modelin e dokumentit dhe formatin XML. Disa mund të zgjedhin të shpërfillin rendin kur interpretojnë këtë dokument XML, por nuk ka kuptim të diskutojmë për këtë pasi çështja është përtej qëllimit të një diskutimi të vetë formatit. Për më tepër, nëse e bëni dokumentin të shikueshëm në shfletues duke i bashkangjitur një fletë stili kaskadë, do të shihni që elementët e fjalorit shfaqen në një rend të caktuar dhe në asnjë tjetër.

Me fjalë të tjera, një fjalor (një pjesë e të dhënave të strukturuara) mund të konvertohet në n dokumente të ndryshme të mundshme (në XML, PDF, letër, etj.), ku n - numri i kombinimeve të mundshme të elementeve në fjalor, dhe ne nuk kemi marrë ende parasysh variabla të tjerë të mundshëm.

Sidoqoftë, rrjedh gjithashtu se nëse doni të transferoni vetëm të dhëna, atëherë përdorimi i një dokumenti të lexueshëm nga makina për këtë nuk do të jetë efektiv. Ai përdor një model, i cili në këtë rast është i tepërt, ai vetëm do të pengojë. Përveç kësaj, për të nxjerrë të dhënat burimore, do t'ju duhet të shkruani një program. Nuk ka asnjë kuptim të përdorësh XML për diçka që nuk do të formatohet si dokument në një moment (të themi, duke përdorur CSS ose XSLT, ose të dyja), pasi kjo është arsyeja kryesore (nëse jo e vetmja) për ta bërë këtë. në modelin e dokumentit.

Për më tepër, duke qenë se XML nuk ka koncept të numrave (ose shprehjeve Boolean, ose llojeve të tjera të të dhënave), të gjithë numrat e përfaqësuar në këtë format konsiderohen thjesht tekst shtesë. Për të nxjerrë të dhëna, duhet të dihet skema dhe lidhja e saj me të dhënat përkatëse që shprehen. Ju gjithashtu duhet të dini se kur, bazuar në kontekstin, një element i veçantë teksti përfaqëson një numër dhe duhet të konvertohet në një numër, etj.

Kështu, procesi i nxjerrjes së të dhënave nga dokumentet XML nuk është aq i ndryshëm nga procesi i njohjes së dokumenteve të skanuara që përmbajnë, për shembull, tabela që formojnë shumë faqe të dhënash numerike. Po, është e mundur të bëhet kjo në parim, por kjo nuk është mënyra më optimale, përveç si mjeti i fundit, kur nuk ka absolutisht opsione të tjera. Një zgjidhje e arsyeshme është thjesht gjetja e një kopjeje dixhitale të të dhënave origjinale që nuk është e përfshirë në një model dokumenti që kombinon të dhënat me paraqitjen e tij specifike tekstuale.

Thënë kjo, nuk më befason aspak që XML është popullor në biznes. Arsyeja për këtë është pikërisht se formati i dokumentit (në letër) është i kuptueshëm dhe i njohur për biznesin, dhe ata duan të vazhdojnë të përdorin një model të njohur dhe të kuptueshëm. Për të njëjtën arsye, bizneset shumë shpesh përdorin dokumente PDF në vend të më shumë formateve të lexueshme nga makina - sepse ato janë ende të lidhura me konceptin e një faqeje të printuar me një madhësi fizike specifike. Kjo vlen edhe për dokumentet që nuk ka gjasa të printohen ndonjëherë (për shembull, një dokument PDF prej 8000 faqesh të regjistrit). Nga ky këndvështrim, përdorimi i XML në biznes është në thelb një manifestim i skeuomorfizmit. Njerëzit e kuptojnë idenë metaforike të një faqeje të printuar me madhësi të kufizuar dhe kuptojnë se si të krijojnë procese biznesi bazuar në dokumente të printuara. Nëse ky është udhëzuesi juaj, dokumentet pa kufizime të madhësisë fizike që janë të lexueshme nga makineri—dokumentet XML—përfaqësojnë risi, ndërkohë që janë një homolog i njohur dhe i rehatshëm i dokumentit. Kjo nuk i pengon ata të mbeten një mënyrë e pasaktë dhe tepër skeuomorfe e paraqitjes së të dhënave.

Deri më sot, të vetmet skema XML që unë njoh dhe që mund t'i quaj me të vërtetë një përdorim të vlefshëm të formatit janë XHTML dhe DocBook.

Burimi: www.habr.com

Shto një koment