[sdumi]

I'm not sure I understand his example:

    “I need to configure this server and the server needs to know if this value is true or false.”
    No, that’s bad. Don’t do that. That’s not a good use for XML.

But on the other hand, if you need to mark something bold, then XML is a great choice.

I see both cases as being quite equivalent: whether the server needs to know that a value is true/false or that it needs to display something as bold feels quite the same thing, isn't it?

Or does he mean that you cannot easily retrieve the value of an arbitrary XML element? Whereas to display a document you just process it sequentially and do not need to 'retrieve' arbitrary data. Is this it?

[TRiG_Ireland]

I think I'm with the author on this. The two scenarios are very different. Bold text is probably a span of text within a larger block of text: delimiting it with an opening and closing tag makes sense. A config value is a boolean switch.

This makes sense:

    <element>Some text here. <bold>Some more text here.</bold> And yet further text here.</element>

This does not:

    <value>true</value>

That should be:

    value: true

[stvltvs]

A better XML encoding would be the following, optimally with a schema that would define allowed values.

    <setting name="foo" value="true"/>

[TRiG_Ireland]

That still feels ugly and verbose to me.

[stvltvs]

I don't disagree, but it's easier to rigorously validate than lighter-weight markup languages, if that's important to the use case.

[gilcot]

It's only a construction to justify author's biases.

[earthboundkid]

Literally every article is that. What’s your point?

[gilcot]

Oh, I was only saying that the article isn't saying that you cannot easily retrieve the value of an arbitrary XML element. It simply putting together selected examples that should deserve YAML and convince us that we must swear XML true.

Well, life isn't black and white, but somewhat greyscale. From my experience, none is better and they don't share the same use-cases.