[Yaml-core] Re: YAML

[Brian I. <in...@tt...>]

John, I'm cc'ing our mailing list in case they have anything interesting to
add. The other guys are much more intimate with XML issues than I am. I'm
more just into this thing for the serialization end of things.

(John is my old college buddy, a bona fide genius and a cool guy.)

On 12/08/02 15:17 -0500, John Winans wrote:
> Quoting Brian Ingerson <in...@tt...>:
> 
> > On 12/08/02 07:18 -0500, jo...@wi... wrote:
> > > 
> > > >With XML you have to invent your own native in-memory
> > > >representation. If you're doing everything in C, C++, Java etc,
> > > >you'll need to do that anyway. XML has a lot of tools for parsing
> > > >and processing, but they all have to invent there own fluky ways
> > > >of storing data, and then you're stuck with that model.
> > > 
> > > This is true and yah, I am a C guy, so I have to buy into the in-core
> > > and external views anyway.
> 
> 
> I am STILL tropubled by this whole thing. It seems to me that what you
> have is a simplification of what XML provides... which in turn is a
> simplification of what SGML does.

The information models of XML and YAML are totally different. You'd have to
simplify both XML and YAML to come up with a reasonable cross section. As far
as I can tell SGML/XML never had a real information model. They just had to
graft one on in the forms of DOM and such.

YAML is designed from data model outwards. It start with associative arrays
(mappings), arrays (sequences) and scalar values. These are common in all the
modern day scripting languages, even crappy ones like Javascript. Then we add
a simple but extensible typing system and an aliasing mechanism and viola!,
we can serialize almost anything.

The other two design goals are to make it as human readable (actually *nice*
to read) and easily parsable as possible. Now you have a language that really
excels for things like config files, logs, messaging and especially
debugging.

XML isn't bad as a "binary" format for storing textual data. But when you try
to apply it everywhere, it starts showing its suckiness fast. One thing YAML
gets right where XML fails miserably (at least from a readability standpoint)
is embedding like-content. XML/SGML embedded in XML looks like shite. YAML
in YAML looks just like YAML :)

> 
> I thinks SGML is a shit-mess for a parser to have to deal with and that XML 
> helps things to some extent.
> 
> I also think that most of the XML parsers I have seen are bloated shit-piles.
> 
> I also think, however, that Java's use of XML for serialization is not a bad 
> approach and that one could write a reasonably light weight parser for a 
> serialization language in PERL.

There are no end of Perl parsers and tools for XML. There are tons. The
problem is that you have to buy into XML APIs in the first place. You lose
simplicity and speed. 

Perl is an order of magnitude improvement over C. I'm talking ease of
programming. There is so much less to think about. The builtin data types are
simple malleable and extendable. That's why using something as heavyweight as
XML (should) causes a gag reflex to the average Perl programmer.

XML as a general serialization language for Perl would simply be a nightmare.
The only time it is reasonable is when you are dealing with very simple data.
YAML does the hard edge cases with relative elegance.

> 
> My motivation for thinking in XML terms is that the serialized data copuld be 
> more easily shared and stored in XML-aware storage and comminication systems.

XML is useful when you need to talk to another system that uses XML. And that
(unfortunately) is the all too common case these days. Everybody is on the
silly XML bandwagon.

> Maybe YAML addresses application types that are not intended to be
> used in the types of environment that I tend to gravitate towards.

Doubt it. But if you're not coming from a scripting langauge point of mind,
it's a harder sell.

Cheers, Brian

BTW, I don't know how much you've poked around yaml.org, but at least take a
look at the examples section of the spec. It's fairly helpful.