[Yaml-core] on type families and formalism

[Clark C . E. <cc...@cl...>]

Oren,

  I've found that the type family notion doesn't
  really help us much.  Let's drop this concept
  and instead call it the "description" of 
  the transfer method.  Of course, the description
  will be talk of the type family... 

  But I don't think we're going to get into
  a formal definition of type families... unless
  we pull out the big boys.... like RFC Walters
  (Categories and Computer Science), etc.  And
  I think this is going a bit far.

  And I think we're complicated enough... I
  think we can safely drop this distinction
  and keep it informal.

Brian,

  For the places where I do "formal stuff",
  I'll put a translation right before it
  followed by the word "Formally, ..."
  where upon the dis-interested reader
  can skip this part if they understand
  the informal description.

  Overall, there are a few hard concepts
  in the information model:

   1. Unlike mathematics, we have two 
      ways that nodes can be equivalent, 
      by pointer (identity) or by 
      value (equality).

   2. A collection is simply your garden
      variety 7th grade pre-algebra 
      function (aka mapping), with a 
      domain (the keys) and a range 
      (the values).  Nothing fancy, but
      nailing down this definition is
      rather key (we could reference it
      instead... but this would increase
      the third party documentation
      dependency).

   3. Equivalence of collections is not 
      simple.  Informally, you can think
      of this as having paris that are
      equal... but it's very hard to
      express without diving into 
      the formalism (otherwise you are
      either too vague or omit cases
      that can be troublesome)

   4. Our constraint on documents being
      disjoint is also not simple....
      it's easy to visualize, but 
      much harder to write down on paper!
   
   In short, I don't think we can do
   away with the formalism that I've 
   put together, without something
   equally as formal.

All,

I've thought about the three model system
and dumped it in favor of a single
"information model" plus two mixins:

  1. A "syntax" mix-in which handles
     attributes added to the information
     model relating to syntax

  2. A "serial" mix-in which handles
     modifications to the model so
     that the graph can be flattened
     into a tree.

Best,

Clark