XML è quasi sempre utilizzato in modo improprio

Il linguaggio XML è stato inventato nel 1996. Appena apparso, le possibilità della sua applicazione avevano già cominciato a essere fraintese, e per gli scopi ai quali si cercava di adattarlo, non era la scelta migliore.

Non è esagerato affermare che la stragrande maggioranza degli schemi XML che ho visto erano usi inappropriati o errati di XML. Inoltre, questo uso di XML ha dimostrato un fondamentale malinteso su cosa significasse XML.

XML è un linguaggio di markup. Questo non è un formato dati. La maggior parte degli schemi XML hanno esplicitamente trascurato questa distinzione, confondendo XML con un formato dati, il che alla fine si traduce in un errore nella scelta di XML perché è il formato dati effettivamente necessario.

Senza entrare troppo nei dettagli, XML è più adatto per annotare blocchi di testo con struttura e metadati. Se il tuo obiettivo principale non è lavorare con un blocco di testo, è improbabile che la scelta di XML sia giustificata.

Da questo punto di vista esiste un modo semplice per verificare la qualità della realizzazione dello schema XML. Prendiamo come esempio un documento nello schema previsto e rimuoviamo da esso tutti i tag e gli attributi. Se ciò che rimane non ha senso (o se è rimasta una riga vuota), allora il tuo schema non è stato creato correttamente o semplicemente non avresti dovuto utilizzare XML.

Di seguito fornirò alcuni degli esempi più comuni di circuiti costruiti in modo errato.

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

Qui vediamo un esempio di un tentativo infondato e strano (anche se molto comune) di esprimere un semplice dizionario di valori-chiave in XML. Se rimuovi tutti i tag e gli attributi, rimarrai con una riga vuota. In sostanza, questo documento, per quanto assurdo possa sembrare, è un'annotazione semantica di una riga vuota.

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

A peggiorare le cose, qui non abbiamo solo un'annotazione semantica di una stringa vuota come un modo stravagante di esprimere un dizionario: questa volta il "dizionario" è codificato direttamente come attributi dell'elemento radice. Ciò rende il dato insieme di nomi di attributi su un elemento indefinito e dinamico. Inoltre, mostra che tutto ciò che l'autore voleva veramente esprimere era una semplice sintassi di valori-chiave, ma invece ha preso la decisione assolutamente bizzarra di applicare XML, forzando l'uso di un singolo elemento vuoto semplicemente come prefisso per utilizzare la sintassi degli attributi. E mi imbatto in tali schemi molto spesso.

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

Questo è qualcosa di meglio, ma ora per qualche motivo le chiavi sono metadati e i valori no. Uno sguardo molto strano ai dizionari. Se rimuovi tutti i tag e gli attributi, metà delle informazioni andranno perse.

Un'espressione corretta del dizionario in XML sarebbe simile a questa:

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

Ma se le persone hanno preso la strana decisione di utilizzare XML come formato dati e poi di usarlo per organizzare un vocabolario, allora dovrebbero capire che ciò che stanno facendo è inappropriato e non conveniente. È anche comune che i progettisti scelgano erroneamente XML per creare le proprie applicazioni. Ma ancora più spesso peggiorano le cose utilizzando XML senza senso in una delle forme sopra descritte, ignorando il fatto che XML semplicemente non è adatto a questo.

Il peggiore schema XML? A proposito, il premio per il peggior schema XML che abbia mai visto, Ottiene il formato del file di configurazione del provisioning automatico per i telefoni di telefonia IP Polycom. Tali file richiedono il download di file di richiesta XML tramite TFTP, che... In generale, ecco un estratto da uno di questi 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="..." />

Questo non è il brutto scherzo di qualcuno. E questa non è una mia invenzione:

• gli elementi vengono semplicemente utilizzati come prefisso per associare attributi, che a loro volta hanno nomi gerarchici.
• Se desideri assegnare valori a più istanze di un particolare tipo di record, devi utilizzare i nomi degli attributi per farlo. che hanno indici.
• Inoltre, gli attributi che iniziano con softkey., deve essere posizionato sugli elementi <softkey/>, attributi che iniziano con feature., deve essere posizionato sugli elementi <feature/> ecc., nonostante sembri del tutto inutile e a prima vista privo di significato.
• E infine, se speri che il primo componente del nome di un attributo sia sempre lo stesso del nome dell'elemento, niente del genere! Ad esempio, gli attributi up. deve essere allegato a <userpreferences/>. L'ordine di attribuire i nomi degli attributi agli elementi è arbitrario, quasi completamente.

Documenti o dati. Di tanto in tanto, qualcuno fa qualcosa di completamente strano cercando di confrontare XML e JSON, dimostrando così di non capire nessuno dei due. XML è un linguaggio di markup dei documenti. JSON è un formato di dati strutturati, quindi confrontarli tra loro è come provare a confrontare il caldo con il morbido.

Il concetto di differenza tra documenti e dati. Come analogo di XML, possiamo prendere condizionatamente un documento leggibile dalla macchina. Sebbene sia concepito per essere leggibile dalla macchina, si riferisce metaforicamente ai documenti e da questo punto di vista è in realtà paragonabile ai documenti PDF, che molto spesso non sono leggibili dalla macchina.

Ad esempio, in XML l'ordine degli elementi è importante. Ma in JSON, l'ordine delle coppie chiave-valore all'interno degli oggetti è privo di significato e indefinito. Se desideri ottenere un dizionario non ordinato di coppie chiave-valore, l'ordine effettivo in cui appaiono gli elementi in quel file non ha importanza. Ma puoi formare molti tipi diversi di dati da questi dati. documentazione, perché c'è un certo ordine nel documento. Metaforicamente è analogo a un documento su carta, sebbene non abbia dimensioni fisiche, a differenza di una stampa o di un file PDF.

Il mio esempio di rappresentazione corretta di un dizionario XML mostra l'ordine degli elementi nel dizionario, al contrario della rappresentazione JSON. Non posso ignorare questo ordine: questa linearità è inerente al modello del documento e al formato XML. Alcuni potrebbero scegliere di ignorare l'ordine quando interpretano questo documento XML, ma non ha senso discuterne poiché il problema va oltre lo scopo di una discussione sul formato stesso. Inoltre, se rendi il documento visualizzabile nel browser allegandogli un foglio di stile a cascata, vedrai che gli elementi del dizionario appaiono in un certo ordine e in nessun altro.

In altre parole, è possibile convertire in un dizionario (un pezzo di dati strutturati). n vari possibili documenti (in XML, PDF, cartacei, ecc.), dove n - il numero di possibili combinazioni di elementi nel dizionario, e non abbiamo ancora preso in considerazione altre possibili variabili.

Tuttavia, ne consegue anche che se si desidera trasferire solo dati, l'utilizzo di un documento leggibile dalla macchina non sarà efficace. Utilizza un modello, che in questo caso è superfluo: sarà solo d'intralcio. Inoltre, per estrarre i dati di origine, dovrai scrivere un programma. Non ha quasi senso usare XML per qualcosa che non verrà formattato come documento prima o poi (ad esempio, usando CSS o XSLT, o entrambi), poiché questo è il motivo principale (se non l'unico) per farlo. al modello del documento.

Inoltre, poiché XML non prevede il concetto di numeri (o espressioni booleane o altri tipi di dati), tutti i numeri rappresentati in questo formato sono considerati solo testo aggiuntivo. Per estrarre i dati, è necessario conoscere lo schema e la sua relazione con i dati corrispondenti espressi. Devi anche sapere quando, in base al contesto, un particolare elemento di testo rappresenta un numero e deve essere convertito in un numero, ecc.

Pertanto, il processo di estrazione dei dati dai documenti XML non è molto diverso dal processo di riconoscimento dei documenti scansionati contenenti, ad esempio, tabelle che formano molte pagine di dati numerici. Sì, in linea di principio è possibile farlo, ma questo non è il modo ottimale, tranne come ultima risorsa, quando non ci sono assolutamente altre opzioni. Una soluzione ragionevole è semplicemente trovare una copia digitale dei dati originali che non sia incorporata in un modello di documento che combini i dati con la loro specifica rappresentazione testuale.

Detto questo, non mi sorprende affatto che XML sia popolare nel mondo degli affari. La ragione di ciò è proprio che il formato del documento (su carta) è comprensibile e familiare per le aziende, che vogliono continuare a utilizzare un modello familiare e comprensibile. Per lo stesso motivo, le aziende troppo spesso utilizzano documenti PDF invece di formati più leggibili dalle macchine, perché sono ancora legate al concetto di pagina stampata con una dimensione fisica specifica. Ciò vale anche per i documenti che difficilmente verranno mai stampati (ad esempio, un PDF di 8000 pagine di documentazione del registro). Da questo punto di vista, l'uso di XML nel mondo degli affari è essenzialmente una manifestazione di scheumorfismo. Le persone comprendono l'idea metaforica di una pagina stampata di dimensioni limitate e capiscono come creare processi aziendali basati su documenti stampati. Se questa è la tua guida, i documenti senza limiti di dimensione fisica leggibili dalle macchine (documenti XML) rappresentano l'innovazione pur essendo una controparte familiare e comoda. Ciò non impedisce loro di rimanere un modo errato ed eccessivamente scheumorfico di presentare i dati.

Ad oggi, gli unici schemi XML che conosco e che posso veramente definire un uso valido del formato sono XHTML e DocBook.

Fonte: habr.com