Italiano

Strumenti per sviluppatori · Convertitori di sintassi

Discendenza di XML da SGML: perché ha attributi, spazi dei nomi e DTD

· Sfondo

xml formati di dati sicurezza

Attributi XML, prefissi dello spazio dei nomi e testo misto accanto a un DOCTYPE rifiutato
Illustrazione vettoriale originale ToolAcre

Le stranezze di XML (attributi rispetto a elementi, spazi dei nomi, DTD, contenuti misti) hanno senso una volta che sai che è stato progettato come SGML semplificato per i documenti, non per i dati. Questo post traccia quel lignaggio e cosa significa quando converti XML in JSON.

Perché questo formato dati ha attributi? - uno sviluppatore che converte XML in JSON e soddisfa una distinzione che JSON non è mai stata necessaria

JSON ha un tipo di proprietà dell'oggetto; XML distingue attributi, elementi figlio e testo. ToolAcre mappa questa distinzione con gli attributi `@` e le normali chiavi figlio. La differenza è visibile quando un elemento ha sia `id="7"` che un figlio `<id>`: entrambi sopravvivono con proprietà separate.

Questa convenzione spiega la forma risultante senza affermare che gli attributi abbiano un ruolo semantico universale. Gli autori XML li scelgono secondo i propri schemi. Il convertitore conserva la categoria del nodo che può osservare, non il motivo aziendale per cui è stato scelto.

SGML e la tradizione dei documenti — ISO 8879, markup per la pubblicazione e l'idea di taggare il testo anziché codificare i record

Contenuti misti, elementi secondari ordinati, attributi, commenti e istruzioni di elaborazione sono funzionalità orientate ai documenti presenti nell'origine XML. L'implementazione ne dimostra la gestione ma non contiene prove della cronologia SGML, della cronologia delle pubblicazioni ISO o delle motivazioni del settore editoriale.

Un articolo legato al codice sorgente inizia quindi dal comportamento eseguibile. Il testo attorno agli elementi figlio è con perdita di dati; i commenti e le istruzioni di elaborazione vengono eliminati; CDATA rimane contrassegnato. Questi fatti spiegano perché un albero di documenti non si adatta perfettamente a un albero di valori JSON.

Funzionalità XML orientate ai documenti visibili nell'implementazione, senza una richiesta di cronologia SGML

Il parser convalida XML ben formato e riporta riga e colonna. Ignora la dichiarazione nel valore risultante e preserva le cinque entità integrate e i riferimenti ai caratteri numerici come testo decodificato. Non stabilisce obiettivi del gruppo di lavoro o un resoconto di progettazione in dieci principi.

Le affermazioni storiche necessitano di fonti editoriali esterne, che questo compito non aggiunge. Ometterli è più accurato che inventare la conformità o la provenienza da un nome di dipendenza.

Il parser gestisce la sintassi XML; le prove del repository non stabiliscono la cronologia della progettazione 1998

Gli attributi diventano chiavi con il prefisso `@`; gli elementi mantengono i loro nomi. Il testo all'interno di un elemento strutturato si sposta in `#text`, mentre un elemento di solo testo si comprime in una stringa. Ciò mantiene le categorie strutturali separate per quanto consentito da un modello a oggetti.

Scrivendo XML si inverte la convenzione: `@id` diventa un attributo. I nomi di attributi o elementi non validi vengono rifiutati anziché disinfettati. Questa decisione impedisce che una mappatura non corretta diventi plausibile XML con nomi alterati silenziosamente.

Gli attributi e gli elementi rimangono distinti secondo la convenzione @ di ToolAcre

I prefissi degli spazi dei nomi vengono mantenuti parola per parola nei nomi degli elementi e degli attributi, incluse le dichiarazioni degli spazi dei nomi. Non vengono risolti, rimossi o riscritti. Ciò preserva l'ortografia di origine ma non è una risoluzione del tipo in grado di riconoscere lo spazio dei nomi.

Ogni DOCTYPE viene rifiutato prima che fast-xml-parser riceva il documento. La maschera evita false corrispondenze all'interno dei commenti e CDATA. Ciò impedisce richieste di entità esterne, letture di entità di file locali e attacchi di espansione di entità, senza possibilità di aggirare il rifiuto.

I prefissi dello spazio dei nomi vengono mantenuti letteralmente e ogni DOCTYPE viene rifiutato

In `<p>before<b>bold</b>after</p>`, il posizionamento del testo è importante. ToolAcre rileva contenuti misti, unisce i frammenti in `#text` e avverte che le loro posizioni relative ai bambini vengono perse. Le proprietà dell'oggetto JSON non possono riprodurre una sequenza ordinata di testo alternato e nodi di elementi.

I figli con lo stesso nome ripetuti diventano array, ma i fratelli con nomi diversi rimangono proprietà. Il codice che richiede l'ordine esatto dei documenti deve utilizzare una rappresentazione del nodo XML anziché considerare l'oggetto convertito come completo.

Cosa non copre: XSLT, XPath e XQuery, i linguaggi di elaborazione cresciuti attorno a XML

XSLT, XPath e XQuery non vengono importati o esposti. Né il pannello convalida XSD, elabora dichiarazioni DTD o costruisce oggetti di dominio tipizzati. È una proiezione di dati con limiti espliciti di sicurezza e fedeltà.

Un linguaggio di query o trasformazione può preservare e navigare nell'ordine dei nodi in modi che questa conversione di valori semplici non può. Scegli questo strumento quando le caratteristiche del documento fanno parte del lavoro piuttosto che un imballaggio accessorio.

Conclusione: XML è un formato di documento che ha imparato a trasportare dati e come il pannello dei convertitori di sintassi mostra ciò che sopravvive alla sua traduzione in JSON

Il modello di dati osservabili di XML include distinzioni assenti da JSON. ToolAcre contrassegna attributi, CDATA e testo strutturato, conserva i prefissi degli spazi dei nomi, elimina i nodi non dati e rifiuta i DOCTYPE. Ogni scelta è visibile e testata.

Utilizza il pannello per scoprire cosa sopravvive a una proiezione, non come autorità storica o come processore XML completo. Quando ordini, gli schemi o la semantica dello spazio dei nomi sono importanti, mantieni l'albero originale e utilizza strumenti XML appositamente creati.

Sicurezza e fedeltà si intersecano anche al confine DOCTYPE. Rifiutare la dichiarazione impedisce l'elaborazione dell'entità, ma eliminarla da un documento legacy arbitrario può modificare i riferimenti all'entità o i presupposti di convalida. Se possiedi la fonte, sostituisci le entità richieste con testo sicuro esplicito e convalida il documento risultante. Se non lo possiedi, utilizza un flusso di lavoro XML approvato anziché indebolire il rifiuto o presentare una conversione parziale come contenuto originale.