xml

XML diarhhea

October 27, 2004 16:02:23.579

XML has been the buzzword in the industry for the last few years. I'm starting to really, really wonder why. Take Web Services (please). How is this not a complete redo of CORBA, but using a textual format so as to slow the whole thing down? Heck, the WS* working group has even gotten as bad as the OMG used to be in terms of spewing out specs that no one cares about. Then there are configuration files. Everything needs to be in XML now. Again I ask, why? I have a simple theory about configuration files - they should come in one of two forms:

  • Simple data that the user may be expected to hand edit? Use an ini (key=value) style file. Why? Because they are simple, and anyone can figure them out. Hand editing an XML file is just asking for trouble.
  • More complex data that will only be changed by the application, or some application provided editor. This should probably be in a binary format so as to discourage hand editing. If the data is in a form that it should only be manipulated by the application, a textual format is the last thing you should be using

This is why I use an ini file for BottomFeeder settings. Knowledgeable users can hand edit the file to tweak settings, and it's obvious what the format is. I use a binary format for the application data - for one thing, it was too big to be optimal XML, and for another - I don't really want anyone trying to hand edit it. More and more, I'm finding that XML is becoming the useless answer to every question...

Comments

XML diarhhea

[ Michael Lucas-Smith] October 27, 2004 20:28:46.932

Comment by Michael Lucas-Smith

What format would you put RSS in instead? Or the content in each RSS item?

[Troy Brumley] October 27, 2004 20:55:37.177

XML is just another tool, and it has a proper domain. An ini file is not such a good thing for XML, though we have looked at doing that in a few things. I think it's a good format BETWEEN systems, but inside a system, use whatever makes sense.

ini xml

[bryan] October 28, 2004 4:31:34.756

I disagree, ini files are perfect for xml as long as the following is done:

  • a simple non-hierarchical xml is used which basically moves from username=bryan to bryan
  • that the tool using that xml ignores anything it does not undersand

by having that I can

  • work with that ini file using numerous tools that are used for just about everything else, working with non-marked up text has become the uncommon case, as such I have to take more effort to work with that simpler format then I have to work with the more complex format
  • I can put other things into the file that I know the meaning of, perhaps for tracking configurations files etc. that I can't in the ini file.

These rules if followed give the most extensible and easy to use xml, unfortunately people with other agendas want to place xml schema etc. on top of all that. even in cases where it isn't necessary, thus making everyone fall down, tear their clothes and pour dirt on their face screaming that xml is too complicated.

ini files are horrid

[Elliotte Rusty Harold] October 28, 2004 8:27:33.585

I hate editing .ini files by hand. It looks easy but it never is. For instance:

  • Does the file have to end with a line break? Does it have to not end with a line break? Does it not care?
  • Does it support non ASCII characters or not? Do I have to escape them? If so, how?
  • Is white space significant? Is it preserved? Do I have to escape it? If so, where and how?
Every .ini file answers these questions differently, and these are hardly the only issues. More often than not, the answers aren't documented anywhere and you just have to experiemnt and hope.

Every single one of these questions is answered in a standard way in an XML document. You never have to debug the syntax. A well-defined syntax helps users (at least the sort of advanced users who ar elikely to be editing ini files in the first place). .ini files are not a well-defined syntax.

One size doesn't fit all

[Rob Meyer] October 28, 2004 10:55:42.459

Why expose application data or complex configuration as XML? For one, you get the parser and serializable for free. It may not be a perfect representation, but you don't have to write it, it's available for just about any language you can imagine. And, it allows your users to use your application in ways that maybe you hadn't anticipated. As always, there are different audiences. I've been a system administrator for a long time, and any server-side application that keeps its configuration (or data that I might be interested in) in a closed binary format are frustrating to deal with. Maybe I want to generate the config from scripts or templates, maybe I want to move it from platform to platform, maybe I want to put it under revision control.

By saying "you don't need to worry about those details," the application designer is dictating how I will use the application, which is just going to make me like it less. If having such details hidden is considered to be a competitive advantage, then that's fine and within your rights, but it's also within my right to choose a different program, which I happily will.

Configuration files

[James Robertson] October 28, 2004 11:41:52.704

To reiterate, I see two cases:

  • Files users might modify - keep it simple. Ini files are perfect for this
  • Files users can't/should not modify - Format doesn't really matter - whatever works for the developer. That could be binary or XML.

My point is, XML doesn't really work for non-technical end users...

 Share Tweet This

comments(6) | permanent link | printer friendly | del.icio.us | diggIt | next | prev

-->