XML viene praticamente sempre utilizzato in modo errato

Il linguaggio XML è stato inventato nel 1996. Appena è apparso, le possibilità di utilizzo sono state fraintese, e per gli scopi a cui è stato cercato di adattarlo, non è stata la scelta migliore.

Non sarà esagerato dire che la stragrande maggioranza degli schemi XML che ho visto rappresentava un uso inadeguato o errato di XML. Inoltre, tale utilizzo di XML testimoniava una fondamentale incomprensione di ciò che XML è prima di tutto.

XML è un linguaggio di markup. Non è un formato di dati. Nella maggior parte degli schemi XML questa distinzione non è stata esplicitamente considerata, confondendo XML con un formato di dati, il che ha portato a un errore nella scelta di XML, poiché in realtà era necessario un formato di dati.

Senza entrare 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, la scelta di XML difficilmente sarà giustificata.

Da questo punto di vista, esiste un modo semplice per verificare quanto sia ben fatto uno schema XML. Prendiamo ad esempio un documento nello schema previsto e rimuoviamo tutti i tag e gli attributi. Se nel resto non ha senso (o se rimane una stringa vuota), allora o il tuo schema è costruito in modo errato, o semplicemente non avresti dovuto utilizzare XML.

Di seguito fornirò alcuni dei più comuni esempi di schemi costruiti in modo errato.

Qui vediamo un esempio di un tentativo ingiustificato e strano (sebbene piuttosto comune) di esprimere in XML un semplice dizionario "chiave-valore". Se rimuoviamo tutti i tag e gli attributi, rimarrà una stringa vuota. In sostanza, questo documento rappresenta, per quanto possa sembrare assurdo, un'annotazione semantica di una stringa vuota.

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

Cosa ancor peggiore, qui non abbiamo solo un'annotazione semantica di una riga vuota come un modo stravagante di esprimere un dizionario — stavolta il «dizionario» è codificato direttamente come attributi dell'elemento radice. Di conseguenza, il set di nomi degli attributi sull'elemento diventa indeterminato e dinamico. Inoltre, è chiaro che tutto ciò che l'autore voleva esprimere era una semplice sintassi «chiave-valore», ma invece ha preso una decisione assolutamente strana di applicare XML, costringendo l'uso di un singolo elemento vuoto semplicemente come prefisso per utilizzare la sintassi degli attributi. E schemi come questo mi capitano molto spesso.

John
  Londra

Questo è già un po' meglio, ma ora le chiavi sono per qualche ragione meta dati, mentre i valori non lo sono. Un punto di vista piuttosto strano sui dizionari. Se si rimuovono tutti i tag e gli attributi, si perde metà delle informazioni.

Un'espressione corretta di un dizionario in XML apparirebbe approssimativamente così:

Nome
    John
  
  
    Città
    Londra

Ma se le persone hanno preso la strana decisione di applicare XML come formato dati e poi di utilizzarlo per ordinare un dizionario, devono capire che quello che fanno non è appropriato e non è comodo. Inoltre, spesso i progettisti scelgono erroneamente XML per creare le loro applicazioni. Ma ancora più spesso, aggravano la situazione con l'uso insensato di XML in una delle forme sopra descritte, ignorando il fatto che XML non è adatto a questo.

Qual è il schema XML peggiore? A proposito, il premio per il schema XML peggiore che abbia mai visto, va al formato di file di configurazione per la gestione delle risorse automatiche per i telefoni VoIP Polycom. Questi file richiedono il caricamento di file XML tramite richiesta TFTP, che… In sostanza, ecco un estratto di 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="..." />

Non è uno scherzo di cattivo gusto. E non è una mia invenzione:

• gli elementi sono semplicemente utilizzati come prefisso per allegare attributi che di per sé hanno nomi gerarchici.
• Se è necessario attribuire valori a più istanze di un determinato tipo di registrazione, è necessario utilizzare nomi di attributi, che contengono indici.
• Oltre a ciò, gli attributi che iniziano con softkey., devono essere collocati sugli elementi <softkey/>, gli attributi che iniziano con feature., devono essere collocati sugli elementi <feature/> e così via, nonostante questo possa sembrare completamente superfluo e, a prima vista, privo di senso.
• E, infine, se speravi che il primo componente del nome dell'attributo corrispondesse sempre al nome dell'elemento, non è affatto così! Ad esempio, gli attributi up. devono essere associati a <userpreferences/>. L'ordine con cui gli attributi sono associati agli elementi è arbitrario, quasi del tutto.

Documenti o dati. Di tanto in tanto qualcuno fa cose assolutamente strane, cercando di confrontare XML e JSON, dimostrando così di non comprendere né l'uno né l'altro. XML è un linguaggio di markup per documenti. JSON è un formato di dati strutturati, quindi confrontarli tra loro è come cercare di confrontare il caldo con il morbido.

Comprendere questo aiuterà il concetto di differenza tra documenti e dati.Come analogia, XML può essere considerato un documento leggibile dalla macchina. Anche se è progettato per essere letto da una macchina, metaforicamente si riferisce ai documenti e da questo punto di vista è effettivamente comparabile ai documenti in formato PDF, che spesso non sono leggibili dalla macchina.

Ad esempio, in XML l'ordine degli elementi è rilevante. In JSON, l'ordine delle coppie "chiave-valore" all'interno degli oggetti non ha significato e non è definito. Se desideri ottenere un dizionario non ordinato di coppie "chiave-valore", l'ordine effettivo in cui gli elementi seguono in questo file non ha importanza. Ma puoi formare da questi dati molti diversi documenti,poiché in un documento c'è un ordine definito. Metaforicamente, questo è analogo a un documento cartaceo, anche se non ha dimensioni fisiche a differenza di una stampa o di un file PDF.

Nel mio esempio di rappresentazione corretta di un dizionario in formato XML viene mostrato l'ordine degli elementi nel dizionario, diversamente dalla rappresentazione in formato JSON. Non posso ignorare questo ordine: tale linearità è intrinsecamente propria del modello di documenti e del formato XML. Qualcuno, interpretando questo documento XML, potrebbe decidere di ignorare l'ordine, ma discutere su questo punto è insignificante, poiché questa questione esula dalla discussione sul formato stesso. Inoltre, se si rende il documento visibile in un browser, allegando un foglio di stile, si può notare che gli elementi del dizionario seguono un certo ordine e in nessun altro.

In altre parole, un dizionario (frammento di dati strutturati) può essere trasformato in n vari documenti possibili (in formato XML, PDF, su carta, ecc.), dove n rappresenta il numero di possibili combinazioni di elementi nel dizionario, e questo senza considerare altre variabili possibili.

D'altra parte, ne deriva anche che se si desidera trasmettere solo dati, utilizzare un documento leggibile da macchina non sarà efficace. Utilizza un modello che in questo caso è superfluo, risulterà solo un ostacolo. Inoltre, per estrarre i dati originali, sarà necessario scrivere un programma. È difficile immaginare un motivo valido per usare XML per qualcosa che, a un certo punto, non verrà formattato come documento (ad esempio, tramite CSS o XSLT, o entrambi), poiché questa è la principale (se non l'unica) ragione per seguire il modello di documento.

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

In questo modo, il processo di estrazione dei dati dai documenti XML non è molto diverso dal processo di riconoscimento dei documenti scansionati, che contengono, ad esempio, tabelle che formano molte pagine di dati numerici. Sì, è sostanzialmente possibile farlo, ma non è il percorso più ottimale, a meno che non sia un caso estremo, quando non ci sono altre opzioni. Una soluzione sensata sarebbe semplicemente trovare una copia digitale dei dati originali, non inclusi nel modello del documento, in cui i dati sono uniti alla loro rappresentazione testuale specifica.

Non mi sorprende affatto che l'XML sia popolare nel mondo degli affari. La ragione è proprio che il formato dei documenti (su carta) è comprensibile e familiare per le aziende, e vogliono continuare a utilizzare un modello noto e comprensibile. Per lo stesso motivo, nel business si utilizzano troppo spesso documenti in PDF invece di formati più adatti all'elaborazione automatica — perché sono ancora legati al concetto di pagina stampata con una dimensione fisica definita. Questo vale anche per quei documenti che difficilmente saranno mai stampati (ad esempio, un file PDF della documentazione di un registro di 8000 pagine). Da questo punto di vista, l'uso dell'XML nel business è essenzialmente un'espressione di scemorfismo. Le persone comprendono l'idea metaforica di una pagina stampata di dimensioni limitate e sanno come creare processi aziendali basati su documenti stampati. Se questo è il vostro riferimento, i documenti senza dimensioni fisiche limitate, che sono leggibili dalla macchina — i documenti XML — rappresentano un'innovazione, fungendo al contempo da una controparte familiare e confortevole del documento. Ciò non toglie che rimangano un modo inaccurato e troppo scemorfico per rappresentare i dati.

Ad oggi, le uniche schede XML di cui posso effettivamente parlare come un uso corretto di questo formato sono XHTML e DocBook.

Fonte: habr.com