Re: XML too hard (YAML opportunity?)

<[e-mail]> writes:

> > Now you can store anything in a configuration file,
> > which is liberating.  That something is a boolean, string, integer,
> > array, hash or whatever...YAML deals with for me.  That is really nice.
> 
> But what if you don't want to couple your data to a particular
> language type?
> 
> Suppose I write a YAML file to hold, say, groups of name=value
> pairs.  My understanding is that I have to decide, when designing
> the data file, whether each group is to be a hash, or a list, or
> some other type.  My application code will then be expecting to deal
> with data arriving as this type.
> 
> If, later, I decide that DataTypeFoo was a poor choice and would
> rather my app process the data as DataTypeBar, I either have to
> change the config format or have an extra step in my app to change
> the data from one format to another. No?
> 
> For example, if I have
> 
>  some_num: 23
> 
> it's an integer.  If later I decide that floats are better and want
> change my code, don't the older data files have to be rewritten?

The problem is just as bad with XML and a statically typed language
(I'm assuming that we're talking about statically typed languages
here, since Ruby wouldn't have the problems you describe).  If you
decided to do it the other way around, and convert something that had
been a float in your XML files to an integer, a certain well-known
statically typed language would require that you change all your
existing config files.  eg.  Assuming you're expecting a float
somewhere in your code, you might have something like <foo
value="1.0"> in your XML, and parsing code like this:


float f = Float.parseFloat(fooValue);

which you then decide change to:

int i = Integer.parseInt(fooValue);


For all the old XML files you'll suddenly find yourself with
NumberFormatExceptions all over the place.  In other words, the
semantics were still implicit in the XML file, and yet you were still
required to manually implement the semantics you required.  Worst of
both worlds.

-- 
Mark Hulme-Jones < [e-mail] >