Progettazione di un sistema di documenti JSON auto-descrittivo

0

Sto provando a ideare un sistema di documenti per un dominio specifico che coinvolga oggetti semplici (persone, società, fatture, ecc.) che sarebbe anche in grado di descrivere completamente se stesso. Questa capacità di auto-descrizione sarebbe idealmente ricorsiva. Il sistema documentale sarà basato su JSON, ma credo che il principio in questione si applichi a qualsiasi notazione strutturata.

Per illustrare cosa intendo, diciamo che ho il seguente documento JSON che descrive una persona (azienda, fattura, ecc. sono fondamentalmente tutti uguali, solo con proprietà diverse):

{
  "Name": "John Doe",
  "Email": "[email protected]",
  "BirthDate": "1976-07-04"
}

Quindi, ho un secondo documento JSON che descrive la struttura del primo. Chiamiamo questo "Meta-documento di livello 1":

{
  "Type": "Person",
  "Properties": {
    "Name": { "Type": "String", "Required": true },
    "Email": { "Type": "String" },
    "BirthDate": { "Type": "Date" }
  }
}

Questo sarebbe abbastanza semplice, se non fosse per il requisito, quel sistema dovrebbe anche essere in grado di descrivere completamente questo meta-documento.

Per dirla in termini più generali: sto cercando un modo per definire un "Meta-documento di livello N" autosufficiente, che sarebbe in grado di descrivere una struttura dei "Meta-documenti di livello N-1" ".

NOTA : sarei disposto ad adottare una soluzione per N = 2, ma l'istinto mi dice che una vera soluzione per N = 2 funzionerebbe anche per qualsiasi N. Ora che penso di esso, questo potrebbe essere più un puzzle di matematica che programmarne uno. :)

È persino possibile? Se sì, puoi darmi qualche esempio? In caso contrario, quali sono le mie altre opzioni?

EDIT: ho incluso un ingenuo esempio di come apparirebbe un "Meta-documento di livello 2", basato su quanto sopra:

{
  "Type": "MetaLevel2",
  "Properties": {
    "Properties": { "Type": "Hash", "Required": true }
  }
}

Il problema con questo è che non descrive l'oggetto che descrive i dettagli della proprietà (cioè quello con gli attributi "Tipo" e "Richiesto").

Se dovessi includere la descrizione di questi, dovrei aggiungere un altro attributo allo stesso oggetto che sto tentando di descrivere :

{
  "Type": "MetaLevel2",
  "Properties": {
    "Properties": {
      "Type": "Hash",
      "Required": true,
      "ValueProperties": { "Type": "String", "Required": "Boolean" }
    }
  }
}

Purtroppo questo mi getta in un problema ricorsivo, perché ora mi manca la descrizione di "ValueProperties". Infatti, per ogni nuovo attributo che invento al livello N, ho un problema che lo descrive al livello N + 1 senza introdurre ancora un altro attributo che necessita di descrizione.

Quello che sto cercando è una soluzione che non risentirebbe di questo problema.

Per essere chiari: sono a conoscenza di XSD, ma non sono sicuro di come applicare i suoi principi al mio caso. A meno che non manchi qualcosa, XSD soffrirebbe dello stesso problema ricorsivo. Questo mi dà ragione per credere di avere un problema con l'approccio stesso.

    
posta aoven 23.03.2013 - 11:03
fonte

3 risposte

-1

Sembra che ora abbia trovato un approccio migliore. Il problema della ricorsione può essere evitato appiattendo gli oggetti nidificati, in questo modo:

{
  "Type": "MetaLevel2",
  "Properties": {
    "Properties": { "Type": "Hash", "Required": true },
    "Properties.Type": { "Type": "String", "Required": true },
    "Properties.Required": { "Type": "Boolean" }
  }
}

Certo, sembra un lieve abuso del sistema di proprietà, ma non in modo irragionevole. Posso creare la consapevolezza necessaria sulla notazione del nome della proprietà punteggiata direttamente nel software che gestirà questi documenti.

Lascerò la domanda aperta ancora per un po '. A meno che qualcuno non trovi una soluzione più pulita in quel periodo, andrò con questo.

EDIT: Sì, funziona abbastanza bene, come risulta.

Ogni volta che decido di aver bisogno di un altro attributo annidato, posso semplicemente descriverlo usando la notazione appiattita, rimanendo così compatibile con la struttura esistente.

L'unica cosa speciale che il software deve capire per consumare questi documenti è il significato di "Tipo": attributo "Hash", che segnala che diversi attributi dovrebbero essere interpretati come un singolo oggetto JSON durante la lettura e viceversa quando si scrive .

Ancora, grazie a tutti quelli che hanno avuto il tempo di leggere tutto questo e di rispondere!

    
risposta data 23.03.2013 - 13:25
fonte
2

C'è Progetto IETF per schema JSON . Sembra proprio quello che vuoi usare. Anche dai un'occhiata a Wikipedia .

    
risposta data 23.03.2013 - 13:34
fonte
-1

Sì, questo è possibile. Questo è già utilizzato per XML e si chiama XML Schema Definition (XSD) .

Puoi semplicemente prendere ciò che fa XSD e fare la stessa cosa con JSON.

    
risposta data 23.03.2013 - 11:48
fonte

Leggi altre domande sui tag