From: why the lucky stiff <ruby-talk@...>
Date: 2002-11-03T00:20:02+09:00
Subject: YAML/XML Comparison (was Re: Ruby.bah!)

NAKAMURA, Hiroshi (nahi@keynauts.com) wrote:
> Though I scanned YAML spec only once, YAML spec includes
> functions which are equivalent for XML, XML Namespace(sort-of),
> SAX(stream model), DOM(tree model), XML Schema Datatypes
> Part2(build-in types), and SOAP Encoding(Collection and Mapping).
> Users can get big benefit of many functions from YAML
> without knowing detail of above specs.

I think so, too.

> I know YAML can serialize heavy-complexed such as map in map
> in array in ..., including multi-ref object.  But editing a
> YAML-serialized text of heavy-complexed object is as difficult
> as editing one of XML-serialize, I think.  We need special
> viewer/editor to add a node, cut-and-paste a text, etc.
> As for this point, XML has an advantage for now.

Yes, great point.  Last night at RubyConf someone mentioned this
as well.  (The viewer/editor idea.)  Basically, all we really need
is a viewer/editor for Ruby data structures.  Then, load from YAML
documents or dump to.  Might even be useful for editing Ruby objects
serialized with Marshall.

> Again, I completely agree with YAML is suitable for not
> complexed object serialization, such as configuration files,
> lightweight messaging.  And within scripting language world,
> users doesn't often care its type system. (Without explicit
> type declaration, YAML serialized text is much smarter.)

We're in the process of making the type system more flexible.
Actually, it's not so much a change in the type system, but a change
in what happens at the Parser level and what happens at the Loader
level.  Because if some users simply won't benefit from the typing,
then let's not waste their time trying to figure out typing.  Expose
an earlier representation of the objects for them to access.  Of
course, you don't get the same quality of serialization at this
level, but some developers can afford that.

_why