Perché convalidare XML?

Per assicurarti che funzioni. Certo, se scrivi solo alcuni dati per la tua applicazione per leggerlo, potrebbe essere sufficiente se funziona. Se si invia un file a qualcun altro, le cose potrebbero essere diverse. Ma anche all'interno dell'applicazione puoi scegliere in seguito di cambiare la libreria di analisi e la nuova potrebbe lamentarsi di errori accettati e ignorati come se non fossero in grado di fuggire correttamente da alcuni caratteri.

Oppure, a seconda del tipo di dati che si memorizzano, possono apparire alcuni nuovi caratteri (forse un utente con un nome straniero) e da quel momento le definizioni di set di caratteri appropriati potrebbero essere importanti. Lo stesso se si invia un file XML da Windows a un sistema Linux. Più ci si avvicina alle definizioni e alle convalide, meno è probabile che si verifichino problemi imprevisti quando le cose cambiano.

Dipende da come stai usando l'XML.

Ad esempio, se vuoi estrarre uno o due pezzi di dati dall'XML, allora vai avanti, allora sarebbe meglio solo estrarli e andare avanti.

Tuttavia, se hai bisogno dell'intero documento XML, ad esempio, per esempio, desideri trasformarlo in un altro formato XML che richiede tutti i campi, allora dovrei ottenere uno schema coinvolto.

Dipende anche dalla relazione che hai con la persona che ti ha mandato l'XML: se stai ricevendo XML da una parte con cui devi essere formale (ad es. un'altra azienda) allora avere schemi XML ti permette di stabilire un contratto su cosa accetterete come input e come output.

D'altra parte, se hai una relazione informale, puoi essere generoso con ciò che accetti / respingi.

È un po 'come chiedere, perché testiamo i nostri programmi. Lo facciamo nel caso in cui abbiano torto.

Naturalmente ci sono degli scenari in cui sai che i dati non sono sbagliati, perché il programma che lo genera è ben testato e affidabile. In tal caso non è necessario convalidare i dati. Non è obbligatorio.

Bene, non è necessario. La convalida dell'XML su uno schema (DTD è obsoleto obsoleto) equivale all'utilizzo di un linguaggio tipizzato staticamente. Garantisce un più alto livello di correttezza a scapito di più lavoro in anticipo. Generalmente trovo che validare XML sia molto utile quando si ha a che fare con servizi remoti. È auto-documentante. Se stai trasferendo i dati da un client a un server in cui controlli entrambi i lati, allora è meno utile.

Parlare in termini di utilizzo di XML per i servizi Web: uno schema ben formato consente al consumatore del servizio Web di sapere che cosa si aspetta il server e quindi cosa il server restituirà. veramente aiuta a sapere quali sono gli input e gli output per il servizio web.

Poi ci sono i servizi web mal formati: ti dicono cosa si aspettano da te, ma poi restituiscono alcune assurdità. Attualmente mi occupo di un servizio del genere: ti dicono come formattare l'input, ma poi restituiscono la risposta come una stringa. Una stringa che contiene XML complesso. Detto XML complesso non ha schemi contro cui convalidare, quindi non ho idea di cosa sia garantito per tornare dal server, cosa è facoltativo, o quali tipi sono eventualmente restituiti. È effettivamente inutile, in quanto non mi dice nulla di utile.

Perché? perché non vuoi scrivere validatori tu stesso, e se lo fai, è molto probabile che tu non abbia esperienza nel farlo, e quando hai bisogno di cambiarlo per soddisfare i nuovi requisiti, avrai un tempo terribile.

Nonostante la credenza comune, XML non è rigido; Finché il tuo XML è sintatticamente corretto, è un XML valido, nonostante le persone ignoranti ti dicano il contrario.

VUOI convalidare il tuo XML se le tue applicazioni (sia esso web o altro) si basano su modelli (non necessariamente XML, perché qualsiasi modello può essere trasformato in XML scrivendo un semplice programma tree walking) per comportarsi correttamente.

Ad esempio, potresti avere un modello JSON per i colori

[
    {"name": "red", "cssxrgb": "#ff0000"},
    {"name": "blue", "cssxrgb": "#00ff00"},
    {"name": "green", "cssxrgb": "#0000ff"}
]

La maggior parte dei programmatori, se viene richiesto di scrivere un programma per assicurarsi che tutte le voci in questo array siano valide e dire cosa non è valido quando non lo è, scriverà qualcosa di questo odore:

var jsonString = '
[
    {"name": "red", "cssxrgb": "#ff0000"},
    {"name": "blue", "cssxrgb": "#00ff00"},
    {},
    {"name": "green", "cssxrgb": "#0000ff"}
]
';
var data = JSON.parse(jsonString);

for (var i = 0; i < data.length; ++i) {
    var row = data[i];

    if (!row.hasOwnProperty('name')) {
        throw new TypeError('row #' + i + " is missing required property name");
    }
    if (!row.hasOwnProperty('cssxrgb')) {
        throw new TypeError('row #' + i + " is missing required property cssxrgb");
    }
}

Può essere difficile da mantenere, richiede una codifica molto attenta ed è molto fragile per errori di battitura, cambi di campo, ecc.

Un semplice programma può essere scritto per trasformare il precedente in XML, e molti modelli hanno già molti trasformatori online da loro in XML. Non deve nemmeno essere un buon trasformatore, è più semplice cambiare il metodo di trasformazione dei dati in xml che modificare i validatori personalizzati. Ecco un esempio per la trasformazione di cui sopra in

<colors><color name="red" cssxrgb="#ff0000" /><color name="blue" cssxrgb="#00ff00" /><color name="green" cssxrgb="#0000ff" /></colors>

codice di trasformazione:

var jsonString = '
[
    {"name": "red", "cssxrgb": "#ff0000"},
    {"name": "blue", "cssxrgb": "#00ff00"},
    {"name": "green", "cssxrgb": "#0000ff"}
]
';

var data = JSON.parse(jsonString);
var xmlString = '<colors>';

for (var i = 0; i < data.length; ++i) {
    var row = data[i];
    var name = row.name;
    var cssxrgb = row.cssxrgb;
    var keys = Object.keys(row);
    xmlString += '<color ';    
    var tmp = [];
    for (var j = 0; j < keys.length; ++j) {      
        var key = keys[j];
        var value = row[key];
        tmp.push('${key}="${value}"');
    }    
    xmlString += tmp.join(', ') + ' />';    
}
xmlString += '</colors>';
console.log(xmlString);

Ora per convalidare, tutto ciò che devi fare è eseguirlo sul doctype come

<!ELEMENT colors (color*)>
<!ELEMENT color EMPTY>
<!ATTLIST color name CDATA #REQUIRED>
<!ATTLIST color cssxrgb CDATA #REQUIRED>

Puoi verificarlo con i validatori online come tali

<!DOCTYPE colors [
    <!ELEMENT colors (color*)>
    <!ELEMENT color EMPTY>
    <!ATTLIST color name CDATA #REQUIRED>
    <!ATTLIST color cssxrgb CDATA #REQUIRED>
]>
<colors><color name="red" cssxrgb="#ff0000" /><color name="blue" cssxrgb="#00ff00" /><color name="green" cssxrgb="#0000ff" /></colors>

I rigidi validatori rifiuteranno il modello se contiene attributi / elementi non dichiarati nella DTD, il che è utile quando i programmi sono fragili in chiave, coppie di valori che non si aspettano. Il problema è se un validatore smette di convalidare dopo il primo errore o se ci sono troppi falsi positivi come i tag non dichiarati rispetto alle violazioni delle cose che il tuo doctype in realtà chiede di verificare.

Se sai come scrivere i tuoi validatori, puoi spesso scrivere quelli migliori più velocemente della scrittura dei tuoi trasformatori model-to-xml e del tuo doctype, ma anche in questo caso, è più facile cambiare un DTD esistente o model to xml transformer che dover modificare il proprio validatore personalizzato.

Come per HTML / SVG / altri formati comuni; Di solito sono XML non validi, ma se si sceglie di renderli XML validi, si ha la possibilità di aggiungere i propri tag che vengono ignorati dal documento se li si disegna in display: none , ma si ha ancora un feedback quando si esegue accidentalmente un errore di battitura nel proprio modello. Questo è utile per cose come i modelli angolari, i metadati personalizzati che vengono gestiti da JavaScript quando determinati eventi si innescano.

Nel peggiore dei casi, ti consente di stabilire quali parti del DOM sono "standard" e quali sono i metadati (es. author tag in head) / custom (ad es. gallery tag che angularjs trasforma in seguito) / dati spazzatura (errori di battitura, metadati non più necessari, così via), in entrambi i casi questi tag personalizzati introducono complessità nel modello e la convalida di xml può aiutarti a capire quali parti del DOM potrebbero essere le cause più guai.

Per riassumere qui ci sono i vantaggi della convalida

1. è validabile - anche se non usa la validazione, puoi almeno sapere che è possibile validarlo perché ha una struttura XML sintatticamente corretta, che ti permette di convalidarlo quando vuoi o quando è necessario.

2. Aiuta a trovare parti di DOM che un programma a seconda del modello potrebbe non aspettarsi.

3. È più semplice scrivere e gestire un semplice validatore trasformando in XML e scrivendo un DOCTYPE e scegliendo quale DOCTYPE utilizzare su una specifica esecuzione di validazione rispetto alla scrittura del proprio validatore. È anche più semplice correggere i casi limite nel tuo trasformatore personalizzato, doctype che all'interno di un validatore personalizzato.

4. Può sfruttare le tecnologie XML: se è un XML valido, può utilizzare facilmente molte delle tecnologie XML come XSL. Queste tecnologie di solito aggiungono molta complessità rispetto al fare le cose in modo convenzionale, ma consentono di controllare il tuo documento in modo piuttosto efficace una volta che ti senti a tuo agio con qualsiasi di esse.