Introducing DSON

I was reading the YAML specification recently, and I noticed the section 
"1.3. Relation with JSON", which talked about a serialization format 
"YSON" between YAML and JSON. I realized this was exactly what I had 
been designing in my spare time for the past year or so, and so I 
thought I would share my thoughts on the matter. I'm designing a 
programming language called Droscript, and a serialization format called 
DSON (Droscript object notation), which can be described as tagged JSON, 
or cononical YAML, which ever suits your fancy. In short, roughly speaking:

  JSON < DSON < YAML.

The purpose behind DSON as a serialization format is to have a common 
format which is:

  - an RDF encoding, and
  - an OpenMath encoding.

A DSON Value can be one of: Array, Object, Number, String, Symbol, or 
Typed. A 'Symbol' can be either a Name or a URI. A Typed Value is 
expressed in a subset of YAML used for tags, so for example:

  !<http://www.openmath.org/cd/nums1#rational> [22, 7]

represents the rational number 22/7. The detailed grammar for the 
differences between DSON and JSON is:

  Start :
    ('@let' Object)* Value*

  Value :
    Array
    Object
    Number
    String
    Symbol # includes 'true', 'false', 'null'.
    Typed

  Pair :
    String ': ' Value
    Symbol ': ' Value

  ... # rest of JSON Syntax

  Typed :
    '!' String Value
    '!' Symbol Value

  Symbol :
    Name ':' Name ':' Name # for OMCD namespaces < \1 / \3 # \5 >
    Name ':' Name          # for XML namespaces  < \1 # \3 >
    Name                   # for RDF blank nodes < # \1 >
    URI

  # lexical

  Name : [A-Za-z-][0-9A-Za-z-]*

  URI : '<' URIContent '>'

The detailed differences, making (DSON != YAML), are

  - 'Typed' values can be tagged by 'String's,
  - 'Name's are namespaced with ':' and not '!',
  - 'Name's cannot start with a number, and
  - 'Pair's can be keyed by 'URI's.

DSON is an RDF encoding in that an RDF graph can be represented as

  !triples [
   [<http://www.w3.org/1999/02/22-rdf-syntax-ns#_1>,
    <http://www.w3.org/2000/01/rdf-schema#subPropertyOf>,
    <http://www.w3.org/2000/01/rdf-schema#member>]
  ]

which would stand for the Turtle syntax "rdf:_1 rdfs:subPropertyOf 
rdfs:member ." . Also, the common idiom of expressing typed values in 
RDF is "value^^typeURI", which can of course be written as "!typeURI 
value" in DSON.

DSON is an OpenMath encoding in that an OM object can be expressed as 
(the axiom of the empty set)

  !<http://www.w3.org/1998/Math/MathML#bind> 
[<http://www.openmath.org/cd/quant1#exists>, x,
    !<http://www.w3.org/1998/Math/MathML#bind> 
[<http://www.openmath.org/cd/quant1#forall>, y,
      !<http://www.w3.org/1998/Math/MathML#apply> 
[<http://www.openmath.org/cd/set1#notin>, y, x]
    ]
  ]

I also been considering a new directive would make the whole Name/URI 
thing easier in the long run:

  @let {
    om: <http://www.openmath.org/cd>,
    mml: <http://www.w3.org/1998/Math/MathML>,
    notin: <http://www.openmath.org/cd/set1#notin>
  }

  !mml:bind [om:quant1:exists, x,
    !mml:bind [om:quant1:forall, y,
      !mml:apply [notin, y, x]
    ]
  ]

would be equivalent to the example above (axiom of the empty set).

In this sense, the @let directive combines both (&, *) anchor notations 
in YAML, and the %TAG directive at the same time. It also provides a way 
to define XML and RDF namespaces. XML namespaces are tricky, though, 
since the phrase 'm:apply' doesn't map to a URI, but a pair (mmlns, 
"apply"), so this does not encode XML namespaces exactly. However, since 
QName is a type, one could encode a QName as: "!qname [ns, local]". 
Also, each key in the first (and only) parameter of @let (an object) 
would have to be a 'Name' in order for @let to work properly.

In these examples, all the tags after '!' have been URIs, but they could 
just have easily been Names, for example, if a DSON processor is also an 
OpenMath/MathML processor, then !bind can be assumed to mean the obvious 
thing, just as !apply can be assumed to mean the obvious as well. 
Perhaps there could be some default bindings, or something, so that some 
prefixes can be omitted if defaults are used. For example, one could 
require that there is an implicit directive before every DSON file:

  @let {
    null:  <tag:yaml.org,2002:null>,
    true:  <http://www.openmath.org/cd/logic1#true>,
    false: <http://www.openmath.org/cd/logic1#false>
  }

or the like, to ensure that these three symbols are not redefined by 
further @let directives.

Overall, it seems to be quite an expressive format for having such a 
modest extension to JSON, but all the URIs might be a little much. In 
hindsight, a similar purpose could be achieved without 'Symbol's at all, 
making typed/tagged values reduce to

  '!' String Value

which would _still_ be incompatible with YAML. I suppose what I'm asking 
is: does anyone have any recommendations on how to use YAML for these 
purposes, or any ideas how to make DSON as compatible as possible with YAML?

Regards,

Andrew Robbins

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev