Why XML config files?

  • Thread starter Thread starter Daniel Billingsley
  • Start date Start date
D

Daniel Billingsley

Ok, I wanted to ask this separate from nospam's ridiculous thread in hopes
it could get some honest attention.

VB6 had a some simple and fast mechanisms for retrieving values from basic
text files, which in turn could be simply and easily maintained with
notepad.

I understand the benefits of XML, really, but in the case of configuration
files it seems it is almost always nothing more than unnecessary complexity,
both in accessing them and maintaining them.

What am I missing?
 
Daniel,

Well, you kind of answered your own question. The benefits of XML
become apparent when you need them. Granted, when things work, you wonder
why you need the extra complexity, but when you find yourself in a bind and
you have to make changes, you will be glad you have XML, as the number of
tools available to manipulate it are plentiful.

Also, like everything else in XML, it allows for easy insertion into
other business processes (I use business here loosely).

If you want, all of the routines in VB are implemented as static methods
in the Microsoft.VisualBasic namespace which is distributed with the
Framework (the classes for the most part are in Microsoft.VisualBasic.dll).
You can set a reference to this and use the methods as you would in VB
normally.

Hope this helps.
 
The benefit of XML config file is that you are not limited
to just key/value settings, but you can have different
types of configurations that are more complex. Of course
you can achieve the same thing with regular text file, but
why reinvent the wheel.

Tu-Thach
 
Nicholas Paldino said:
Daniel,

...Granted, when things work, you wonder
why you need the extra complexity, but when you find yourself in a bind and
you have to make changes, you will be glad you have XML, as the number of
tools available to manipulate it are plentiful.
Click to expand...

Uh.. you mean like Editor, Notepad, Wordpad, Word, etc. ad infinitum? Come
on, you've got to do better than that. Please, I'm not trying to be flaming
sarcastic, but you just gave the argument for never "inventing" XML config
files in the first place.
Also, like everything else in XML, it allows for easy insertion into
other business processes (I use business here loosely).

If you want, all of the routines in VB are implemented as static methods
in the Microsoft.VisualBasic namespace which is distributed with the
Framework (the classes for the most part are in
Click to expand...
Microsoft.VisualBasic.dll).

That seems a rather nasty solution for my C# app.
 
Which is the cart and which is the horse? That is, by your own statement
("you can achieve the same thing with regular text file") didn't XML
reinvent the wheel?
 
Let me clarify... I meant my statement only to apply to config files, not
XML in general. The benefit is obvious when we start talking about
something complex like a representation of a DataTable, but config files
are typically fairly simple.
 
I beg to disagree. Configuration files can be quite complex. Use of XML
for config files whenever your data is: nested rather than flat. For
example:
<servers>
<server type="development">
<database>
<name="mydatabase">
<users>
<user>
<name>smith</name>
<role>manager</role>
</user>
<user>
<name>jones</name>
<role>clerk</role>
<users>
</database>
</server>
<server type="production">
<database>
<name="yourdatabase">
<users>
<user>
<name>black</name>
<role>manager</role>
</user>
<user>
<name>white</name>
<role>clerk</role>
<users>
</database>
</server>
</servers>

Representing this in a flat INI type file is very complex if not impossible.
when new element groups are added to the INI file access code may break.
Since one has the power of Xpath and the XML DOM as part of the API one can
access groups of nested information quite easily ( \servers[server
@type="development]\users).
Also a new element groups may be added to the XML config file without
breaking older access code.

give it a try.

dlr
 
We don't disagree - I said quite clearly that config files are *typically*
fairly simple, but acknowledged XML is obviously better for more complex
situations.

Of course, we're talking theoretically here. I would be curious to see what
percentage of .NET apps have config files this complex vs. the kind that
could easily be handled by a flat text file.

I find your point about breaking flat text files interesting because for
simple configuration information I see a 6-line file with all kinds of XML
tags much more prone to maintenance problems than a simple 1 or 2 line flat
file.

I don't think we need to keep going 'round and 'round on this. I made this
comment because I saw a *few* valid points in another thread which claimed
something like OO principles and n-tiered applications were the work of
satan. Obvious nonsensical drivel. I do, however, personally know of some
OO purists that always tend to make simple projects 10 times more complex
than they need to be, which in the long run costs somebody money.

So my point here is I just that this is an example - I think (with no
empirical evidence, of course) there are more cases than not that making
config files XML added unnecessary complexity. Could .NET have supported
both (without the VB namespace hack)? Hmmm.


Dennis Redfield said:
I beg to disagree. Configuration files can be quite complex.
Click to expand...

<snip>
 
You are missing the point, of maintaining uniformity and standardization
across the whole world.


Keyur Shah
Verizon Communications
732-423-0745
 
Daniel Billingsley said:
We don't disagree - I said quite clearly that config files are *typically*
fairly simple, but acknowledged XML is obviously better for more complex
situations.

Of course, we're talking theoretically here. I would be curious to see what
percentage of .NET apps have config files this complex vs. the kind that
could easily be handled by a flat text file.

I find your point about breaking flat text files interesting because for
simple configuration information I see a 6-line file with all kinds of XML
tags much more prone to maintenance problems than a simple 1 or 2 line flat
file.

I don't think we need to keep going 'round and 'round on this. I made this
comment because I saw a *few* valid points in another thread which claimed
something like OO principles and n-tiered applications were the work of
satan. Obvious nonsensical drivel. I do, however, personally know of some
OO purists that always tend to make simple projects 10 times more complex
than they need to be, which in the long run costs somebody money.

So my point here is I just that this is an example - I think (with no
empirical evidence, of course) there are more cases than not that making
config files XML added unnecessary complexity. Could .NET have supported
both (without the VB namespace hack)? Hmmm.
Click to expand...

No. Remember, while configuration files are generally pretty simple, but
configuration can include things like assembly version redirections, etc,
which while not in every configuratoin, support HAS to be there, it may be
needed. Splitting across different formats just complicates things
needlessly. The choice to provide the slightly more complex solution with
vastly superior flexibility is a good choice, in my opinion. Flat files
simplicity is not enough to make up for their lack of flexibility.

It is, in theory, possible for an developer to write an INI or whatever for
his own settings. I'd call their design into question, I consider INI's and
the registry to be for legacy use only by this point.
 
Hi Daniel,

Thanks for posting in this group.
I have reviewed your posts. I think you already know the much benefit of
the XML, but as you think, most of the configuration files in .Net are
simple, so it worths no while to introduce such "complex" technical for
them.
I think the uniform xml format for config files is for uniformity and
standardization(just as keyur said). Just so, the .Net can provide the
uniform way for accessing and managing these files.
For the text file "simplicity" and xml file "complexìty", I think this
points to the content of the configuration file. This simplicity based on
you manipulating the configuration file manually. While you maintain the
config files through program in .Net or other applications, I think plaint
text file's "simplicity" becomes not so simple(because of non static and
uniform architecture). While xml's "complexity" become more easy(because of
rich tools and access models). We should be aware of the percentage of
accessing config files manually or programmatically.
Also, all the config files in the xml format(whether short or long) are
more scalable.

Hope this helps,

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

--------------------
| From: "Daniel Billingsley" <dbillingsley@NO.durcon.SPAAMM.com>
| References: <umuuoJGqDHA.1724@TK2MSFTNGP10.phx.gbl>
<106101c3a868$70aee0c0$a501280a@phx.gbl>
<ucCkIdHqDHA.2772@TK2MSFTNGP10.phx.gbl>
<#YBPFuHqDHA.2512@TK2MSFTNGP09.phx.gbl>
<OQsd5#HqDHA.2592@TK2MSFTNGP10.phx.gbl>
| Subject: Re: Why XML config files?
| Date: Tue, 11 Nov 2003 14:03:07 -0500
| Lines: 33
| X-Priority: 3
| X-MSMail-Priority: Normal
| X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
| X-Mimeole: Produced By Microsoft MimeOLE V6.00.2800.1165
| Message-ID: <uTQpyZIqDHA.2244@TK2MSFTNGP12.phx.gbl>
| Newsgroups: microsoft.public.dotnet.languages.csharp
| NNTP-Posting-Host: 68-74-16-211.ded.ameritech.net 68.74.16.211
| Path:
cpmsftngxa06.phx.gbl!TK2MSFTNGXA06.phx.gbl!TK2MSFTNGXA05.phx.gbl!TK2MSFTNGP0
8.phx.gbl!TK2MSFTNGP12.phx.gbl
| Xref: cpmsftngxa06.phx.gbl microsoft.public.dotnet.languages.csharp:198459
| X-Tomcat-NG: microsoft.public.dotnet.languages.csharp
|
| We don't disagree - I said quite clearly that config files are *typically*
| fairly simple, but acknowledged XML is obviously better for more complex
| situations.
|
| Of course, we're talking theoretically here. I would be curious to see
what
| percentage of .NET apps have config files this complex vs. the kind that
| could easily be handled by a flat text file.
|
| I find your point about breaking flat text files interesting because for
| simple configuration information I see a 6-line file with all kinds of XML
| tags much more prone to maintenance problems than a simple 1 or 2 line
flat
| file.
|
| I don't think we need to keep going 'round and 'round on this. I made
this
| comment because I saw a *few* valid points in another thread which claimed
| something like OO principles and n-tiered applications were the work of
| satan. Obvious nonsensical drivel. I do, however, personally know of
some
| OO purists that always tend to make simple projects 10 times more complex
| than they need to be, which in the long run costs somebody money.
|
| So my point here is I just that this is an example - I think (with no
| empirical evidence, of course) there are more cases than not that making
| config files XML added unnecessary complexity. Could .NET have supported
| both (without the VB namespace hack)? Hmmm.
|
|
| | > I beg to disagree. Configuration files can be quite complex.
|
| <snip>
|
|
|
 
Of course, we're talking theoretically here. I would be curious to see what
percentage of .NET apps have config files this complex vs. the kind that
could easily be handled by a flat text file.
Click to expand...

Well, even if there are only a few that benefit from having XML handle
the complexities, I think it's worth it going that way. I investigated
quite thoroughly whether we should use keep on using our trusty .INI
files instead - we gave up on it in the end, since there are some
cases (not many, but some) where the two-level section/key + value
just aren't enough.

Also, with all the XML support built right into the .NET framework,
you'd be foolish not to use it, and instead go back to re-invent the
wheel one more time.

Yes, XML is more complex and more verbose - get over it, and start
embracing it.

Marc
================================================================
Marc Scheuner May The Source Be With You!
Bern, Switzerland m.scheuner(at)inova.ch
 
I remember being on a nightmare project where we were using .INI files to
store language translations, and running into huge problems with (lack of)
proper Unicode support. Oh, and I remember everything breaking if the files
grew larger than 64KB ...
 
You folks are arguing for the need for XML config files in some cases, which
I've already admitted several times. I guess I should have made the subject
"why no more flat config files" to better represent my question.

In regards to supporting both simple flat files and XML files, I don't buy
the argument that it makes things too complicated. It doesn't seem any more
complicated to me than having to be aware of the way search paths worked in
DOS 6.22 or the way a web application can have multiple config files
scattered across several folders creating a complex hierarchy of config
settings. The rules would be quite simple:
1) look in a flat text file named xxx
2) look in the config file named xxx
3) XML takes precedence on conflict

Just think of a case where your config files only has one setting and you're
on the phone with a user of your software and you're trying to get them to
turn on verbose logging in the config file to track down some obscure bug...
would you rather have to walk the typical end user through changing a file
with one line

Logging=0
to
Logging=3

or have to get them to make the right change in an XML file. I'd take the
former any day. This is an example where the complexity of XML will
undoubtedly cost people money.

In fact, now that I think of it, the beauty of supporting both would be you
could put a few basic things like that in the .ini file and the more complex
stuff in the XML file.

As for .ini and registry being legacy, I think that is kind of a
self-defeating argument. We've been told for 5 years the registry was
supposed to make config files obsolete, and here we trying to get away from
the registry as much as possible and go back to config files. Maybe I'm
just an ornery old fart, but I'm very skeptical of the latest greatest new
directions from MS being the final word.

The "reinventing the wheel" argument is interesting too in that regard,
since XML config files is I guess the 3rd version now. I agree it's a good
reinvention, but that argument isn't logical - as if leaving flat file
support in .NET would have been a 4th version. No, it was the 1st. Yes, it
would be unwise of me to write my own flat config file support at this
point, but that's quite a different thing from MS leaving it in .NET.

Yes, there are reasons why XML config files are a great thing, but that
ain't two of them.

Now, the international/unicode argument is an interesting one. I wonder how
big the impact of that is though, from the standpoint of number of projects
it effects. Since XML is in reality a simple text file, how does it solve
that problem?

Please don't let this degrade into some kind of flame war as if I'm arguing
against XML, or that direction, or MS in general. I'm ONLY arguing against
making things unnecessarily complex, which I believe XML config often does.
 
Daniel said:
Ok, I wanted to ask this separate from nospam's ridiculous thread in
hopes it could get some honest attention.

VB6 had a some simple and fast mechanisms for retrieving values from
basic text files, which in turn could be simply and easily maintained
with notepad.

I understand the benefits of XML, really, but in the case of
configuration files it seems it is almost always nothing more than
unnecessary complexity, both in accessing them and maintaining them.

What am I missing?
Click to expand...

thanks for a very good interesting post. I am speaking as a (you could
say) "wannabe developer" in c# so I do not talk as someone with a great
authority on the subject :?)
I must admit to agreeing with you that the arguments against simple ini
files has left me somewhat unconvinced possibly like yourself. I still
remember the days of MSDOS, Lotus123 etc and cant help but feel that
things have gone almost full circle (not a bad thing). One of the
reasons we are told is because of dll hell.
I remember when Microsoft didnt embrace standards but made up there
own, remember the battle between corba and com. Now ms is submitting
standards to the ecma! People would not have believed that 10 years ago.
And I guess as much as people may argue that what we are getting IS an
improvement to what we had, I wouldnt be suprised to see the
reinvention of a light weight registry in 10 years time. I guess what I
am saying is this ...that no matter whether it is an improvement or not
the fact of the matter is that it is here and it is here for the
forseeable future, so we must embrace it where we can.

"You can't say civilization don't advance -- for every war, they kill
you in a new way"
Will Rogers

--

Br,
Mark Broadbent
mcdba , mcse+i
=============
 
1) Simple things tend to become more complex over time

2) It's easier to use XML than flat files. Why? You want to get the
configuration information into and out of the file, and represent it as
(say) an object in your program. All you have to do is create a
configuration object, mark it as serializable, and then use the built-in
serialization services to save and load it's state. Just a few lines of
code. No nasty parsing. No config/object mapping - everything is done for
you.

Eric
 
Ok, more of the same arguments why XML config files are better for some
purposes. I think there's not much point to this conversation.
 
Daniel Billingsley said:
You folks are arguing for the need for XML config files in some cases, which
I've already admitted several times. I guess I should have made the subject
"why no more flat config files" to better represent my question.

In regards to supporting both simple flat files and XML files, I don't buy
the argument that it makes things too complicated. It doesn't seem any more
complicated to me than having to be aware of the way search paths worked in
DOS 6.22 or the way a web application can have multiple config files
scattered across several folders creating a complex hierarchy of config
settings. The rules would be quite simple:
1) look in a flat text file named xxx
2) look in the config file named xxx
3) XML takes precedence on conflict
Click to expand...

The complexity comes down to support. Simply because flat files are
possible, support personnel needs to be able to walk the end user through
whatever configuration method you use, it could come down to what the
administrator felt like using, that is complexity defined.
Also, it requires extra classes, it adds the potential that you walk into a
situation where you have to scrap your config file because you need to store
hiearchal data.
Standardization has a point, and picking ONE format to use was needed. In
this case xml provided a much better solution overall, even if sacrificing
simplicity in the bottom 10% of cases.
Just think of a case where your config files only has one setting and you're
on the phone with a user of your software and you're trying to get them to
turn on verbose logging in the config file to track down some obscure bug...
would you rather have to walk the typical end user through changing a file
with one line

Logging=0
to
Logging=3

or have to get them to make the right change in an XML file. I'd take the
former any day. This is an example where the complexity of XML will
undoubtedly cost people money.
Click to expand...

I'd rather tell them how to do it in XML than have to ask them:
"Ok, sir, does your app.config start with <?xml > or does it start with
something else?"
"the xml one"
"Ok, xml, then do this..."

or,
"something else"
"ok, it doesn't, then do this".

why does 2 possibilities make things better? Most end users I've been in
contact with can't handle sectioned ini's very well either.
In fact, now that I think of it, the beauty of supporting both would be you
could put a few basic things like that in the .ini file and the more complex
stuff in the XML file
Click to expand...
..
Which is a waste, one file, one config. No need to add a bunch of extra
logic and more complicated instructions simply because it lets you have a
flat file.
As for .ini and registry being legacy, I think that is kind of a
self-defeating argument. We've been told for 5 years the registry was
supposed to make config files obsolete, and here we trying to get away from
the registry as much as possible and go back to config files. Maybe I'm
just an ornery old fart, but I'm very skeptical of the latest greatest new
directions from MS being the final word.
Click to expand...

I considered the registry to be much better than the annoying proprietary
configuration file formats. However, with the evolution of xml and a
standardized, fairly easy to read syntax, I no longer think that the
registry is a as nessecery device.
The "reinventing the wheel" argument is interesting too in that regard,
since XML config files is I guess the 3rd version now. I agree it's a good
reinvention, but that argument isn't logical - as if leaving flat file
support in .NET would have been a 4th version. No, it was the 1st. Yes, it
would be unwise of me to write my own flat config file support at this
point, but that's quite a different thing from MS leaving it in .NET.

Yes, there are reasons why XML config files are a great thing, but that
ain't two of them.
Click to expand...

I disagree. INI files are still annoying. Explaining to people how to work
with sections was too complicated, and they are to inflexible.

I do wonder why flexiblity is not a good thing about xml however?
Now, the international/unicode argument is an interesting one. I wonder how
big the impact of that is though, from the standpoint of number of projects
it effects. Since XML is in reality a simple text file, how does it solve
that problem?
Click to expand...

Basically, standardized encoding specifier. Plain text files don't reliably
specify an encoding. You simply have to assume its the proper encoding.
Thats basically xml's strong point.
Please don't let this degrade into some kind of flame war as if I'm arguing
against XML, or that direction, or MS in general. I'm ONLY arguing against
making things unnecessarily complex, which I believe XML config often does.
Click to expand...

I'd rather not start a flame war either, I simply disagree with your stance.
I think in the end, xml config files reduce overall complexity by providing
a standard format that the entire framework works with, while flat files
could only be used in limited situations.
 
Also, it requires extra classes, it adds the potential that you walk into a
situation where you have to scrap your config file because you need to store
hiearchal data.
Standardization has a point, and picking ONE format to use was needed. In
this case xml provided a much better solution overall, even if sacrificing
simplicity in the bottom 10% of cases.
Click to expand...

By that logic we should only have ONE mechanism for remoting (HTTP or TCP),
only either DataSet or DataReader, or one database supported by ADO.NET,
etc. ad infinitum. God forbid we should have to switch between two options!
There are a gazillion cases where having multiple ways of doing things
obviously adds complexity to the developer that must understand them all, or
at least choose one of them. But we accept and embrace them because then we
can pick the one that works best for the particular situation given that the
options each have certain strengths and weaknesses. What's the difference
here?
I'd rather tell them how to do it in XML than have to ask them:
"Ok, sir, does your app.config start with <?xml > or does it start with
something else?"
"the xml one"
"Ok, xml, then do this..."
Click to expand...

Uh, I would think the person/company who wrote the application ought to know
where they put the setting in question.
why does 2 possibilities make things better?
Uh...

.
Which is a waste, one file, one config. No need to add a bunch of extra
logic and more complicated instructions simply because it lets you have a
flat file.
Click to expand...

See above.
 
Daniel Billingsley said:
into

By that logic we should only have ONE mechanism for remoting (HTTP or TCP),
only either DataSet or DataReader, or one database supported by ADO.NET,
etc. ad infinitum. God forbid we should have to switch between two options!
There are a gazillion cases where having multiple ways of doing things
obviously adds complexity to the developer that must understand them all, or
at least choose one of them. But we accept and embrace them because then we
can pick the one that works best for the particular situation given that the
options each have certain strengths and weaknesses. What's the difference
here?
Click to expand...
Thats a very weird set of ideals. In some cases, HTTP or TCP is annoying and
hopefully will be less of an issue in the future. However, DataSet and
DataReader are vastly different things. Flat files and xml files would be
the same thing in a different format, there really is no parallel here.


Btw, you've yet to provide ANY proof that flat files are useful. All you've
done is complain about a pervcieved increase of complexity. Do you have any
argument for supporting flat files, or is it just that you don't want to
upgrade(or aren't willing to actually try to learn something maybe?) You
have, however, argued that increased flexibility is not a reason to not use
flat files, what exactly is it that you want?
Uh, I would think the person/company who wrote the application ought to know
where they put the setting in question.
Click to expand...

Ok, then, what if the end user administrator needs to use advanced, non-flat
file capable features like remoting configurations or assembly redirections.
That means that the xml file would have to be used and both would have to be
supported by the developer to provide an acceptable classes.
See above.
Click to expand...

Of course, your proving my point. One thing is simpler, in the cases above
there are valid reasons for the variety of choices, even if it increases
complexity. On the other hand I don't think there is a valid reason for flat
files, they don't provide anything, no new features, no ease of working
with, it just takes a way flexibility without adding anything to the mix.
Why bother? Why not store all of your data in ini's for that matter, forget
xml or databases, just use flat files.
 
Back
Top