Se XML è così male ... perché così tante persone lo usano? [chiuso]

Capisco lo scopo di XML, ma sento sempre persone lamentarsi di quanto sia MALE? Non capisco davvero cosa ci sia di male? Di solito ascolto i termini "gonfio" e "lento".

Ma immagino che come programmatori, per cosa lo usi principalmente? E lo consideri davvero "cattivo" ... perché se lo è, moltissime persone lo usano per il trasporto di dati ...

Xml è perfetto per quello che è stato progettato: un protocollo di trasferimento dati leggibile dall'uomo, neutro dalla piattaforma, con alcune funzionalità per applicare la convalida dei dati a livelli bassi. Dubito che chiunque usi Xml in questo modo abbia una vera lamentela. È il formato di filo più succinto? No. Ma ci sono opzioni peggiori. È veloce come leggere il tuo formato binario personalizzato? No. Ma i tuoi partner commerciali possono leggerlo nello stack che stanno utilizzando.

Il problema, tuttavia, è che gli umani - specialmente la razza conosciuta come architetti d'impresa - sono malvagi e prendono le cose buone e le rendono cattive. Nel caso di Xml, la prima parte di questo secolo ha visto Xml come il martello universale per ogni problema IT. Cospargi un po 'di design per commissione e finirai con alcune mostruosità orribili come SOAP e oXML . Nessuno dei due dovrebbe essere desiderato sui nemici, non dimenticare amici o colleghi.

XML è solo uno strumento disponibile in molti gusti e usi. XML eccelle in alcune cose e fa schifo in altre. Penso che uno dei problemi sia che le persone hanno visto XML "enterprise" che è inutilmente complesso con spazi dei nomi e schifezze sparse (SOAP, chiunque?). Il trucco per la progettazione di formati XML per gli esseri umani consiste nell'aggiungere un significato reale ai dati senza renderli schiaccianti da leggere.

Una delle cose con cui le persone si mettono in discussione è che a volte XML soffoca su alcuni caratteri o su alcune parentesi mancanti. Vi è, tuttavia, sia un lato positivo che un lato negativo. Il lato positivo è che non hai ambiguità come hai fatto con l'HTML in cui diversi casi di sintassi semi-non valida possono essere interpretati in modo diverso.

Il rovescio della medaglia è che è un po 'più difficile da creare e più difficile da imparare. Sono d'accordo che si potrebbe sostenere che il Web non sarebbe diventato così grande se l'HTML fosse rigoroso come l'XML, ma direi anche che saremmo contenti se lo facesse oggi. :)

Inoltre, non usarlo per tutto solo perché puoi, avere il senso e il giudizio per applicarlo in modo appropriato. Se tutto ciò che hai è XML, tendi sempre ad essere una trasformazione XSLT lontano da ciò che desideri. :)

Direi che il formato conta davvero solo quando gli umani devono interagire con esso. Se stai scrivendo un programma che serializza qualcosa e lo invia da qualche parte dove deve essere consumato da un altro dei tuoi programmi, a chi importa che aspetto ha, purché sia ​​il più efficiente possibile? Usa un formato binario o coniglietti e unicorni per tutto ciò che mi interessa.

Pro di XML

• Copre molti casi limite che YAML e JSON non hanno
• Esistono strumenti eccellenti per l'analisi e la convalida di XML in una matrice di piattaforme e linguaggi diversi
• L'XML può essere facilmente e potentemente trasformato in un altro formato (tramite cose come XSLT)
• I documenti XML ragionevoli sono semplici da leggere e modificare per gli esseri umani; non dirmi che JSON è più facile, non è :)
• XML è auto-descrittivo in una certa misura, cioè contiene direttamente informazioni sulla sua struttura e significato (contrariamente alla maggior parte dei formati binari)
• Gestisce la codifica
• Spazio bianco agnostico, che semplifica l'utilizzo multipiattaforma
• Si rompe se non è ben formato (Assicura che i dati siano strutturalmente corretti)
• Non è SGML

Contro

• verboso
• Analizzare non è veloce come binario
• Si interrompe se non è ben formato (arresta in modo anomalo l'applicazione)

Buoni usi

• File di configurazione
• Formati di scambio dati
• Formati di file resilienti alla versione
• Archiviazione di documenti in database

Usi non così buoni

• Formati di trasferimento dati
• Serializzazione di oggetti
• Memorizzazione dei dati relazionali nei database
• Formato file per scenari I / O ad alte prestazioni

Jeff Atwood ha un post sul blog abbastanza buono in XML: The Angle Bracket Tax su questo se vuoi che una fonte ne parli.

Gli usi più comuni che ho per questo sono:

• Servizi che parlano tra loro. Ad esempio, un sito Web che utilizza un sistema di gestione dei contenuti deve inviare alcuni dati in un sistema di gestione delle relazioni con i clienti e questo viene fatto con XML.

• Memoria di configurazione. Web.config e app.config sono esempi comuni, ma anche gli script nAnt possono utilizzare anche alcuni XML.

Non penso che sia ottimale, ma da solo non mi dispiace.

Due motivi:

1. Ci sono un sacco di cattivi programmatori là fuori. L'XML può essere dannoso, ma è anche semplice (almeno in superficie) e semplifica la scrittura di software dannoso. Sorta come VB.
2. Molte persone che prendono queste decisioni non sono programmatori, ma tipi di attività che hanno sentito solo che "tutti usano XML" e quindi decidono che vogliono che anche il loro prodotto usi XML.

Di solito ascolto i termini "gonfio" e "lento".

Non è la sintassi più compatta, ma è chiaramente la più espressiva. Leggibile dagli umani? dipende da come progetti la tua lingua. Molte persone non progettano un linguaggio per XML, ma semplicemente serializzano gli oggetti come XML.

... perché così tante persone lo usano?

È onnipresente. Puoi interrogare un database XML con XQuery, trasformare i risultati con XSLT come XHTML o Atom, ottenere Atom o altri formati XML da altri servizi Web, ottenere XML dagli utenti utilizzando XForms, convalidarlo con XMLSchema, Relax NG o Schematron, elaborarlo con XProc, salvarlo di nuovo nel database con XQuery Update. Tutti questi strumenti comprendono l'XML, quindi non è necessario mappare tra diverse rappresentazioni.

XML non è una tecnologia di serializzazione, è un insieme di informazioni di uso generale.

Qui, lo usiamo per lo scambio di dati tra diversi sistemi realizzati da diversi fornitori con diverse rappresentazioni interne. Costruiamo un sistema di trasformazione / interscambio XML per trasferire i dati avanti e indietro. Funziona bene per quello.

XML non è intrinsecamente negativo, ma riconosco che progettare una soluzione "buona" utilizzando XML non è banale.

"L'essenza dell'XML è questa: il problema che risolve non è difficile e non risolve bene il problema." - Phil Wadler, POPL 2003

La mia opinione personale è che fino a quando non ti preoccupi della convalida, degli schemi, degli XSLT e delle altre cose brutte e mantieni le dimensioni dei file piccole (altrimenti l'analisi diventa lenta) puoi trovare alcuni buoni usi dell'XML (un esempio serve per configurare la tua applicazione invece di usare i file INI).

Nella mia esperienza, le persone si lamentano principalmente del modo in cui viene utilizzato, non della tecnologia stessa.

I bit gonfi e lenti di cui le persone si lamentano sono in genere le librerie / i metodi utilizzati per recuperare informazioni da esso.

Lo uso per archiviare piccole quantità di informazioni strutturate che voglio archiviare su disco (senza database o serializzazione binaria) o passare a un'altra applicazione (che in sostanza descrive anche SOAP).

È buono perché:

È una "interfaccia" standard con cui possono comunicare più sistemi eterogenei. Ed è "Human" leggibile (tipo di, prova a fissare XML da 5 MB)

È male perché:

È gonfio, dimensioni maggiori = maggiore larghezza di banda = più $$

Ci sono altri motivi, ognuno ha una lamentela diversa ...

Come per qualsiasi altra tecnologia: ci sono molti strumenti e librerie disponibili.

Non mi piace l'XML, soprattutto perché è funky, quando le persone dicono che è leggibile dall'uomo, scherzano, penso, o non hanno mai veramente letto un XML quando si tenta di incorporare XML in un attributo ... le entità XML lo rendono davvero illeggibile. Inoltre, è sorprendente quanto spazio viene sprecato a causa del tag di fine ridondante e della capacità di mescolare testo e dati gratuiti ...

Ma:

• Xml può essere specificato (xsd) e sono disponibili strumenti che controllano la conformità dei dati Xml
• molti strumenti (editor di testo e simili) supportano Xml
• molte librerie (in circa tutti i linguaggi di programmazione) supportano Xml

Ha anche il vantaggio della precedenza, il più delle volte. Quando stai già fornendo servizi web in Xml e uno ti chiede un nuovo servizio ... probabilmente verrà fatto in Xml perché è quello che sai.

XML è una cattiva scelta per i file che devono essere gestiti dagli umani. Non c'è separazione visiva tra il markup e il contenuto, il che rende difficile la lettura. È noioso scrivere correttamente senza un editor per scopi speciali. Qualsiasi errore in un documento XML è fatale; un documento XML non può essere parzialmente elaborato. Quando un file XML non è valido, il messaggio di errore risultante è spesso inutile.

Per qualsiasi file che deve essere gestito da un essere umano, preferirei utilizzare uno qualsiasi di JSON, YAML o codice sorgente in un linguaggio interpretato (Python, Ruby, Groovy, ecc.). Abbiamo scoperto che un ottimo modo per creare una configurazione XML per il codice legacy è utilizzare Groovy MarkupBuilder. Un'altra buona scelta è quella di creare un linguaggio specifico per il dominio; questo è abbastanza facile da fare con Ruby, Groovy e molte altre lingue.

L'analisi è relativamente semplice pur essendo leggibile dall'uomo allo stesso tempo.

E alcuni simpatici parser (ad esempio Xerces {c ++}) sono prontamente disponibili.