On 25/08/02 21:39 +0200, Armin Roehrl wrote:
> How did you find out that about each other's work and finally
> team up?
From my perspective, YAML emerged from the work of SML-DEV; a group
of XML deviants (implementers and heavy users) who had grown tired
of the complexity of XML and its toolset. Over a year and a half
this group explored the core of XML searching for a simplified syntax,
or more importantly, a clean information model (recommendation for
using XML) for our XML based applications and tools. In this context
I met Oren. My respect for Oren grew daily as he not only took time
to tear apart proposals (even my stupid ones) but also found innovative
ways to put them back together.
This SML-DEV group came up with Common XML and Minimal XML, both successful
subsets of XML. But after that, it stalled. I think primarly beacuse
the group was heavily manned by people who depend upon XML for their
day job and could not explore options incompatible with XML. After 6
months with nothing new said and much wheel spinning, I decided to
part ways with the "pointy brackets". To my suprise (and delight)
Oren followed along.
Running into Brian was a pure accident. I very much dislike Perl, but knew
it was cryptic and I was looking for a symbol to represent hashes (@),
lists (@) and scalars ($) -- the core components of the "non-xml" information
model Oren and I had come up with. While looking to see if "everything"
in Perl fit into one of these three categories, I ran into Data::Denter.
One look at its syntax and I said... hey here is a fella that thinks like me.
As it turns out... I'm very lucky he doesn't think like me. I couldn't agree
more with Brian's characterization of the dynamics.
Right now YAML is facing its first real "popularization". People are
pushing YAML beyond its original scope -- serialization /w generic toolset.
Our current information model (formal description of how things work)
forbids key order and duplicate keys, even though a YAML synax shows
both and the YAML parser would allow both. These restrictions are
essential (as Oren and I learned in SML-DEV) to portability and to
very cleanly designed generic tools. So, we now have three options:
stay focused on serialization at the expense of those wishing to use
our syntax for other stuff, cast our generic toolset aside and primarly
be a serialization format, or try to ballence both concerns. We're
going to take the latter approach, but ballence won't be easy. It means
compromises from both camps. I would not be opting for the balence
if Brian and Oren were not with me side by side.