[FR-devel] Latest YAML format (final round...really ;-)

[Rich Kilmer]

I am just going to reply to all the YAML/XML replies to date here...

> -----Original Message-----
> From: address@hidden 
> [mailto:address@hidden On Behalf Of Robert Hicks
> Sent: Saturday, November 09, 2002 10:48 AM
> To: address@hidden
> Subject: Re: [FR-devel] Latest YAML format
> 
> 
> I have not really been involved up to this point but this 
> would be my thoughts coming from someone that is learning 
> Ruby. I would be more inclined towards the XML spec for these reasons:
> 
> #01 XML is an industry standard and you will probably find 
> many more people that could grok it over YAML.

While XML (as in elements/attributes/values) are a standard, the
specific element names, and attribute ids, and nesting of elements, and
values are specific to our application.  This is a learning curve for
someone regardless of whether its XML or YAML.  The key difference I see
it that with YAML you don't directly use a parser (like in XML) to
navigate the elements/attributes/values. Instead, it builds you objects
(with properly set values by type like Time objects, Integers, Floats,
Booleans, Strings, and other objects).  YAML is more of an object
serialization format than XML is...which is more of a data format.  The
cool thing is that it's a textual serialization format as opposed to say
Java's binary format.  I did not actually write any YAML...I built a
class named PluginConfiguration and once its values are set I call
"to_yaml" and it returns a YAML string...then I perform
YAML.load(...yaml string...) and it returns a constructed
PluginConfiguration object.

> 
> #02 I, being a novice programmer, would be more inclined to 
> do something with XML because I can use that knowledge in 
> other programming areas.

We are talking about 5-8 lines of XML/YAML per plugin and this will
likely be generated through a Plugin Manager FreeRIDE plugin.  If you
start developing for FreeRIDE you will find that our architecture makes
use of very cool Ruby capabilities which will not transfer to other
languages (although they are incredibly great!)

> 
> #03 I agree with Laurent, we need to set "some" things in 
> stone and build upon that. I don't think we should changed 
> from XML to YAML because of this.

I agree...but I will also say that Ruby is very good at enabling
continuous refactoring.  We need to set the core in stone(ish) quite
soon to allow others to begin plugin work.  I am working on that right
now.

> 
> #04 I also agree with Laurent and will phrase it this way. I 
> know because XML is an industry standard that XML will always 
> be improved upon in Ruby and we cannot say that about YAML

We have no more assurance that the particular Ruby XML parser we use
(REXML in this instance) will be under continued development any more
that the YAML library (but Why...YAML4Ruby's author is now on our list
;-)  I do understand that XML is a standard but we use a trivial amount
from that standard.

> 
> So there are some thoughts I have had in the reading of your 
> posts. I guess my "vote" would be stick with XML.  : )
> 
> Bob

Thanks for contributing...really...I thank everyone.  Since this is
trivial either way I would like one more round on replies to this email
based on my explanations (if folks would not mind).

What I want folks to keep in mind is software elegance...not just "the
industry standard".  We want FreeRIDE be awesome...not just "me too" at
every level. Again, this change is no big deal from a code perspective,
but it will become an instrastructure tool that we use in other areas.
The question is should that infrastructure be based on Ruby
classes/objects that serialize to text (YAML) or XML.

-Rich