Domanda

Per me utilizzabile significa che:

  • viene utilizzato nel mondo reale
  • ha strumenti di supporto.(almeno qualche semplice editor)
  • ha una sintassi leggibile dall'uomo (niente parentesi angolari, per favore)

Inoltre voglio che sia il più vicino possibile a XML, ad es.deve esserci supporto sia per gli attributi che per le proprietà.Quindi no YAML Per favore.Attualmente mi viene in mente solo una lingua corrispondente: JSON.Conosci altre alternative?

È stato utile?

Soluzione

YAML è un superset al 100% di JSON, quindi non ha senso rifiutare YAML e considerare invece JSON.YAML fa tutto ciò che fa JSON, ma YAML offre anche molto di più (come i riferimenti).

Non riesco a pensare a nulla che XML possa fare che YAML non possa fare, tranne convalidare un documento con un DTD, che nella mia esperienza non è mai valso il sovraccarico.Ma YAML è molto più veloce e più facile da digitare e leggere rispetto a XML.

Per quanto riguarda gli attributi o le proprietà, se ci pensi, non "aggiungono" veramente nulla...è solo una scorciatoia notazionale per scrivere qualcosa come attributo del nodo invece di inserirlo nel proprio nodo figlio.Ma se ti piace questa comodità, puoi spesso emularlo con gli elenchi/hash incorporati di YAML.Per esempio:

<!-- XML -->
<Director name="Spielberg">
    <Movies>
        <Movie title="Jaws" year="1975"/>
        <Movie title="E.T." year="1982"/>
    </Movies>
</Director>


# YAML
Director: 
    name: Spielberg
    Movies:
      - Movie: {title: E.T., year: 1975}
      - Movie: {title: Jaws, year: 1982}

Per me, il lusso di non dover scrivere due volte ciascun tag di nodo, combinato con la libertà da tutta la spazzatura delle parentesi angolari, rende YAML una scelta preferita.In realtà mi piace anche la mancanza di attributi formali dei tag, poiché mi è sempre sembrata un'area grigia di XML che introduceva inutilmente due serie di sintassi (sia durante la scrittura che durante l'attraversamento) essenzialmente per lo stesso concetto.YAML elimina del tutto questa confusione.

Altri suggerimenti

JSON è un'ottima alternativa e sono disponibili strumenti in più lingue.Ed è davvero facile da usare nei client Web, poiché è Javascript nativo.

ho trovato Espressioni S essere un ottimo modo per rappresentare dati strutturati.È un formato molto semplice, facile da generare e analizzare.Non supporta gli attributi, ma come YAML e JSON, non è necessario.Gli attributi sono semplicemente un modo per XML di limitare la verbosità.I formati più semplici e puliti semplicemente non ne hanno bisogno.

TL;DR

Prolog non è stato menzionato qui, ma è il miglior formato che conosco per rappresentare i dati.I programmi Prolog, essenzialmente, descrivono database, con relazioni complesse tra entità.Prolog è semplicissimo da analizzare, il cui probabilmente unico rivale sono le espressioni S in questo dominio.

Versione completa

I programmatori spesso "dimenticano" in cosa consiste effettivamente XML.Di solito si riferisce a un sottoinsieme molto piccolo di ciò che è.XML è un formato molto complesso, con almeno queste parti: Linguaggio dello schema DTD, Linguaggio dello schema XSD, Linguaggio di trasformazione XSLT, Linguaggio dello schema RNG E XPath (più XQuery): sono tutti parte integrante dello standard XML.Inoltre, ci sono alcuni apocrifi simili E4X.Ognuno di essi ha la propria versione, un bel po' di sovrapposizioni, incompatibilità, ecc.Pochissimi parser XML in circolazione li implementano tutti.Per non parlare delle molteplici stranezze e bug dei popolari pars, alcuni dei quali portano a notevoli problemi di sicurezza come https://en.wikipedia.org/wiki/XML_external_entity_attack .

Pertanto, alla ricerca di un file XML alternativa non è una buona ideaProbabilmente non vorrai affatto avere a che fare con XML.

YAML è, probabilmente, la seconda opzione peggiore.Non è grande quanto XML, ma è stato progettato nel tentativo di coprire tutte le basi...più di dieci volte ciascuno...in modi diversi e unici che nessuno avrebbe mai potuto concepire.Devo ancora sentire parlare di un parser YAML che funzioni correttamente.Ruby, il linguaggio che utilizza molto YAML, aveva notoriamente avvitato per questo motivo.Tutti i parser YAML che ho visto finora sono copie di libiaml, che è esso stesso un tipo di parser scritto a mano (non generato da una descrizione formale), con un codice di cui è molto difficile verificare la correttezza (funzioni che si estendono su centinaia di righe con un flusso di controllo contorto).Come già accennato, contiene completamente JSON al suo interno...oltre a una manciata di tecniche di codifica Unicode...all'interno dello stesso documento e probabilmente un sacco di altre cose di cui non vuoi sentire parlare.

JSON, d'altra parte, è completamente diverso dagli altri due.Probabilmente puoi scrivere un parser JSON mentre aspetti il ​​download dell'artefatto del parser JSON dal tuo Maven Nexus.Può fare ben poco, ma almeno sai di cosa è capace.Niente sorprese.(Tranne alcune discrepanze relative all'escape dei caratteri nelle stringhe e alla doppia codifica).Nessun exploit nascosto.Non puoi scrivere commenti al suo interno.Le stringhe multilinea sembrano pessime.Qualunque cosa intendi per distinzione tra proprietà e attributi, puoi implementarla con più dizionari nidificati.

Supponiamo che tu voglia correggere ciò che XML ha sbagliato...beh, allora cose popolari come YAML o JSON non lo faranno.In qualche modo la moda e il pensiero razionale si separarono nella programmazione a metà degli anni settanta.Quindi, dovrai tornare a dove tutto ebbe inizio con McCarthy, Hoare, Codd e Kowalski, capire cosa stai cercando di rappresentare e poi vedere qual è la migliore tecnica di rappresentazione che esiste per qualunque cosa tu sia. cercando di rappresentare :)

Jeff ha scritto a riguardo Qui E Qui.Questo dovrebbe aiutarti a iniziare.

Consiglierei JSON...ma visto che ne hai già parlato forse dovresti darci un'occhiata Buffer del protocollo Google.

Modificare:I buffer di protocollo sono progettati per essere utilizzati in modo programmatico (esistono collegamenti per c++, java, python ...) quindi potrebbero non essere adatti al tuo scopo.

Le tue richieste sono un po' impossibili..Vuoi qualcosa di simile a XML, ma rifiuta probabilmente l'equivalente più vicino che non ha parentesi angolari (YAML).

Per quanto non mi piaccia, perché non usare semplicemente XML?Non dovresti mai dover leggere effettivamente XML (a parte il debug, suppongo), ci sono una quantità assurda di strumenti per questo.

Praticamente tutto ciò che non è XML non sarà così ampiamente utilizzato, quindi ci sarà meno supporto per gli strumenti.

JSON è probabilmente equivalente, ma è praticamente altrettanto illeggibile..ma ancora una volta, non dovresti mai leggerlo (caricalo in qualunque lingua tu stia utilizzando e dovrebbe essere trasformato in array/dict/variabili/qualunque cosa nativi).

Oh, trovo JSON lontano più bello da analizzare rispetto a XML:L'ho usato in Javascript e nel modulo Python simplejson - circa un comando ed è ben trasformato in un dict Python nativo o in un oggetto Javascript (da qui il nome!)

C'è ASSONE che coprono il meglio di XML e JSON.Spieghiamolo con diversi esempi.

AXON potrebbe essere considerato una forma più breve di dati XML.

XML

<person>
   <name>Frank Martin</name>
   <age>32</age>
 </person>

ASSONE

person{
  name{"Frank Martin"}
  age{32}}

O

person
  name:
    "Frank Martin"
  age:
    32

XML

<person name="Frank Martin" age="32" />

ASSONE

person{name:"Frank Martin" age:32}

O

person
  name: "Frank Martin"
  age: 32

AXON contiene una qualche forma di JSON.

JSON

{"name":"Frank Martin" "age":32 "birth":"1965-12-24"}

ASSONE

{name:"Frank Martin" age:32 birth:1965-12-24}

AXON può rappresentare una combinazione di dati di tipo XML e di tipo JSON.

ASSONE

table {
  fields {
    ("id" "int") ("val1" "double") ("val2" "int") ("val3" "double")
  }
  rows {
    (1 3.2 123 -3.4)
    (2 3.5 303 2.4)
    (3 2.3 235 -1.2)
  }
}

O

table
  fields
    ("id" "int")
    ("val1" "double")
    ("val2" "int") 
    ("val3" "double")
  rows
    (1 3.2 123 -3.4)
    (2 3.5 303 2.4)
    (3 2.3 235 -1.2)

È disponibile la libreria Python Pyaxon Ora.

Penso Argento chiaro è un'ottima alternativa.Hanno anche una pagina di confronto Qui e un elenco di progetti che lo usano

Per memorizzare dati simili a codici, LES (Loyc Expression Syntax) è un'alternativa in erba.Ho notato che molte persone usano XML per costrutti simili a codici, come sistemi di compilazione che supportano condizionali, invocazioni di comandi e talvolta anche loop.Questo genere di cose sembrano naturali in LES:

// LES code has no built-in meaning. This just shows what it looks like.
[DelayedWrite]
Output(
    if version > 4.0 {
        $ProjectDir/Src/Foo;
    } else {
        $ProjectDir/Foo;
    }
);

Tuttavia, non ha ancora un ottimo supporto per gli strumenti;attualmente l'unica libreria LES è per C#.Attualmente è noto che solo un'app utilizza LES: LLLPG.Supporta gli "attributi" ma sono come attributi C# o annotazioni Java, non attributi XML.

In teoria potresti utilizzare LES per dati o markup, ma non esistono standard su come farlo:

body {
    '''Click here to use the World's '''
    a href="http://google.com" {
        strong "most popular"; " search engine!"
    };
};

point = (2, -3);
tasteMap = { "lemon" -> sour; "sugar" -> sweet; "grape" -> yummy };

Se sei allergico alle parentesi angolari, allora JSON, HDF (ClearSilver) e OGDL sono gli unici che conosco subito.

Dopo aver cercato su Google, ho trovato anche un elenco di alternative qui:
http://web.archive.org/web/20060325012720/www.pault.com/xmlalternatives.html

YAML è un formato estremamente completo e generalmente leggibile dall'uomo, ma il suo punto debole è la complessità, come dimostrato dalle vulnerabilità di Rails che abbiamo riscontrato quest'inverno.A causa della sua ubiquità in Ruby come linguaggio di configurazione, Tom Preston-Werner di Github si è fatto avanti per creare un'alternativa sana chiamata TOML.Ha ottenuto immediatamente una trazione enorme e ha un ottimo supporto per gli strumenti.Consiglio vivamente a chiunque guardi YAML di dare un'occhiata:

https://github.com/mojombo/toml

AFAIK, JSON e YAML sono esattamente equivalenti in termini di struttura dei dati.YAML ha semplicemente meno parentesi, virgolette e cose del genere.Quindi non vedo come tu possa rifiutare l'uno e mantenere l'altro.

Inoltre, non vedo come le parentesi angolari di XML siano meno "leggibili dall'uomo" rispetto alle parentesi quadre, alle parentesi graffe e alle virgolette di JSON.

Esistono davvero tantissime alternative a XML, ma il problema principale con molte di esse sembra essere che le librerie potrebbero non essere disponibili per ogni linguaggio scelto e le librerie sono relativamente laboriose da implementare.

L'analisi di una struttura ad albero stessa potrebbe non essere così piacevole, se confrontata con coppie chiave-valore, ad es.tabelle hash.Se un'istanza di tabella hash soddisfa il requisito che tutte le sue chiavi siano stringhe e tutti i suoi valori siano stringhe, allora è relativamente semplice implementare hashtable2string() e string2hashtable().

Utilizzo la serializzazione della tabella hash in AJAX tra PHP e JavaScript e il formato che ho sviluppato si chiama ProgFTE (Programmer Friendly text Exchange) ed è descritto in:

http://martin.softf1.com/g/n//a2/doc/progfte/index.html

È possibile trovare una versione Ruby dell'implementazione ProgFTE come parte della libreria Ruby di Kibuvits:http://rubyforge.org/projects/kibuvits/

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top