Re: [Caml-list] Re: Serialisation of PXP DTDs

[Mauricio Fernandez <mfp@acm.org>]

On Sat, Oct 25, 2008 at 12:27:08AM +0200, Mikkel Fahnøe Jørgensen wrote:
> > serialization too. My protocol family is both substantially simpler and better
> > adapted for extensibility. For example, the generic pretty-printer (able to
> > decode any message) takes ~40 lines of code.
> >
> 
> I see - somehow it reminds me of stackish - kind of S expressions
> backwards I guess - apparently with good performance, but also tag'ed
> I reckon.
> 
> http://www.zedshaw.com/essays/stackish_xml_alternative.html

heh, I read about Stackish a while ago (a few years?). 
Besides being human-readable, Stackish uses tags in a different way.
Whereas Stackish uses tags for the node names (behaving like Google's Protocol
Buffers or Facebook's Thrift in this regard), in my design tags are like
OCaml's: a way to encode different constructors for a given field.

For instance, if you have a field 
   ...
   length : float  
   ...
and latter decide that a mere float is not enough, and it should be actually

    type len = Cm of float | Inch of float
      
      ...
      length : float
      ...
my system assigns a tag to each constructor, the way OCaml does (the original
type definition carries a default tag which corresponds to the Cm
constructor). AFAICS this can only be encoded in a roundabout way in Stackish,
since it doesn't have sum types.

> More specifically regarding DTD's:
> Since I have been playing around with Ragel: http://www.complang.org/ragel/
> I was also wondering about converting DTD's to state-machines with a
> stack, then feed them to a Ragel input file and have Ragel produce a
> table that can be run by a small interpreter.
> I did something similar for an XML parser as a kind of DTD
> replacement, although I manually wrote the state-machines and compiled
> to C, not a table.
> For OCaml you would link in the C interpreter, or rewrite it in OCaml.

Turning each data schema into a state-machine sounds like a fair amount of
work. What I was looking for and ended up implementing is similar in spirit
to bin-prot's "with bin_io" extension, with the difference that the type is
specified using a language-independent abstract syntax instead of OCaml's type
language, and that the wire format is designed to allow extensions happening
in both producers and consumers non-atomically. 

-- 
Mauricio Fernandez  -   http://eigenclass.org