Amazing Demo Scene Guy (bit techy)

[bloid]

My major argument against XML is it's ludicrous entropy. It's hard to beat about 30% efficiency with it.

It compresses very well though.

[Dio]

That's still throwing CPU time after the problem, and adding in more modules you don't want or need. But, like I said, I don't understand the basic rationale, so I'm the wrong person to criticise.

[gravy]

What do you -think- the basic rationale is?

[Dio]

I get my head around the 'structured method for arbitrary hierarchical data' bit. What I don't understand is why this stuff is useful for things that aren't explicit, standardised protocols and therefore why people want to use it in internal code.

I've encountered a few things at work that take XML config or input files, and it seemed a total misuse to me - they were always harder to work with than an alternative text-based alternative (e.g. a classic INI file) would be.

[Mr Dom]

I get my head around the 'structured method for arbitrary hierarchical data' bit. What I don't understand is why this stuff is useful for things that aren't explicit, standardised protocols and therefore why people want to use it in internal code.

I've encountered a few things at work that take XML config or input files, and it seemed a total misuse to me - they were always harder to work with than an equivalent text file would be.

Because:
(1) human-readable config files are ace.
(2) XML as a defined standard covers most of the bases you need for extensibility & backwards compatability (i.e. open/close tags mean if you dont understand a tag skip to the close tag & forget about it, so newer versions of the config files are still readable by older versions of the code)
(3) there are already a LOT of tools that will generate/parse/validate generic XML - half your tool work is done for you.
(4) There is open source XML parsing code around, so half your config reading/processing/validating is done for you.
(5) Re-inventing the wheel is pointless if you are in business (fun to do for yourself to learn stuff tho)
(6) Size doesnt matter in the business world. Hardware is significantly cheaper to upgrade than software for a business (a proportion of hardware costs can be offset against tax as depreciation, I dont understand how it worked only that it did)
(7) XML is a buzzword that makes non-technical managers think its really modern & cool

[Dio]

Yeah, for me it mostly seems number 7 is the rule. Then again I thought the same about C++ a few years ago .

as to 1 - I've never found XML to be human-readable. At best, it is human-parseable-with-extreme-effort. 3 and 4 have also seemed a red herring in my encounters - the actual parsing of a file isn't the 'hard' bit, it's doing the right thing with it afterwards.

[gravy]

Yeah, for me it mostly seems number 7 is the rule. Then again I thought the same about C++ a few years ago .

Bottom line is XML isn't a panacea for everything and yeah some people will willfully overuse because it's tarred with the super hip brush. I'm railing against the "universally wrong" comment which is at the other end of the spectrum.

As I said before it was hugely refreshing to be able to get information out of MS Project files, Vis Studio vproj files and XLS files by having a quick squint at the XML and writing a small bit of code that extracted what I needed. All without having to look at one bit of online documentation. I was pretty happy with that and something that wouldn't have happened very easily with binary format files.

[Kemper_Boyd]

Yeah, for me it mostly seems number 7 is the rule. Then again I thought the same about C++ a few years ago .

There is quite a bit of truth in that. A good simple idea over time becomes a
hyped and overly complex 'standard'. I think you could say the same about UML.

The basic idea behind XML is fine, XML plus all the baggage applied across
the board that is the problem. If you have thought about why you are using
XML you will be fine, if you are XML enabling the cat you have lost the plot.

[Dio]

Yeah, that was certainly thought about its use for the input and config files cases I've seen.

With UML, I understand more about what it's for than what it is, which is very wrong somewhere.

[bloid]

It is my personal opinion that XML as a configuration file format was a huge mistake made by enthusiastic management types who had no idea what they were speccing out..

XML for inter-process communication is genius, but for anything I have to edit by hand it is a pain in the ass, and a huge step backwards...

It looks like a current push is towards using DSLs for this sort of configuration task, which is so much nicer

[gumboot]

Games on consoles are essentially embedded applications and when creating content for games it's very useful to have data held in a way that's easily edited and can be validated. XML is pretty good on that front, there are good tools for editing it and schemas can be used to validate the XML's correctness.

Well this is like saying that if I run Windows then I have access to more virus scanning software.

I don't get your complaints about data being intrinsically hierarchical. That's dependent on what you put in your XML file, it's easy to create an XML file that's practically flat. Same goes for quickness of interpreting XML data. If you create the data it's up to you how you parse it. I had to do some work interpreting an MS Project file and I found the usual XML libs too slow so I rolled my own solution using regular expressions that was plenty fast enough and worked within the bounds I needed. Just because you can make ridiculously complicated hard to parse XML files it doesn't mean you have an obligation to do so.

It is useful. It's been useful to me and I've seen it in use on a number of projects as an intermediary format with great success. I'm with you that embedded apps shouldn't have libxml or xpath linked in at run time but calling it a universal wrong is off beam.

The problem is that these benefits aren't related to XML. They're simply related to plain-text. If you have to constrain the language such that the hierarchy is flat then there's no point in using a heirarchical language. Choosing to use that language despite the lack of applicability means that you pay penalties that you simply needn't pay. It's a waste of resource, and it puts reading software in a position that it simply doesn't need to be in. The only thing that mitigates the problem is people's willingness to produce bloatware.

If you're using XML-like syntax without going into the full depth of the XML specification then all you've done is chosen a fugly syntax for your flat plain-text database... and that is sick and wrong.

(1) human-readable config files are ace.
(2) XML as a defined standard covers most of the bases you need for extensibility & backwards compatability (i.e. open/close tags mean if you dont understand a tag skip to the close tag & forget about it, so newer versions of the config files are still readable by older versions of the code)
(3) there are already a LOT of tools that will generate/parse/validate generic XML - half your tool work is done for you.
(4) There is open source XML parsing code around, so half your config reading/processing/validating is done for you.
(5) Re-inventing the wheel is pointless if you are in business (fun to do for yourself to learn stuff tho)
(6) Size doesnt matter in the business world. Hardware is significantly cheaper to upgrade than software for a business (a proportion of hardware costs can be offset against tax as depreciation, I dont understand how it worked only that it did)
(7) XML is a buzzword that makes non-technical managers think its really modern & cool

(1) Most non-XML configuration files I've dealt with are far more readable (the obvious exception being sendmail.cf, but that's designed as machine-readable only). At work we have tools that convert simple proprietary text files into XML simply because the XML that they have to become is ridiculously complicated and uneditable -- and yet those files are meant to express such simple structures. Even the old-fashioned Windows .INI convention is perfectly well suited to most configuration file requirements, and...
(2) ...software is perfectly free to ignore fields that have become obsolete.
(3) They're all crap. And when you're forced to do something from scratch because of the lack of good existing software, it's an unreasonably complex task.
(4) It's all crap.
(5) Many of the situations in which I've seen XML used are situations where the brainless solution (or even the criminally-brainless raw binary dump) are perfectly straightforward, and doubtless involve less hassle than dealing with a tool that tries to generalise the problem.
(6) no doubt.
(7) And it starts with an X!!

[Mr Dom]

(1) Most non-XML configuration files I've dealt with are far more readable (the obvious exception being sendmail.cf, but that's designed as machine-readable only). At work we have tools that convert simple proprietary text files into XML simply because the XML that they have to become is ridiculously complicated and uneditable -- and yet those files are meant to express such simple structures. Even the old-fashioned Windows .INI convention is perfectly well suited to most configuration file requirements, and...
(2) ...software is perfectly free to ignore fields that have become obsolete.
(3) They're all crap. And when you're forced to do something from scratch because of the lack of good existing software, it's an unreasonably complex task.
(4) It's all crap.
(5) Many of the situations in which I've seen XML used are situations where the brainless solution (or even the criminally-brainless raw binary dump) are perfectly straightforward, and doubtless involve less hassle than dealing with a tool that tries to generalise the problem.
(6) no doubt.
(7) And it starts with an X!!

(1) yes, it is perfectly possible to output better than XML but...
(2) Only if it knows WHERE THE UNKNOWN DATA ENDS
Thats the important bit.
For binary data, the good old chunk format is king (where you specify the chunk ID & a length, so if you dont understand the id you skip that length) Doesn't work for text unless you get anyone editing it to count characters themselves.

So - you need some tag that distinguishes each nested block so they can be skipped or extracted and passed on to a subsystem or something. You need these tag to match start/end.

You could use indents or brackets, and have your own parser/editor that checks it. You could use DevStudio brace matching. Anyone who has edited deeply nested code will testify that working out exactly which closing brace is missing & from where is not always the easiest job.

Or you could use XML and a tool that will check your matching such as... Firefox! (Thats what I use to validate XML), and where the closing tag is actually the same as the opening tab with an extra '/'
<myData>
<Answer> 42 </Answer>
<FavColour> Blue <OnTuesdays> Red </OnTuesdays></FavColour>
</myData>
Tada!

(3) Firefox to validate, SciTe to edit. Works fine for me

(4) You should find better XML parsing code. parsing the XML is the easy bit (tokenise, chunkify, etc.). Its what you do with the chunks thats good/bad & thats the code you add yourself.

(5,6,7) Never underestimate the stupidity of corporate IT!

[PaulCunningham]

To say that I as a .Net developer shouldn't ever, ever use XML is simply immature and ignorant. Rightly or wrongly, Microsoft have chosen this technology and made it very easy for me as a software developer to work with it and get on with solving business problems.

To assume that my goals and restrictions are the same as yours is laughable. Personally, I've got more important things to worry about than shaving off a few clock counts / bytes from a file loader that runs once at startup.

Universal Wrong? Not even close.

[gumboot]

.NET is wrong too.

[Jimaroid]

Makes me laugh when people blame the managers. XML was adopted by pedantic engineers looking to find a problem to apply their solution to. And even then, they used the wrong format. Doh!

XML is a mess but the alternatives of writing yet another parser are too depressing to think about. It's not perfect, it doesn't fit every task but it doesn't have to. It's much better now that it's adopted than having to handle a myriad of nonsense binary formats. You all know that binary formats are wrong, don't you?