Why XML config files?

[Daniel Billingsley]

I've changed the subject as I suggested a few posts ago because my original
title doesn't truly reflect my question or position.

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.

I'll grant you the DataSet/DataReader argument, but you know full well there
are countless cases where there are equivelent ways of doing things. Your
argument would call for a complete rewrite of the entire framework - numeric
type conversions is just the first example off the top of my head. Or how
about += or ++ operators? I can't count the number of times I've heard
seminar, MSDN, magazine writers, or even posters in this newsgroup say
something to the effect of "one of the things about .NET is it gives you
several ways to do things." You'll have to be a little more intellectually
honest with your arguements I'm afraid.

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.

You obviously haven't read, or can't understand, what I've written so far.

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.

Not how to translate "to provide an acceptable classes" means, but yes,
we're talking about supporting both. Just like you must understand the
significance of numerous web.config files that may contain duplicate values
or the fact that you can add trace listeners in a config file or within the
program itself, or what += means, etc. etc. etc. etc. - all "complexities"
we embrace because we like the flexibility multiple options provide.

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.

You have some interesting logic flow there Daniel. Having two options
"takes away flexibility"? You can't admit one single advantage of flat
files. You are even arguing here that maintaining a single key=value file
isn't never easier than a 5-6 line nested tag XML file. You are so hung up
on the argument that XML files are better for some cases, to which I've
readily agreed throughout this thread, that you apparently can't admit
there's a single situation where a flat file would be better, even
theoretically speaking, and have resorted to pure childishness here at the
end, as if I ever even hinted that I think there was not a need for XML
files in general.

 

[Daniel Billingsley]

BTW, this is kind of off topic, being more of a general .NET issue, and I
think everybody has expressed their opinion, so you can take your best shot
back at me but then I think this has run its course.

 

[Daniel O'Connell]

I've changed the subject as I suggested a few posts ago because my original
title doesn't truly reflect my question or position.



I'll grant you the DataSet/DataReader argument, but you know full well there
are countless cases where there are equivelent ways of doing things. Your
argument would call for a complete rewrite of the entire framework - numeric
type conversions is just the first example off the top of my head. Or how
about += or ++ operators? I can't count the number of times I've heard
seminar, MSDN, magazine writers, or even posters in this newsgroup say
something to the effect of "one of the things about .NET is it gives you
several ways to do things." You'll have to be a little more intellectually
honest with your arguements I'm afraid.


You obviously haven't read, or can't understand, what I've written so far.

No, I simply think you are wrong.

to

Not how to translate "to provide an acceptable classes" means, but yes,
we're talking about supporting both. Just like you must understand the
significance of numerous web.config files that may contain duplicate values
or the fact that you can add trace listeners in a config file or within the
program itself, or what += means, etc. etc. etc. etc. - all "complexities"
we embrace because we like the flexibility multiple options provide.


You have some interesting logic flow there Daniel. Having two options
"takes away flexibility"? You can't admit one single advantage of flat
files. You are even arguing here that maintaining a single key=value file
isn't never easier than a 5-6 line nested tag XML file. You are so hung up
on the argument that XML files are better for some cases, to which I've
readily agreed throughout this thread, that you apparently can't admit
there's a single situation where a flat file would be better, even
theoretically speaking, and have resorted to pure childishness here at the
end, as if I ever even hinted that I think there was not a need for XML
files in general.

Let me rephrase. To support flat files across all situations, flexibility
would have to be sacrificed. It would, infact, press the design of
configuration and its organization into things only expressable by flat
files, otherwise you end up with cases where you have to rewrite your config
file because you hit upon a situation, possibly a rare situation, where the
flat file doesn't do what you want. Now, speaking as an end user, config
files aren't my favorite things to begin with, now throw in that maybe I'll
have to start with a blank slate and rewrite it because the author was
concerned that I couldn't handle xml? That would just piss me off in the
end.