2012-01-11 11 views
8

Mi piace JSON come formato per i file di configurazione per il software che scrivo. Mi piace il fatto che sia leggero, semplice e ampiamente supportato. Tuttavia, sto scoprendo che ci sono alcune cose che mi piacerebbe davvero che JSON non avesse.Alternative JSON (allo scopo di specificare la configurazione)?

Json non ha stringhe multilinea o qui documenti (http://en.wikipedia.org/wiki/Here_document), e questo è spesso molto imbarazzante quando si desidera che il file JSON sia leggibile ed accessibile dall'utente. Puoi utilizzare array di stringhe, ma questa è una soluzione sfacciata.

Json non ammette commenti.

Se si guardano i formati dei file di configurazione di Unix, si vede un sacco di persone che progettano i propri formati scomodi per cose che avrebbe davvero più senso fare usando una specie di cosa generale. Ad esempio, ecco qualche codice da un file di configurazione di Apache:

RewriteEngine on 
RewriteBase /temp 
RewriteCond %{HTTP_ACCEPT} application/xhtml\+xml 
RewriteCond %{HTTP_ACCEPT} !application/xhtml\+xml\s*;\s*q=0 
RewriteCond %{REQUEST_URI} \.html 
RewriteCond %{THE_REQUEST} HTTP/1\.1 
RewriteRule t\.html t.xhtml [T=application/xhtml+xml] 

In sostanza, quello che sta succedendo qui è che hanno inventato un modo estremamente dolorosa di scrivere una funzione booleana f (w, x, y, z) = w &! x & y & z. Vuoi un "o" logico? Hanno anche un meccanismo separato (brutto) per quello.

Ciò che sembra indicare è una sorta di linguaggio di descrizione dei dati semplice e turing-incompleto, ma ancora più espressivo, flessibile e conveniente di json. Qualcuno sa di un tale linguaggio?

A mio gusto, XML è troppo complicato, e le espressioni chiare hanno le caratteristiche sbagliate (completezza di Turing) e mancano delle caratteristiche giuste (qui documenti, sintassi espressiva).

[EDIT] Il titolo è fuorviante. Non sono letteralmente interessato alla prossima iterazione di JSON. Non sono interessato alle lingue che sono un sottoinsieme di javascript. Sono interessato ai linguaggi di descrizione dei dati alternativi.

+3

[YAML] (http://en.wikipedia.org/wiki/YAML)? – BalusC

+0

@BalusC: Suggerimento interessante :-) Ma YAML non sembra offrire un buon modo di fare la funzione booleana/l'esempio di Apache o le applicazioni con un sapore simile. –

risposta

1

La "J" in JSON è "Javascript". Se un particolare costrutto di sintassi desiderato non è in Javascript, non sarà su JSON.

Heredocs sono al di là della competenza di JSON. Questo è un costrutto di sintassi del linguaggio per la definizione di stringa multi-linea semplificata, ma JSON è una notazione di trasporto. Non ha nulla a che fare con la costruzione. Tuttavia, ha stringhe multilinea, semplicemente consentendo \n caratteri di nuova riga all'interno di stringhe. Non c'è niente in JSON che dice che non è possibile avere un'interruzione di riga in una stringa. Finché i caratteri di citazione contenenti sono corretti, è perfettamente valido. per esempio.

{"x":"y\nz"} 

è 100% legittimo JSON valido, ed è una stringa multilinea, considerando

{"x":"y 
z"} 

non è e non riuscirà a parsing.

+0

"Se un particolare costrutto di sintassi desiderato non è in Javascript, non sarà su JSON." È carino, ma JSON non è in realtà un sottoinsieme di JavaScript e supporta cose che JavaScript non ha. – kyrias

2

C'è sempre quello che mi piace chiamare "vero JSON". JSON è l'acronimo di JavaScript Object Notation e JavaScript fa ha commenti e qualcosa di abbastanza vicino a heredocs.

Per il heredoc, si usa E4X XML inline di JavaScript:

{ 
    longString: <> 
       Hello, world! 
       This is a long string made possible with the magic of E4X. 
       Implementing a parser isn't so difficult. 
       </>.toString() // And a comment 
    /* And another 
     comment */ 
} 

È possibile utilizzare il motore JavaScript di Firefox (FF è l'unico browser a supportare E4X attualmente) oppure è possibile implementare il proprio parser, che in realtà non è così difficile

Here's the E4X quickstart guide, too.

+0

Idea interessante, anche se fallisce il criterio di Turing-incompletezza. –

+0

qual è/sono il modo/i per comprimere gli spazi bianchi per il salvataggio della larghezza di banda della rete? Grazie. –

+1

@AizzatSuhardi: Usa effettivo JSON JSON – Ryan

0

Un importante attributo JSON (probabilmente il più importante) è che si può facilmente "flip" tra la rappresentazione di stringa e la rappresentazione in forma di oggetto, e gli oggetti utilizzati per rappresentare la forma oggetto sono relativamente matrici e mappe semplici. Questo è ciò che rende JSON così utile in un contesto di rete.

Le funzioni desiderate sono in conflitto con questa doppia natura di JSON.

4

EDN format è un'opzione basata sui valori letterali Clojure. È quasi un superset di JSON, tranne per il fatto che nessun simbolo speciale separa chiavi e valori nelle mappe (come fa : in JSON); piuttosto, tutti gli elementi sono separati da spazi bianchi e/o una virgola e una mappa è codificata come una lista con un numero pari di elementi, racchiusi tra {..}.

EDN consente commenti (a newline utilizzando ; o alla fine dell'elemento successivo letto utilizzando #_), ma non qui-docs. È estensibile a nuovi tipi usando un tag notazione:

#myapp/Person {:first "Fred" :last "Mertz"} 

L'argomento del tag myapp/Person (cioè {:first "Fred" :last "Mertz"}) deve essere un'espressione valida EDN, il che rende inestensibile di supporto qui-doc.

Ha due tag incorporati: #inst per data e ora #uuid. Supporta anche i simboli con il simbolo dei nomi (cioè identificativo) e le parole chiave (cioè i tipi di chiavi delle mappe); distingue le liste (..) e vettori [..]. Un elemento di qualsiasi tipo può essere usato come chiave in una mappa.

Nel contesto del tuo problema precedente, si potrebbe inventare un tag #apache/rule-or che accetta una sequenza di elementi, la cui semantica ti lascio!

0

Per la configurazione è possibile utilizzare un linguaggio di scripting integrabile, come lua o python, infatti questa non è una cosa insolita da fare per la configurazione. Questo ti dà stringhe multilinea o qui documenti e commenti. Rende anche più facile avere cose come la funzione booleana che descrivi. Tuttavia, i linguaggi di scripting sono, naturalmente, completi Turing.

4

Dai un'occhiata alla http://igagis.github.io/stob/

E 'ancora più semplice di JSON.

Ha commenti in stile C++.

È possibile formattare stringhe multilinea e utilizzare la nuova linea sfuggita \ n e tab \ t char se è necessaria una nuova riga o scheda "reale".

Ecco il frammento di esempio:

"String object" 
AnotherStringObject 
"String with children"{ 
    "child 1" 
    Child2 
    "child three"{ 
     SubChild1 
     "Subchild two" 

     Property1 {Value1} 
     "Property two" {"Value 2"} 
     //comment 

     /* multi-line 
      comment */ 

     "multi-line 
     string" 

     "Escape sequences \" \n \r \t \\" 
    } 

R"qwerty(
This is a 
raw string, "Hello world!" 
int main(argc, argv){ 
    int a = 10; 
    printf("Hello %d", a); 
} 
)qwerty" 
} 
+0

Questo è amore a prima vista. Ha anche una stringa raw letterale impressionante – Abdurrahim

+0

Felice che ti sia piaciuto. Sfortunatamente, il supporto delle stringhe raw è implementato solo nella libreria C++. Al momento, le librerie C# e Java mancano del supporto delle stringhe raw. – igagis

+0

Indovina che è il momento di collaborare allo sviluppo del sistema operativo. Soprattutto la libreria C# ha bisogno di miglioramenti sembra come se fosse stata scritta da uno sviluppatore C++ :) – Abdurrahim

Problemi correlati