Product SiteDocumentation Site

Chapter 1. Introduction

1.1. Requirements
Over the past decade, the need for more flexible and scalable databases has greatly increased. The NoSQL universe brings many new ideas on how to build both scalable data storage and scalable computing infrastructures.
XML and JSON are probably the most popular two data formats that emerged. While XML reached a level of maturity that gives it an enterprise-ready status, JSON databases are still in their early stages. Scalable data stores (like MongoDB) are already available. JSONiq brings SQL-like query capabilities to JSON. The last missing piece for a full-fledged JSON database is a way to make sure that the data stored is consistent and sound. This is where schemas come into play.
Many lessons can be learned from 40 years of relational databases history and 15 years of XML. The goal of this document is to introduce a schema language, JSound, which is much simpler than XML Schema, just like JSON syntax is much simpler than XML syntax.

1.1. Requirements

The JSound schema definition language is based on the following requirements:
  • A schema document must be a well-formed JSON document in the sense that it parses against the JSON grammar.
  • A schema document must be valid in the sense that there is a JSound metaschema document against which all schema documents (including itself) are valid.
  • While the schema definition language is greatly inspired from XML Schema, it must avoid its complexity. It must be simpler and more readable.
  • JSound must support most of the XML Schema primitive atomic types, as many of them are very useful and completely orthogonal to XML.
  • JSound must avoid the XML Schema model of restriction/extension of structured types. Instead, it must support a different model of subtyping based on classical object-oriented inheritance. In JSound, a subtype's value space must always be a subset of its base type's value space.
  • It must be possible to mark string/value pairs in an object type as optional or to specify a default value in case of absence.
  • It should be possible, given a JSON document, to turn it into a schema against which it is valid with minimal changes.