Geeks With Blogs

News Locations of visitors to this page

Brian Genisio's House of Bilz

Part 2

This is the first in a many-part series in which I will be writing about using YAML in the .Net space – particularly within C#.  I will cover the whys, the hows, and show some tricks using the dynamic capabilities of C# when using YAML.  I might even explore IronRuby a bit.

Why YAML?

I got the chance to sit in on four days of Ruby on Rails (RoR) training from Joe Obrien a few weeks ago.  I hadn’t played with RoR in a few months, and this training was amazingly useful.  I always like to see what I can take away from an environment like this for the work I do more regularly.

In this case, one of the things I took away with me was YAML.  Let me start with some background.

Over 10 years ago, when XML was touted as a human-readable data format, I had to scoff.  Was XML really human readable?  Well, from a software developer’s perspective, it sure is a lot nicer than binary.  But, from a REAL human’s perspective, XML is just barely more readable than Klingon.  This is mostly due to the verbose nature of XML and the often ranted about “angle bracket tax”.   

10 years later, we are still using XML as our primary data transfer/persistence/definition format.  I certainly don’t mind using XML in a world where I (a human) rarely need to read the data.  I am fine with keeping the data in my REST services as XML, for instance.  In that case, my tools abstract it away and I don’t have to read it very often.

Currently, my colleague Mike Woelmer and I have a client who needs us to develop an engine where the business rules will be entered by a human (not a developer) and will change as the project evolves.  The data/rules will be set in stone once the project is complete.  XML is a bad choice for this, since a non-technical person will be entering the rules.  At the same time, developing a UI for this is too time consuming and out of the scope of the project.  My first thought: a Doman Specific Language (DSL)!  That would certainly lend well to my requirements.  As much as I liked that idea, I didn’t have time to create a DSL either, especially while spiking.  Then I remembered back to my RoR training.  I remembered a data format called YAML that they used for some of the configuration files.  It was a VERY easy-to-read, hierarchical data format.

To illustrate the difference between XML and YAML, here is a simple example of some rather easy-to-read XML defining the data for a recipe (unrelated to my current project):

<recipe>
  <title>Macaroni and Cheese</title>
  <description>My favorite comfort food.</description>
  <author>Brian Genisio</author>
  <timeToPrepare>30 Minutes</timeToPrepare>
  <ingredients>
    <ingredient>
      <name>Cheese</name>
      <quantity>3</quantity>
      <units>cups</units>
    </ingredient>
    <ingredient>
      <name>Macaroni</name>
      <quantity>16</quantity>
      <units>oz</units>
    </ingredient>
  </ingredients>
  <steps>
    <step>
      <number>1</number>
      <description>Cook the macaroni</description>
    <step>
    <step>
      <number>2</number>
      <description>Melt the cheese</description>
    </step>
    <step>
      <number>3</number>
      <description>Mix the cooked macaroni with the melted cheese</description>
    </step>
  </steps>
</recipe>

Here is the exact same data described with YAML:

Recipe:
  Title:         Macaroni and Cheese
  Description:   My favorite comfort food.
  Author:        Brian Genisio
  TimeToPrepare: 30 Minutes
  Ingredients:
    -
      Name:     Cheese
      Quantity: 3
      Units:    cups
    -
      Name:     Macaroni
      Quantity: 16
      Units:    oz
  Steps:
    -
      Number: 1
      Description: Cook the macaroni
    -
      Number: 2
      Description: Melt the cheese
    -
      Number: 3
      Description: Mix the cooked macaroni with the melted cheese

Although this is a very simple example, I would ask you: Which one would you rather present to a customer when talking about the data and business rules?  Which one would YOU rather look at when developing your software?

In my next couple of posts, I will discuss some tools available to you in the .Net space and some nifty C# 4.0 techniques for working with the data.

Posted on Sunday, February 21, 2010 6:32 AM | Back to top


Comments on this post: Goodbye XML… Hello YAML (part 1)

# re: Goodbye XML… Hello YAML (part 1)
Requesting Gravatar...
All those years ago when my programs were using ini files and not XML files people would condescendingly laugh at me. After all this time, ini is ressurected once again. I am vindicated :)
Left by Siderite on Feb 21, 2010 7:06 PM

# re: Goodbye XML… Hello YAML (part 1)
Requesting Gravatar...
@Siderite: Ha! Yeah, the readability of YAML certainly makes me think of INI files. Note that YAML is much more featured than INI. The primary difference is that you can have hierarchical data just like in XML. In fact, I am not sure there is anything that XML can do that YAML can't. Certainly any spec that I use regularly... It is just more readable, which is a huge plus in my book.
Left by Brian Genisio on Feb 21, 2010 11:52 PM

# re: Goodbye XML… Hello YAML (part 1)
Requesting Gravatar...
What about schemas? Could be useful for rule validation. Thanks for the article, interesting read.
Left by Markus Klems on Feb 22, 2010 8:22 PM

# re: Goodbye XML… Hello YAML (part 1)
Requesting Gravatar...
I havent used any of them, but some schema/validator options for YAML are Kwalify, Rx and YAXML
Left by Brian Genisio on Feb 22, 2010 10:40 PM

# re: Goodbye XML… Hello YAML (part 1)
Requesting Gravatar...
I would encourage you to take a look at JSON http://www.json.org/
Left by Arthur on Feb 25, 2010 1:33 PM

# re: Goodbye XML… Hello YAML (part 1)
Requesting Gravatar...
@Arthur: Yeah, JSON is pretty cool as well. It is certainly more readable than XML, but not quite as readable as YAML. JSON is really great when consuming the data from Javascript since the format IS javascript... but when it comes to anything else, you still need a parser, so I'd rather go to something like YAML when I get the chance.
Left by Brian Genisio on Feb 26, 2010 4:33 PM

# re: Goodbye XML… Hello YAML (part 1)
Requesting Gravatar...
YAML is a full 100% superset of JSON, so no reason to needlessly "downgrade" to JSON (although no harm either since you can always painlessly upgrade back to YAML). The big win for YAML over JSON is that YAML supports references, which JSON does not. Many-to-many relationships can be problematic in JSON but are easy in YAML.
Left by Ari on Mar 06, 2010 5:39 AM

# re: Goodbye XML… Hello YAML (part 1)
Requesting Gravatar...
The YAML Builder is a tool for visually creating YAML-based CSS layouts. It allows for the setting of basic layout characteristics like the number and positioning of the content columns, as well as the dynamic creation of grid-based layouts by dragging and dropping subtemplates.
Left by Bonus del casinò on Apr 09, 2010 11:51 PM

# re: Goodbye XML… Hello YAML (part 1)
Requesting Gravatar...
@Roboblob: Thats right! Take a look at "Part 2" of this, where I write a dynamic wrapper around an old-school parser. It helps a TON :)

Brian
Left by Brian Genisio on Jun 09, 2010 1:43 AM

Your comment:
 (will show your gravatar)


Copyright © Brian Genisio's House Of Bilz | Powered by: GeeksWithBlogs.net