OT: XML too hard (YAML opportunity?)

ruby-talk
1

On /. today there is a discussion about a weblog entry by an XML
co-creator about how XML is ‘irritating, time-consuming, and error-prone’.

Seems to me that the Ruby community has adopted YAML (http://www.yaml.org)
more quickly than many other programming communities, which is why I’m
posting this here (I suppose it’s because we tend to be early adopters,
but that’s a tangent). It also seems to me that YAML solves a
lot of these XML problems. Anyway, this seems like a good opportunity for
YAML.

Phil

2

Seems to me that the Ruby community has adopted YAML
(http://www.yaml.org) more quickly than many other programming
communities, which is why I’m posting this here (I suppose it’s
because we tend to be early adopters, but that’s a tangent). It
also seems to me that YAML solves a lot of these XML problems.
Anyway, this seems like a good opportunity for YAML.

There are three overlapping and yet somewhat distinct user communities
of XML. Data-heads (see XML as “structured data”), Doc-heads (see
XML as “better SGML”), and Web-heads (see XML as “the next HTML”).

YAML will certainly appease the data-heads. But it’ll do nothing
for doc-heads or web-heads.

···

–
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
merlyn@stonehenge.com URL:http://www.stonehenge.com/merlyn/
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

3

On /. today there is a discussion about a weblog entry by an XML
co-creator about how XML is ‘irritating, time-consuming, and error-prone’.
XML Co-Creator says XML Is Too Hard For Programmers - Slashdot

What I got from Bray’s blog entry was that XML programming was hard for certain developers using certain languages. The problems
seems to be the language and what APIs it offers, not XML per se. XML programming hard for Java developers? Wow. Who’da thunk?

Seems to me that the Ruby community has adopted YAML (http://www.yaml.org)
more quickly than many other programming communities, which is why I’m
posting this here (I suppose it’s because we tend to be early adopters,
but that’s a tangent). It also seems to me that YAML solves a
lot of these XML problems. Anyway, this seems like a good opportunity for
YAML.

Odd you see this as an opportunity for YAML; I see this as an opportunity for Ruby.

Ruby makes XML programming is really easy, in large part thanks to REXML, but also because of the dynamic typing and clean OO design
of Ruby.

(It would be killer if Ruby also supported more standard XML APIs as well, but then Ruby would overtake all other languages and be
destroyed by its own success :slight_smile: )

At the end of Bray’s blog entry he mentions that his list of languages (it did not include Ruby, which I suspect it knows little
about) need better support for XML stream processing.

REXML offers that in a nice API.

YAML has its place, though personally I haven’t had a need for a statically-typed markup language (and I admit I still haven’t
managed to finish reading the spec). But it can’t (so far, at least) stand in for XML; comparisons between the two are apples and
oranges.

I’m puzzled, too, by claims of large YAML popularity in the Ruby community.
There appears to be a core group here that make regular posts on YAML, and of course anytime the string “XML” appears in a message a
mailbot sends an autopost follow-up message urging the use of YAML. :wink: But beyond that, I don’t know.

Just to make another apples-to-oranges comparison, there are a good number of Ruby apps/libs that use XML in some way:

http://www.rubyxml.com/raa/details.html (somewhat out of date, so take with a grain of salt.)

Any idea what number of apps or libs use YAML?

Do such comparisons mean anything?

James

···

Phil

4

Have you seen YOD?

I think many people underestimate the flexibility of the yaml type system. As
the project grows and becomes more stable, I see a lot of possibilities in
arenas other than data serialization.

···

On Tuesday 18 March 2003 04:12 pm, Randal L. Schwartz wrote:

… it’ll do nothing| for doc-heads …

–
author: Bruce R. Williams
url: http://codedbliss.com
irc: { nick: iusris, channel: [ruby-lang, yaml], server: irc.freenode.net }
quote: >
It does not require a majority to prevail, but rather an irate,
tireless minority keen to set brush fires in people’s minds.’
– Samuel Adams

5

I’m puzzled, too, by claims of large YAML popularity in the Ruby
community.
There appears to be a core group here that make regular posts on YAML, and
of
course anytime the string “XML” appears in a message a
mailbot sends an autopost follow-up message urging the use of YAML. :wink:
But beyond
that, I don’t know.

Heh… you are so cynical.

I’m just playing YAML’s advocate here… :slight_smile:
even though I’ve never used it.

It’s not just the mysterious whytheluckystiff
who posts about YAML. There’s a small but loyal
sub-community here who apparently use it and
love it.

The only example I can/will give is Rich Kilmer,
who is a YAML enthusiast (and who impresses me
with his technical ability). He, of course, is
the reason FreeRIDE uses YAML.

Of course, there are probably even more fans of
REXML. And you are probably correct in saying
that XML and YAML are not totally comparable.
post seemed on-target to me.

Cheers,
Hal

···

----- Original Message -----
From: jbritt@ruby-doc.org
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Tuesday, March 18, 2003 9:48 PM
Subject: Re: XML too hard (YAML opportunity?)

From my limited knowledge of XML, Randal Schwartz’s

6

This is the YAML advocacy mailbot at host codedbliss.com.

I’m sorry to have to inform you that the message you submitted
to ruby-talk did not meet XML frustration standards.

For further assistance, please send mail to the small
group of YAML supporters within the Ruby community.
If you do so, please include this problem report.

The YAML advocacy mailbot
···

(all in good fun)

Now, seriously…

I totally see what you are getting at-- and I agree with the
’apples-and-oranges’ comparison for the most part.

I also recognize that a person’s choice of markup formats is mostly matter of
taste. Although I’ve used XML for years, I prefer YAML for the vast majority
of projects I work on internally (one of which has a $300,000 budget) because
it is less hassle than XML (using a SAX/DOM parser to turn documents into
usable data)-- but also simply because I like it.

This, of course, is the same reason why I use Ruby. If I cared a great deal
about interoperability (at the current time) I suppose I’d use Perl (esp in
my work environment).

I love the idea of a common standard-- ie: XML. At the same time however, I
don’t mind using something else when I feel it’s a more elegant approach for
the project I’m handling. The fact that YAML is used in very few public
apps/libs (FreeRide, tomslib) right now doesn’t matter to me. Perhaps this
is a failing.

// Bruce

–
author: Bruce R. Williams
url: http://codedbliss.com
irc: { nick: iusris, channel: [ruby-lang,yaml], server: irc.freenode.net }
quote: >
It does not require a majority to prevail, but rather an irate,
tireless minority keen to set brush fires in people’s minds.’
– Samuel Adams

7

jbritt@ruby-doc.org wrote:

YAML has its place, though personally I haven’t had a need for a statically-typed markup language (and I admit I still haven’t
managed to finish reading the spec). But it can’t (so far, at least) stand in for XML; comparisons between the two are apples and
oranges.

What does statically typed mean here?

What I would say (probably out of ignorance) is that XML is semantically
neutral and YAML is semantically stong. In YAML, it’s possible to say
something about what the symbols of the language represent (this is an
array, that is a hash, this refers to that, etc.), but in XML you must
supply that information separately. Of course you still have to do that
with YAML: if your YAML has a user-defined object, the class of that
object better be defined when you load. But there’s this base layer of
semantics in YAML that’s very close to the way programmers (esp. VHLL
programmers) think about data. There are other ways of thinking about
data, so maybe that’s where XML can be valuable… Oh, well, it’s
probably been said.

8

But beyond

that, I don’t know.

Heh… you are so cynical.

I don’t think it’s cynicism. I’m genuinely curious to know the
extent of YAML’s popularity here.

I’m just playing YAML’s advocate here… :slight_smile:
even though I’ve never used it.

It’s not just the mysterious whytheluckystiff
who posts about YAML. There’s a small but loyal
sub-community here who apparently use it and
love it.

I would urge that community to go here:

The only example I can/will give is Rich Kilmer,
who is a YAML enthusiast (and who impresses me
with his technical ability). He, of course, is
the reason FreeRIDE uses YAML.

Yes, I know, and YAML is perhaps better for config files where
name=value is too weak and XML is overkill.

(BTW, does YAML support external entities?)

Of course, there are probably even more fans of
REXML. And you are probably correct in saying
that XML and YAML are not totally comparable.

From my limited knowledge of XML, Randal Schwartz’s
post seemed on-target to me.

Randal was quite correct.

James

···

Cheers,
Hal

9

I mean the data carries with it instructions on how it is to be processed.
It says “Process me as a String,” or, “Process me as a Hash.”

I don’t usually want that in my data files. It tends towards application
logic.

James

···

jbritt@ruby-doc.org wrote:

YAML has its place, though personally I haven’t had a need for
a statically-typed markup language (and I admit I still haven’t
managed to finish reading the spec). But it can’t (so far, at
least) stand in for XML; comparisons between the two are apples and
oranges.

What does statically typed mean here?

10

I got this weird sense that people were talking about me…and here you
are!

First, YAML and XML are different.

XML is a format for writing data, YAML is format for serializing
language objects. That is different. If I wanted to take a series of
Ruby objects and write out an XML file that contained their attributes
I would write emitter code (possibly as methods on the object
‘to_xml’…possibly as a separate method/class), and parser code to
read them in and construct instances. If my Ruby model changed, I
would keep the emitters/parsers updated. A bit of a pain to be sure.

With YAML, I write Ruby code (but no emitters and parsers). I craft my
objects a bit with YAML (with to_yaml_properites, etc) but that is
really for attribute order/readability…but nothing like XML. And
YAML is compact, yet readable (and simply editable). The configuration
files of FreeRIDE used to contain only string values because it was
XML…we could have supported a “type” attribute, but you would still
have been limited. 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.
Oh, and did I say that YAML files are readable?

Here is a simple FreeRIDE plugin configuration file:

— !ruby/object:FreeBASE::PluginConfiguration
name: rubyide_util_logger
version: 1.0
autoload: true
require_path: freebase/logger
startup_module: FreeBASE::Plugins::Logger

That’s it…YAML parses that and creates a PluginConfiguration object
for me. Simple. Oh, and version is a float, autoload is a boolean,
etc, etc.

BTW: I use XML quite a bit too, I am just stating a bit of the case
for YAML’s value.

-rich

···

On Tuesday, March 18, 2003, at 11:35 PM, jbritt@ruby-doc.org wrote:

The only example I can/will give is Rich Kilmer,
who is a YAML enthusiast (and who impresses me
with his technical ability). He, of course, is
the reason FreeRIDE uses YAML.

Yes, I know, and YAML is perhaps better for config files where
name=value is too weak and XML is overkill.

(BTW, does YAML support external entities?)

11

jbritt@ruby-doc.org wrote:

YAML has its place, though personally I haven’t had a need for

a statically-typed markup language (and I admit I still haven’t

managed to finish reading the spec). But it can’t (so far, at

least) stand in for XML; comparisons between the two are apples and

oranges.

What does statically typed mean here?

I mean the data carries with it instructions on how it is to be processed.
It says “Process me as a String,” or, “Process me as a Hash.”

Funny, that’s almost exactly how I would define dynamically typed.
“Instructions on how the data is to be processed” are carried with the
data in dynamically typed languages. In statically typed languages they
are carried with the variable that refers to the data.

It sounds like you would say that Ruby is statically typed because
whenever you introduce a new object, you have to say what class it is.
But then C is dynamically typed because you can take an arbitrary byte
string and cast it however you want!

But whatever we call it, separating application logic from data can be a
good idea, as you say.

···

jbritt@ruby-doc.org wrote:

12

So the fact is the parser of YAML infers (through rules) the types of
the elements it parses is bad from your perspective? The issue is
SOMETHING has to know this. Its either written in some parser function
and mapped (from XML) into your internal object structure, or read in
directly from YAML. As we did with FreeRIDE, the classes that are
serialized to YAML are, in fact, utility classes that YAML is
serializing for us. We just maintain those files (in Ruby). This is
far better than writing an emitter/parser pair for an XML format. I get
to code in my language…and don’t worry about the data format.

Think of it this way:

class Person
attr_accessor :firstname, :lastname
end

p = Person.new
p.firstname = “Richard”
p.lastname = “Kilmer”

=== Output ===

XML:
#BUILD EMITTER
class Person
def to_xml
“”
end
end

xml = person.to_xml
puts xml

YAML:
yaml = person.to_yaml
puts yaml
— !ruby/object:Person
firstname: Richard
lastname: Kilmer

=== Input ===

XML:

BUILD PARSER

class Person
def Person.from_xml(xml)
doc = REXML::Document.new(xml)
p = Person.new
p.firstname = doc.root.attribute[‘firstname’]
p.lastname = doc.root.attribute[‘lastname’]
return p
end
end
p = Person.from_xml(xml)

YAML:
p = YAML.load(yaml)

…

And now, add some new properties:

class Person
attr_accessor :firstname, :lastname, :middle, :age, :hair_color,
:eye_color
end

Here is what you do with YAML:

p = Person.new
p.firstname = “Richard”
p.lastname = "Kilmer
p.hair_color = “Brown”
yaml = p.to_yaml

p2 = YAML.load(yaml)

In XML we have to update our emitter and parser.

…

-rich

···

On Wednesday, March 19, 2003, at 01:27 AM, jbritt@ruby-doc.org wrote:

jbritt@ruby-doc.org wrote:

YAML has its place, though personally I haven’t had a need for
a statically-typed markup language (and I admit I still haven’t
managed to finish reading the spec). But it can’t (so far, at
least) stand in for XML; comparisons between the two are apples and
oranges.

What does statically typed mean here?

I mean the data carries with it instructions on how it is to be
processed.
It says “Process me as a String,” or, “Process me as a Hash.”

I don’t usually want that in my data files. It tends towards
application
logic.

13

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?

Oh, and did I say that YAML files are readable?

You did, but I’m not always seeing that when I read the YAML spec.

James

14

Think of it this way:

class Person
attr_accessor :firstname, :lastname
end

<< snip example >>

What this example highlights is that XML and YAML sit at two different
levels (shame there isn’t an ISO 7-layer model for discussing object
serialisation :slight_smile:

XML is a way of presenting structured data or marked-up text, and because it
doesn’t specify how to handle that data, you have to define the semantics
for yourself. YAML’s application domain is serialisation of arbitary
objects, and it has strongly defined semantics for that.

You can get the same or similar semantics with XML, by putting another layer
on top of it. One way is SOAP, which gives application code almost identical
to the YAML example:

=== Output ===

SOAP:
require ‘soap/marshal’
soap = SOAP::Marshal.dump(p)
puts soap

<?xml version="1.0" encoding="us-ascii" ?>

<env:Envelope xmlns:xsd=“XML Schema” xmlns:env=“http://schemas.xmlsoap.org/soap/envelope/” xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”>
env:Body

Richard
Kilmer

</env:Body>
</env:Envelope>

=== Input ===

SOAP:
p = SOAP::Marshal.load(soap)

The output of this program is XML, but it’s more than that: it’s
SOAP-over-XML. It’s also ugly, but trivial examples like these always look
bad in SOAP, because of the overhead of setting up XML namespaces. The
advantage of this is that your SOAP/XML document is unambiguous, even when
sat alongside other random XML documents and SOAP objects from different
sources.

In fact, according to the YAML home page, the YAML people have defined a
standard for putting YAML serialisation semantics over XML: YAXML. I’ve not
seen any implementation of that though.

So, with XML, you have to define your own emitters and receivers for each
class. With SOAP/YAML/YAXML, they provide a higher-level abstraction which
is an emitter and receiver for all object classes. I think the latter sits
very nicely with Ruby’s dynamic typing. They work at the same level as
Ruby’s Marshal, which marshals arbitary objects directly to its own binary
string representation. If you want to store an object or collection of
objects persistently then these solutions all work well.

Incidentally, once you’ve got object serialisation, then another nice layer
to stick on top of that is RPC. SOAP has this defined as part of the spec;
YAML has OKAY; Marshal has DRuby.

I think hand-editing is something of a side issue. If your requirement is
for config files then you can hand-edit the internal representation of a
serialised object, but in many cases there is a Better Way for a particular
application. Since many config files are just key=value pairs then YAML’s
representation of a hash shows them quite neatly, but I’m not sure I’d want
to write a YAML object from scratch for anything more complicated - get the
number of spaces wrong at the start of a line and you end up with an
unparseable object. Having some sort of start/end markers for a block of
related parameters seems more friendly to me. Whether that’s curly brackets
(like dhcpd.conf) or … I don’t really care. In complex
configuration files none of these are appropriate. Would you want to
hand-edit sendmail.cf or an exim configure file as XML? I don’t think so.
(OK, so sendmail.cf is not a good example of how configuration files ought
to be :slight_smile:

Hand-editing gives you the possibility of recovering from certain forms of
data corruption, perhaps. But there are other issues which may be of greater
importance, such as interoperability. If you want to do RPC over the
Internet you’ll find a whole load of sites using SOAP, but few using
YAML/OKAY (which hasn’t even got a stable standard yet, from what I hear).
And potentially your SOAP object could be processed with a whole load of
other XML-based tools, none of which I’m familiar with. But in principle I
think you could use XST to pre-validate an object received from an untrusted
source over the Internet, for example, before deserialising it into your
application. The security benefits of that could be important: like a
firewall for objects.

Regards,

Brian.

···

On Wed, Mar 19, 2003 at 04:01:53PM +0900, Richard Kilmer wrote:

15

Hi,

From: Richard Kilmer
Sent: Wednesday, March 19, 2003 4:02 PM

[snipped great examples; Reading ruby code is much
easier than reading English sentence, at least for me]

In XML we have to update our emitter and parser.

You are comparing XML and YAML here. But as I wrote
in [ruby-talk:54657] [1] and yamlrb author _why kind agreed
in [ruby-talk:54697] [2], YAML spec includes more than
XML spec defines.

Excerpted from [ruby-talk:54657]
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.

And your example of YAML;

=== Output ===

YAML:
yaml = person.to_yaml
puts yaml
— !ruby/object:Person
firstname: Richard
lastname: Kilmer

also includes YAML’s Ruby mapping (!ruby/object:… part.)

It’s to be expected that yamlrb(YAML + Ruby language mapping)
can do more without extentions. As Brian stated, we should
not compare (plain) XML vs YAML.

Comparing XML + some extentions vs YAML for data serialization,
I wrote my stance in [ruby-talk:54657] [1].

Regards,
// NaHi

[1] http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/54657
[2] http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/54697

(From [ruby-talk:54657])

Let’s ask the inverse question: Can XML easily step for YAML?
XML is squeezed
into many case where I believe it doesn’t suit as well.
Configuration files,
messaging, data serialization. YAML is engineered for these cases.

I agree, except data serialization. :slight_smile:
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.

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.)

For me, it’s a simple trade-off thing.

16

So the fact is the parser of YAML infers (through rules) the types of
the elements it parses is bad from your perspective?

In most of my use cases, yes. If I want typing info, it’s
easy enough to add when and where I want it. I prefer it
to be an option, not a requirement.

The issue is
SOMETHING has to know this. Its either written in some parser function
and mapped (from XML) into your internal object structure, or read in
directly from YAML.

Right. And in some cases this information is business logic.
This is less the case when serializing objects, where the type of the
object and its constituents are part of the metadata you’re concerned with.

As we did with FreeRIDE, the classes that are
serialized to YAML are, in fact, utility classes that YAML is
serializing for us. We just maintain those files (in Ruby). This is
far better than writing an emitter/parser pair for an XML format. I get
to code in my language…and don’t worry about the data format.

This may be the best thing for object serialization.

Think of it this way:

In XML we have to update our emitter and parser.

In your example, yes, and the same would be true for YAML if one
wrote custom YAML parser/emitter code for every case.

A better comparison might show the use of XmlSerialization or
SOAP4R to do the XML serialization.

In any event, it may be easier to do this sort of thing with YAML
in Ruby; I don’t really know. But that’s a different matter from
the merits of the actual markup.

James

···

-rich

17

[…]

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?

No. Why?

23 == 23.0

Just different classes. Ruby’s sufficiently flexible to not
really care too much in most circumstances.

cheers,

···

–
Iain.

18

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.

Ah…the key is that you do not design the data file…this is an XML
thing. The to_yaml method creates the format off your object model.

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?

Actually, what will happen is a Hash will be created with a key
(“some_key”) and the value(23). If you change to floats, the Hash will
have the key (“some_key”) and the value(23.0). It all depends on your
use of these objects as to whether this will fail. But this is the
same for XML too. If you have a parser that expects a certain format
in the value of an attribute like:

some_num=“23”

and then do:

some_num=“23.0”

you have to update your parser. If you update it, will it break with
old files? How long does your parser read the old format and convert
to the new?

Oh, and did I say that YAML files are readable?

You did, but I’m not always seeing that when I read the YAML spec.

And XML specs are readable???..I was talking about the YAML content,
not specification. The YAML library deals with the spec. I write Ruby
code and let it emit and parse it.

···

On Wednesday, March 19, 2003, at 01:02 AM, jbritt@ruby-doc.org wrote:

19

Oops, showing my ignorance - I meant XML Schema, or any of the menagerie of
similar XML-validating things. But I think the point stands.

···

On Wed, Mar 19, 2003 at 09:42:51AM +0000, Brian Candler wrote:

But in principle I
think you could use XST to pre-validate an object received from an untrusted
source over the Internet

20

jbritt@ruby-doc.org 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 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 < ture@plig.net >