XML nell'attributo di altri XML

Se si esegue correttamente l'escape dell'XML interno, allora questa CAN può funzionare. Non ho intenzione di fare scommesse su quanto tempo ancora prima di trovare problemi di stravaganza con la fuga,

Personalmente ritengo che sia una cosa MOLTO strana da fare, e penso che causerà un sacco di grattacapi sulla linea. Cosa ancora più importante (forse), significa che non è possibile utilizzare la roba standard per incasellare direttamente l'XML "interno": devi sempre estrarlo, sfuggire e poi puoi prenderlo in giro. Diamine, non puoi nemmeno applicare XPATH che funzioneranno con l'XML interno, per non parlare di qualcosa come XSLT.

Non lo farei, ma non conosco il problema, quindi non posso essere sicuro che non sia la soluzione migliore disponibile in un campo di soluzioni davvero orribili.

Wow, questo è un modo totalmente sbagliato di fare le cose ... Certo che può funzionare, ma perché?

Hai appena aggiunto un nuovo livello di escaping e analisi che nessun altro strumento al mondo può gestire. Che cosa succede se è necessario utilizzare una trasformazione XSLT su di esso? Come usi XPATH su di esso? È solo un lavoro extra per recuperare quei dati senza alcun vantaggio reale.

Il modo corretto per farlo è metterlo come elemento secondario dell'elemento, che ti permette di mettere ... sorprendentemente ... più XML. Ora viene analizzato solo una volta, non ti preoccupi di eseguire l'escape e il doppio parsing e qualsiasi strumento XML sarà in grado di leggere la struttura.

L'unica lamentela che posso vedere su questo è se il contenuto dell'elemento XML ha un semplice contenuto del nodo di testo. In questo caso, sposta semplicemente il testo in un altro sottoelemento. Dovrebbe essere piuttosto semplice aggiornare qualsiasi riferimento XPATH ad esso.

Se l'XML scappato segue un formato specifico Usa uno schema per definire quel formato e metterlo dove appartiene come un altro elemento. Dai suoni delle cose, l'app non usa uno schema e l'analisi è fatta a mano ... ci sono molti formati più adatti per trasmettere dati che XML quindi suppongo che la mia domanda sia perché il programma usa XML in il primo posto.

Sembra che ci sia molto male ma senza una conoscenza di prima mano non potrei iniziare a suggerire come risolverlo.

1. Interromperà il formato dei dati a meno che, a meno che tu non codifichi il codice XML interno, allora dovrebbe fare il trucco.

2. Probabilmente è sicuro ma ... strano. C'è sempre un modo migliore.

L'unica ragione valida che posso pensare è il tentativo di passare informazioni aggiuntive o nuove su un'interfaccia che non può essere modificata / estesa per qualche motivo. Quindi devi trovare un modo per "spremere" nuovi dati in un vecchio formato. Forse è un'interfaccia vecchia e consolidata che è stata accuratamente testata, approvata e certificata. Il costo di cambiarlo sarebbe immenso.

Oltre a questo ... beh ... strano come ho detto ...

Questo è un chiaro indicatore, che il markup esterno è difettoso e dovrebbe quindi essere corretto.
Gli attributi XML sono pensati per valori piatti.

Certo che puoi farlo. SVG mostra che puoi persino renderne uno standard, sebbene in questo caso vi siano chiari vantaggi.

Nel tuo caso, tuttavia, i dati in questione devono essere un bambino anziché un attributo. Punto fermo.

Ho fatto esattamente questo e voglio spiegare in che senso era corretto.

Stavo usando un framework che duplica i dati attraverso una rete. Un server mantiene i dati. I clienti possono iscriversi a una vista sui dati. Ricevono lo stato attuale e vengono successivamente informati di eventuali modifiche. Le modifiche consistevano nell'aggiunta o rimozione di un'entità dati, nell'impostazione di un valore del campo entità o nell'impostazione di una relazione tra entità.

Lo stato e i dati correnti sono stati codificati in XML. Ad esempio, se un prodotto è prenotato e le modifiche di disponibilità, il client potrebbe ricevere un aggiornamento come:

<upd type="product" id="678" available="19" reserved="1" />

Tutti i valori dei campi primitivi sono dati come attributi.

Quello che è successo allora è che un campo proveniente dal DB conteneva XML. È stato memorizzato come stringa XML perché solo il client aveva bisogno di interpretarlo. Pertanto, l'XML, come qualsiasi stringa, è stato correttamente scappato e passato come attributo.

La morale

Non c'è niente di sbagliato, è solo l'isolamento tra due livelli.

Il livello inferiore trasporta le stringhe, tra le altre cose, e capita di rappresentare stringhe come attributi XML. Il livello superiore necessario per trasportare XML e utilizzato naturalmente la rappresentazione di stringa di XML. L'effetto combinato è che ottieni il codice XML codificato in un attributo.

Rilevare quella situazione e spostare quell'XML su un elemento annidato (come il mio capo voleva che facessi) avrebbe infranto l'indipendenza degli strati. Il livello superiore dovrebbe taggare il campo come "questo è formato correttamente XML", e il livello più basso direbbe "bello, lo passerò come elemento annidato".

Per mostrare che è sbagliato, immagina che il livello inferiore sia sostituito da un giorno per usare JSON. Ora deve essere notificato dei dati che sono formattati correttamente JSON. Ma il livello superiore non dovrebbe essere influenzato da cambiamenti nell'implementazione del livello inferiore.

La conversione dell'XML in testo di escape sta distruggendo efficacemente questo markup - convertendolo in una sola dimensione.

Questo è per il tag "cattive pratiche" - non "best practice".