RE: XML and Config files

>Have you ever heard of "Perl Best Practices"?
Indeed I have heard of it, unfortunately I have not read it. Perhaps you
could point out the particular point you were trying to make instead of just
saying RTFM?

>"Microsoft standard"?  Sounds more like a case of NIH.
I wish I knew what NIH meant, since that whole sentence hinged on my
understanding of that cryptic Acronym. I'm guessing it's not the National
Institute of Health...

>In fact, just to turn a crank, what is XML good for, anyway?
The link you provided was an interesting read, but several of the comments
below the article reflect my own feelings. That was quite a straw man
defense; the XML described in the article was poor. His configuration file
was completely without annotation and impossible for someone to understand
without additional documentation. Typically a well formed XML file will be
self documenting. Also as pointed out in the comments the Judicious use of
attributes means you can glean more information from one quick glance than
you could be reading an entire non-xml configuration file.
Ex:
abraham Blue 1 10   #what does this mean?
<tank side="blue" move=10 qty=1>abraham</tank>  #this is more clear


Also the author stating that he's written programs that "required exactly
ZERO configuation(sic)--no configuration files, no annotations, nothing" is
either ignorant or meant to inflame.  Of course we've all written "hello
world" programs that didn't require configuration. Some programs are
designed to be configurable. I have a program/framework written in Perl that
loads objects (defined at runtime by the config file), links them (at run
time in a manner defined by the config file), makes connections to other
processes (as defined by the config file) and process messages (as defined
by the config file) completely based on XML configuration files. The
configuration of these objects can be nested, and the message processing
rules can be quite complex. Surely this could've been in any format but I
believe that XML (being widely supported) was the easiest and most
productive way to do this.

I still haven't heard a real reason not to use it for configuration, unless
you don't need configuration, or your configuration is exceedingly simple.
I'm trying to keep an open mind, and willing to listen to any well thought
out points.  I have in the past made config files perl, and just executed
them at run time so I can see the draw to use non-xml. However, that one
came back to bite me too when a non-perl program wanted to access the same
configuration settings.

(as a side note there are several reasons XML is a preferred data transport
method. Including, but not limited to, the fact that two different parties
can exchange it without having to agree on a library/programming language.
Does RMI work anywhere but JAVA? XML can also be validated against XSD,
another widely supported feature, that can be used as a conflict resolution
between the two parties when a malformed message is passed. Again of course
it could be binary, or some other text format, but why re-invent the wheel,
or make things difficult to debug (ie using binary) when you don't really
need that kind of speed.)

-Wayne Simmons

--
Software Engineer
InterSystems USA, Inc.
303-858-1000
  


_______________________________________________
Perl-XML mailing list
[email protected]
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs