OSDev.org

mystran wrote:Besides, while I'd be perfectly happy to have everything as S-expressions (or pretty much anything else just as well), many people seem to think that XML looks less frightening (which ofcourse is totally irrelevant when you exchange data between two programs, but such is life).

OTOH, compared to something like NeXTStep Property Lists, not to mention a dozen other standardized formats, XML is incredibly frightening and difficult to read. If human readability/editability is the concern, XML is definately not the way to go.

I've voted for consistency as well.

IMHO there's nothing worse than finding that functions don't work in a similar format (within reason).

I find it much easier to pick up, learning what functions are there is bad enough, bit also having to learn the individual format of every function would be a nightmare.

It also adds to simplicity because it doesn't matter how many functions there are, they all work in a similar way. This leads to less nasty surprises, it also makes the API designers job easier as well.

srg

Dreamsmith wrote:

mystran wrote:Besides, while I'd be perfectly happy to have everything as S-expressions (or pretty much anything else just as well), many people seem to think that XML looks less frightening (which ofcourse is totally irrelevant when you exchange data between two programs, but such is life).

Ah, until the moment comes where you have to debug a potential protocol problem... (I am exactly in that position ATM, and if it turns out we have a bug that forces us to update our customer's clients, we will go SOAP as to never again having to fiddle with some self-"designed" binary protocol...)

OTOH, compared to something like NeXTStep Property Lists, not to mention a dozen other standardized formats, XML is incredibly frightening and difficult to read. If human readability/editability is the concern, XML is definately not the way to go.

Depends on how much of the XML to use. Of course, if you squeeze in namespaces, XPath and everything, it's difficult to read. But:
Isn't that hard, now is it?

Solar wrote:Isn't that hard, now is it?

No, but it could be a lot easier. Usually, when you come up with a portable and backwards compatible data expression format, you fight a couple of competing goals: easy to read and edit (by people) and easy to parse and generate (by machine). XML takes the innovative approach of making things more difficult to parse and generate while simultaneously making it more difficult to read and edit. (Yes, that's sarcasm.)

No, it's not as bad as it could be. It's not that hard. But why use it at all when there are so many better alternatives, regardless of your aim?

If it provided some benefit to offset this, that would be understandable. But the only benefit XML provides is ease of exchanging data with programmers who've fallen for the hype around XML. It's not best at anything, nor is it the best compromise between competing goals. If programmers were fully rational beings who implemented things based on their technical merits rather than hype, the XML spec would be sitting in a dustbin. The fact that more than a tiny segment of you reading this even know what XML is is a testament to the power of hype over reason in this industry.

That doesn't make it hard or useless. It's just suboptimal for any purpose.

just for the sake of goodsense, there are alternative to XML that can help you achieving the same basic goals (though maybe not the same hype-level) such as ASN.1 (used in SNMP), eXternal Data Representation (used in SunRPC), or bEncoding (used in python, bittorrent protocol)

There is another merit besides what you said, in which XML excels in the same way as C/C++ for programming languages, ZIP for archiving and HTML for documentation:

"Everybody" knows it.

I don't say there aren't better beasts out there than XML, C/C++, ZIP, and HTML. Yet still I embrace them, as it means least surprise.

I see your point, but unfortunately, we're not living in a perfect world...