XML este practic întotdeauna folosit în mod necorespunzător

Limbajul XML a fost inventat în 1996. Abia a apărut, când posibilitățile sale de utilizare au început deja să fie înțelese greșit, iar pentru scopurile la care a fost adaptat, nu a fost cea mai bună alegere.

Nu este o exagerare să spunem că majoritatea schemelor XML pe care le-am văzut reprezentau o utilizare ineficientă sau greșită a XML-ului. Mai mult, o astfel de utilizare a XML-ului indica o neînțelegere fundamentală a ceea ce este, în primul rând, XML.

XML este un limbaj de marcare. Nu este un format de date.. În majoritatea schemelor XML, această distincție nu a fost luată în considerare, confuzând XML-ul cu un format de date, ceea ce a dus la o alegere greșită a XML-ului, deoarece de fapt era necesar un format de date.

Fără a intra în detalii, XML-ul este cel mai potrivit pentru anotarea blocurilor de text cu structură și metadate. Dacă scopul principal nu este lucrul cu un bloc de text, alegerea XML-ului nu va fi justificată.

Din acest punct de vedere, există o modalitate simplă de a verifica cât de bine este realizată o schemă XML. Să luăm, de exemplu, un document în schema presupusă și să eliminăm toate etichetele și atributele. Dacă ceea ce rămâne nu are sens (sau dacă rămâne un șir gol), fie schema dvs. este construită greșit, fie pur și simplu nu ar fi trebuit să folosiți XML.

În continuare, voi prezenta câteva dintre cele mai frecvente exemple de scheme construite greșit.

Aici vedem un exemplu de tentativă nejustificată și ciudată (deși destul de răspândită) de a exprima, în limbajul XML, un simplu dicționar „cheie-valoare”. Dacă eliminăm toate etichetele și atributele, va rămâne un șir gol. Practic, acest document reprezintă, oricât de absurd ar părea, o anotare semantică a unui șir gol.

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

Ce e mai rău, avem aici nu doar o notare semantică a unei linii goale ca metodă extravagantă de a exprima un dicționar — de data aceasta „dicționarul” este codificat direct sub formă de atribute ale elementului rădăcină. Din această cauză, setul de nume de atribute atribuit elementului devine indefinit și dinamic. Mai mult, de aici se vede că tot ce a vrut de fapt să exprime autorul este un sintax simplu „cheie-valoare”, dar în loc să facă asta, a ales o soluție cu totul stranie prin aplicarea XML-ului, forțând utilizarea unui element gol singular pur și simplu ca prefix pentru sintaxa atributelor. Și astfel de scheme îmi apar foarte des.

John
  London

Asta e deja mai bine, dar acum cheile sunt dintr-un motiv oarecare metadate, iar valorile nu sunt. O viziune destul de ciudată asupra dicționarelor. Dacă ștergi toate etichetele și atributele, vei pierde jumătate din informații.

O exprimare corectă a unui dicționar în XML ar arăta cam așa:

Name
    John
  
  
    City
    London

Dar dacă oamenii au luat decizia stranie de a aplica XML ca format de date și apoi de a organiza dicționarul cu ajutorul său, ar trebui să înțeleagă că ceea ce fac este inadecvat și incomod. De asemenea, adesea proiectanții aleg greșit XML pentru a-și crea aplicațiile. Dar și mai des ei agravează situația prin utilizarea absurdă a XML-ului într-una din formele descrise mai sus, ignorând faptul că XML-ul pur și simplu nu este potrivit pentru asta.

Care este cea mai proastă schemă XML? Apropo, premiul pentru cea mai proastă schemă XML pe care am văzut-o merge la formatul de fișier de configurare a alocării automate de resurse pentru telefoanele IP de la Polycom. Aceste fișiere necesită descărcarea fișierelor XML de solicitare prin TFTP, care… Ei bine, iată un fragment dintr-un astfel de fișier:

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

Aceasta nu este o glumă nereușită a cuiva. Și nu este o invenție de-a mea:

• elementele sunt folosite pur și simplu ca un prefix pentru a atașa atribute, care în sine au denumiri ierarhice.
• Dacă este necesar să atașați valori mai multor instanțe ale unui înregistrări de un anumit tip, trebuie să utilizați denumirile atributelor, care au indici..
• În plus, atributele care încep cu softkey., trebuie plasate pe elemente <softkey/>, atributele care încep cu feature., trebuie plasate pe elemente <feature/> etc., deși acest lucru pare complet redundant și, la prima vedere, lipsit de sens.
• Și, în cele din urmă, dacă sperați că prima componentă a denumirii atributului coincide întotdeauna cu denumirea elementului - nimic mai fals! De exemplu, atributele up. trebuie atașate la <userpreferences/>. Ordinea atașării denumirilor atributelor la elemente este arbitrară, practic în întregime.

Documente sau date.Ocazional, cineva face lucruri complet ciudate, încercând să compare XML și JSON, arătând astfel că nu înțelege niciuna dintre acestea. XML este un limbaj de marcare a documentelor. JSON, pe de altă parte, reprezintă un format de date structurate, așa că a le compara între ele este la fel ca și cum ați încerca să comparați caldul cu moale.

A înțelege acest lucru va ajuta la înțelegerea diferenței dintre documente și date.Ca analog în XML, putem considera un document citibil de mașină. Chiar dacă este destinat citirii de către mașini, din punct de vedere metaforic se referă la documente și, din această perspectivă, este de fapt comparabil cu documentele în format PDF, care de cele mai multe ori nu sunt citibile de mașină.

De exemplu, în XML ordinea elementelor contează. Iar în JSON ordinea perechilor "cheie-valoare" în cadrul obiectelor nu are sens și nu este definită. Dacă doriți să obțineți un dicționar neordonat din perechi "cheie-valoare", ordinea efectivă în care urmează elementele în acest fișier nu are importanță. Dar din aceste date puteți crea multe documente diferite, deoarece în document există o ordine specifică.Metaforic, acesta este analogul unui document pe hârtie, deși nu are dimensiuni fizice spre deosebire de o tipăritură sau un fișier PDF.

În exemplul meu de reprezentare corectă a unui dicționar în limbajul XML, este arătată succesiunea elementelor din dicționar, diferită de reprezentarea în limbajul JSON. Nu pot ignora această succesiune: o astfel de liniaritate este într-adevăr propriu-zisă modelului documentelor și formatului XML. Cineva, la interpretarea acestui document XML, ar putea decide să ignore ordinea, dar a discuta despre acest aspect este inutil, deoarece această problemă depășește cadrul de discuție al formatului în sine. În plus, dacă documentul este făcut vizibil într-un browser, atașându-i un stylesheet, se va putea observa că elementele dicționarului urmează un anumit ordine și nimic altceva.

Cu alte cuvinte, dicționarul (fragment de date structurate) poate fi transformat în n diverse documente posibile (în format XML, PDF, pe hârtie etc.), unde n — numărul combinațiilor posibile de elemente în dicționar, și nu am considerat încă alte variabile posibile.

De asemenea, reiese că, dacă doriți să transmiteți doar datele, utilizarea unui document lizibil de mașină nu va fi eficientă. Acesta folosește un model care devine redundant în acest caz, doar va deranja. Mai mult, pentru a extrage datele originale, va trebui să scrieți un program. Probabil că nu are sens să folosiți XML pentru ceva ce într-un anumit stadiu nu va fi formatat ca un document (de exemplu, folosind CSS sau XSLT, sau ambele), deoarece aceasta este principala (dacă nu singura) motivare pentru a adera la modelul documentului.

Mai mult, deoarece în XML nu există conceptul de numere (sau expresii booleene, ori alte tipuri de date), toate numerele prezentate în acest format sunt considerate doar text suplimentar. Pentru a extrage datele, trebuie să fie cunoscut schema și legătura ei cu datele exprimate corespunzător. De asemenea, trebuie să se știe, în funcție de context, când un anumit element de text reprezintă un număr și trebuie convertit într-un număr etc.

Astfel, procesul de extragere a datelor din documente XML nu diferă atât de mult de procesul de recunoaștere a documentelor scanate, care conțin, de exemplu, tabele ce formează pagini multiple de date numerice. Da, este posibil în principiu, dar nu este cea mai optimă soluție, cu excepția cazului extrem în care nu sunt disponibile alte opțiuni. O soluție rațională ar fi să găsiți o copie digitală a datelor originale, fără a le integra într-un model de document unde datele sunt combinate cu reprezentarea lor textuală specifică.

În acest context, nu mă miră deloc că XML este popular în afaceri. Motivul este tocmai acela că formatul documentelor (pe hârtie) este clar și familiar pentru afaceri, unde se dorește continuarea utilizării unui model cunoscut și ușor de înțeles. Din același motiv, se folosesc prea des documente PDF în loc de formate mai prietenoase pentru procesarea automată - pentru că sunt în continuare legate de conceptul de pagină tipărită cu o dimensiune fizică specifică. Acest lucru se aplică chiar și documentelor care, probabil, nu vor fi niciodată tipărite (de exemplu, un fișier PDF de documentație a registrului de 8000 de pagini). Din această perspectivă, utilizarea XML în afaceri reprezintă în esență o manifestare a skeuomorfismului. Oamenii înțeleg ideea metaforică a paginii tipărite de dimensiuni limitate și știu cum să creeze procese de afaceri bazate pe documente tipărite. Dacă acesta este punctul dumneavoastră de referință, documentele fără o dimensiune fizică limitată, care sunt ușor de citit de mașini - documentele XML - reprezintă o inovație, fiind în același timp un analog familiar și confortabil al documentului. Totuși, acest lucru nu împiedică păstrarea unei metode eronate și exagerat de skeuomorfe de prezentare a datelor.

Până în prezent, singurele scheme XML, pe care le pot considera aplicații corecte ale acestui format, sunt XHTML și DocBook.

Sursa: habr.com