Convertitore da XML a YAML

YAML 1.2 è stato progettato come soprainsieme di JSON, quindi qui non c’è un albero separato. L’XML viene convertito nella stessa struttura che produce la pagina da XML a JSON e un serializzatore diverso la scrive. Ogni decisione di mappatura di quella pagina vale immutata: gli attributi diventano chiavi con prefisso, il testo che condivide un elemento con attributi o figli finisce sotto una chiave di testo, un elemento che compare due volte diventa una sequenza, e i commenti vengono persi.

Una cosa peggiora. In JSON chi consuma vede almeno delle parentesi quadre; in YAML la differenza fra un elemento e due è uno scalare indentato contro un elenco di trattini, e nessuno la nota in un diff. Usa il campo «sempre un array» per tutto ciò che concettualmente è un elenco, così un documento con un elemento e uno con cinquanta producono la stessa forma.

<order id="00042">
  <total currency="GBP">19.90</total>
  <line sku="0071">Widget</line>
  <line sku="0072">Gasket</line>
  <country>NO</country>
</order>

order:
  attr_id: '00042'
  total:
    attr_currency: GBP
    text: '19.90'
  line:
    - attr_sku: '0071'
      text: Widget
    - attr_sku: '0072'
      text: Gasket
  country: 'NO'

YAML 1.1 definisce il proprio tipo booleano per enumerazione, e l’enumerazione è più ampia di quanto chiunque si aspetti. La pagina dei tipi pubblicata elenca, alla lettera: y, Y, yes, Yes, YES, n, N, no, No, NO, true, True, TRUE, false, False, FALSE, on, On, ON, off, Off, OFF. Ognuno di questi, senza apici, si carica come booleano.

La conseguenza ha un nome. Un insieme di codici paese ISO riceve NO per la Norvegia e il parser consegna all’applicazione false. Lo stesso elenco inghiotte una colonna Sì/No esportata da un foglio di calcolo e qualunque interruttore scritto on od off che doveva essere testo. YAML 1.2 ha ristretto lo schema centrale ai soli true e false, ma PyYAML, il Psych di Ruby, Ansible e buona parte degli strumenti Kubernetes risolvono ancora l’insieme 1.1, quindi dài per scontato che sia tutto vivo.

L’emettitore mette fra apici singoli ogni scalare che corrisponda esattamente a quell’elenco, comprese le forme di una sola lettera, più null, Null, NULL e la tilde. Nota la sensibilità alle maiuscole: yES e nO non stanno nell’elenco 1.1 e non vengono quotati, perché nemmeno un parser conforme li legge come booleani.

L’insieme booleano è il caso famoso, non quello comune. Quasi tutti i valori che si rompono sono numeri che numeri non sono mai stati, perché YAML deduce un tipo dalla grafia di uno scalare semplice esattamente come JSON non fa. Uno scalare viene messo fra apici singoli quando corrisponde all’insieme booleano o nullo, quando corrisponde a una grammatica di numero JSON (coprendo 42, 19.90 e 1.10), quando ha uno zero iniziale seguito da altre cifre, quando è vuoto, quando inizia con un carattere indicatore di YAML come un trattino o un cancelletto, o quando ha spazi a una delle due estremità.

Il testo su più righe non viene quotato. Diventa uno scalare a blocco letterale introdotto da una barra verticale con indicatore di taglio. Il letterale è scelto al posto del ripiegato di proposito: un blocco ripiegato riversa le singole interruzioni di riga in spazi, distruggendo codice e indirizzi incorporati. L’indicatore di taglio rimuove l’interruzione di riga finale che un blocco aggiungerebbe altrimenti.

Alcuni valori lasciano comunque l’emettitore senza apici e possono cambiare tipo a valle. Vengono elencati anziché sorvolati, perché nessun emettitore che usi scalari semplici ha risolto l’inferenza di tipo di YAML:

• I numeri sessagesimali. YAML 1.1 legge 22:22 come un intero in base 60, quindi una durata diventa 1342 in PyYAML. Un parser 1.2 come js-yaml restituisce la stringa, quindi dipende da quale lato legge il file.
• Le grafie esadecimali. 0x1F si carica come 31 sia in YAML 1.1 sia nello schema centrale 1.2, quindi un codice colore esadecimale ha bisogno degli apici.
• Le date. 2024-01-05 corrisponde al tipo timestamp di YAML, quindi js-yaml e PyYAML ti consegnano entrambi un oggetto data anziché una stringa.
• Gli scalari a blocco la cui prima riga è indentata più delle righe successive, cosa che capita quando una sezione CDATA conserva gli spazi iniziali. La soluzione di YAML è un indicatore di indentazione esplicito dopo la barra verticale, che questo emettitore non scrive.

È l’unica preparazione che vale la pena fare. I valori predefiniti sono stati scelti per JSON, dove sono sicuri, e YAML ha per le chiavi una grammatica più severa che per i valori.

Il prefisso degli attributi predefinito è @_ e la chiave di testo predefinita è #text. In YAML, @ è un indicatore riservato con cui uno scalare semplice non può iniziare, quindi una chiave @_id rende il documento non analizzabile: js-yaml segnala «bad indentation of a mapping entry» e PyYAML segnala un carattere che non può iniziare alcun token. Un # iniziale è peggio, perché non fallisce. Una riga che dice #text: 19.90 è un commento, quindi il file si carica e il valore semplicemente non c’è.

Entrambi i campi stanno nella riga di controlli sopra l’editor. Metti il prefisso su qualcosa di semplice come attr_ e la chiave di testo su text, e ogni chiave nell’output è un normale nome YAML. Le chiavi che richiedono apici per altri motivi, come soap:Body, vengono quotate automaticamente, perché i due punti non sono leciti in una chiave nuda.

Due passi: analizzare l’XML in sicurezza, poi serializzare con un dumper a cui hai detto di quotare come si deve. La metà XML ha bisogno dei soliti flag sulle entità, perché le impostazioni predefinite in Java e in .NET risolvono un DOCTYPE. La metà YAML richiede attenzione perché i dumper differiscono su quanto aggressivamente quotano.