XML è praticamente sempre utilizzato in modo non corretto

Il linguaggio XML è stato inventato nel 1996. Non appena è apparso, le sue possibilità di applicazione sono state già fraintese e per gli scopi ai quali veniva adattato, non era la migliore scelta.

Non sarebbe esagerato dire che la stragrande maggioranza degli schemi XML che ho visto rappresentavano un uso inappropriato o errato di XML. Inoltre, tale applicazione di XML testimoniava una comprensione fondamentale di cosa sia, prima di tutto, l'XML.

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.

Se non si entra 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, scegliere XML difficilmente sarà giustificato.

Da questo punto di vista, esiste un modo semplice per verificare quanto sia ben fatta una scheda XML. Prendiamo ad esempio un documento nella scheda prevista e rimuoviamo tutti i tag e gli attributi. Se ciò che rimane non ha senso (o se rimane una riga vuota), allora o il tuo schema è costruito in modo errato, o non avresti dovuto utilizzare XML.

Di seguito fornirò alcuni dei casi più comuni 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 si rimuovono tutti i tag e gli attributi, rimane una riga vuota. In sostanza, questo documento rappresenta, per quanto possa sembrare assurdo, un'annotazione semantica di una riga vuota.

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

Ciò che è peggio, non abbiamo qui solo una nota semantica di una stringa vuota come un modo stravagante per esprimere un dizionario: questa volta il «dizionario» è direttamente codificato come attributi dell'elemento radice. Di conseguenza, il set di nomi degli attributi sull'elemento diventa indefinito e dinamico. Inoltre, qui si vede che tutto ciò che l'autore voleva esprimere era una semplice sintassi «chiave-valore», ma invece ha preso una decisione completamente strana di applicare XML, imponendo l'uso di un singolo elemento vuoto come prefisso per utilizzare la sintassi degli attributi. E schemi del genere mi capitano molto spesso.

John
  London

È già un po' meglio, ma ora le chiavi sono per qualche motivo metadati, mentre i valori no. Una visione piuttosto strana 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 circa così:

Nome
    John
  
  
    Città
    Londra

Ma se le persone hanno preso la strana decisione di utilizzare l'XML come formato di dati e poi di ordinare un dizionario in base a esso, devono capire che quello che stanno facendo è inappropriato e scomodo. Ancora più spesso, i progettisti scelgono erroneamente l'XML per creare le loro applicazioni. Ma ancora più frequentemente peggiorano la situazione con un uso insensato dell'XML in una delle forme descritte sopra, ignorando il fatto che l'XML non è adatto a questo scopo.

Qual è il schema XML peggiore? A proposito, il premio per il schema XML peggiore che abbia mai visto, va al formato del file di configurazione per l'allocazione automatica delle risorse per i telefoni VoIP Polycom. Questi file richiedono il caricamento di file XML tramite TFTP, che... In breve, 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="..." />

Questa non è una brutta barzelletta. E non è una mia invenzione:

• gli elementi sono semplicemente utilizzati come prefissi per l'allegazione di attributi, che hanno nomi gerarchici.
• Se è necessario associare valori a più istanze di un record di uno specifico tipo, si devono utilizzare nomi di attributi, che contengono indici.
• Inoltre, gli attributi che iniziano con softkey.devono essere collocati sugli elementi <softkey/>gli attributi che iniziano con feature.devono essere collocati sugli elementi <feature/> ecc., anche se questo sembra del tutto superfluo e a prima vista senza senso.
• E infine, se speravate che il primo componente del nome dell'attributo coincidesse sempre con il nome dell'elemento — nulla di tutto ciò! Ad esempio, gli attributi up. devono essere allegati a <userpreferences/>. L'assegnazione dei nomi degli attributi agli elementi è arbitraria e praticamente completamente libera.

Documenti o dati. Di tanto in tanto, qualcuno compie atti assolutamente strani, 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, invece, rappresenta un formato di dati strutturati, quindi confrontarli è come cercare di confrontare qualcosa di caldo con qualcosa di morbido.

Capire questo aiuta a chiarire la differenza tra documenti e dati. Come analogia, si può considerare XML come un documento leggibile dalla macchina. Sebbene sia destinato a essere letto da una macchina, metaforicamente si riferisce a documenti, e da questo punto di vista è sostanzialmente paragonabile ai documenti in formato PDF, che spesso non sono leggibili dalla macchina.

Ad esempio, in XML l'ordine degli elementi è importante. In JSON, invece, l'ordine delle coppie «chiave-valore» all'interno degli oggetti non ha significato ed è indeterminato. Se desideri ottenere un dizionario non ordinato di coppie «chiave-valore», l'ordine effettivo in cui gli elementi appaiono in questo file non conta. Tuttavia, puoi estrarre da questi dati molti documenti diversi, documenti, poiché nel documento c'è un ordine definito. Metaforicamente, è l'equivalente di un documento cartaceo, anche se non ha dimensioni fisiche come una stampa o un file PDF.

Nel mio esempio di corretta rappresentazione di un dizionario in XML è mostrato l'ordine degli elementi nel dizionario, a differenza della rappresentazione in JSON. Non posso ignorare questo ordine: tale linearità è intrinsecamente propria del modello di documenti e del formato XML. Qualcuno, nell'interpretare questo documento XML, potrebbe decidere di ignorare l'ordine, ma discutere su questo è inutile, poiché la questione esula dalla discussione del formato stesso. Inoltre, se il documento viene reso visibile in un browser, allegando un foglio di stile, si potrà vedere che gli elementi del dizionario seguono un ordine specifico e nulla di diverso.

In altre parole, un dizionario (un frammento di dati strutturati) può essere trasformato in n diversi possibili documenti (in formato XML, PDF, su carta, ecc.), dove n – il numero delle possibili combinazioni di elementi nel dizionario, e questo non tiene ancora conto di altre possibili variabili.

Tuttavia, ciò implica anche che se desideri trasmettere solo dati, utilizzare un documento leggibile dalla macchina non sarà efficace. In questo caso viene utilizzato un modello che si rivela superfluo e potrebbe solo ostacolare. Inoltre, per estrarre i dati originali sarà necessario scrivere un programma. Non ha molto senso utilizzare XML per qualcosa che in una fase successiva non sarà formattato come un documento (ad esempio, tramite CSS o XSLT, oppure entrambi), poiché questa è la principale (se non l'unica) ragione per aderire al modello di documento.

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

Pertanto, il processo di estrazione dei dati da documenti XML non è molto diverso dal processo di riconoscimento di documenti scansionati, che contengono, ad esempio, tabelle con numerosi dati numerici. Sì, è teoricamente possibile farlo, ma non è la strada più ottimale, a meno che non si tratti di un caso estremo, in cui non ci sono altre opzioni. Una soluzione ragionevole sarebbe semplicemente trovare una copia digitale dei dati originali, non integrati nel modello del documento, in cui i dati sono combinati con la loro rappresentazione testuale specifica.

Non mi sorprende affatto che l'XML sia popolare nel business. Questo è dovuto al fatto che il formato dei documenti (su carta) è comprensibile e familiare per le aziende, che desiderano continuare a utilizzare un modello riconoscibile e chiaro. Per la stessa ragione, nel business si ricorre troppo spesso ai documenti in PDF anziché a formati più adatti per l'elaborazione automatica, poiché sono ancora vincolati all'idea di una pagina stampata con dimensioni fisiche specifiche. Questo vale anche per quei documenti che difficilmente verranno mai stampati (ad esempio, un file PDF di documentazione del registro di 8000 pagine). Da questo punto di vista, l'uso dell'XML nel business è essenzialmente un'espressione di skeuomorfismo. L'idea metaforica della pagina stampata di dimensioni limitate è chiara per le persone, che comprendono come creare processi aziendali basati su documenti cartacei. Se questo è il vostro riferimento, i documenti senza una dimensione fisica limitata, che sono leggibili dalle macchine—i documenti XML—rappresentano un'innovazione, essendo al contempo un'alternativa familiare e confortevole al documento. Tuttavia, ciò non impedisce che siano un modo errato e eccessivamente skeuomorfico di rappresentare i dati.

Oggi, le uniche schemi XML che posso realmente considerare un corretto utilizzo di questo formato sono XHTML e DocBook.

Fonte: habr.com