Why use XML as a storage format? [duplicate]_问答_开发者

This question already has answers here: Closed 12 years ago.

Possible Duplicate:
When is it OK to use an XML file to save information?

What's up with everything using XML as a storage format for configuration files such? I'm asking because [name retraced] framework has an XML configuration file to store database credentials, and the particular application that's built upon the framework has some menus stored as an XML fragment in a database... it's not like we'd share database credentials or or menu structure with others, or even data that would be consumed by multiple services. It's all internal/specific to this app. A coworker said that XML is an easily-readable format for humans... but I don't think that's true. p开发者_开发知识库assword foobar123 in an INI file is easier for a human to read than <password>foobar123</password>. Then he said about parsing, but INI files have been around for ages so I'm sure there's a library or two for parsing them. I could see the logic behind using it as a data export method, because then whatever the app produces can be consumed by other services in a straightforward manner, but for internal stuff I just don't get it. Someone please enlighten me.

I won't tackle your general question (I'm not a huge XML fan myself), but I will comment on your comparison of INI and XML files.

XML is good at describing arbitrarily structured data (trees, etc.). INI files best described categorized dictionary type data (key, value pairs). For the specific example you gave of a menu system, XML is a much better bet as it can reflect the menu tree directly.

Other people have made good points, so I'll just add that "human readable" is subjective. But when you consider that every good editor has full XML tools (highlighting, code folding, etc) and that most developers are used to XML thanks to HTML, I'd argue XML is very human readable.

The reasons as they should be:

interoperability (almost anything can talk XML, but in a closed system this it moot, up until the very day another application has to be able to read it)
validation (XSD etc.)
hierarchical

The actual reason:

The manager likes the buzzword & to claim 'it works with XML'
There were so many happy people claiming 'it works with XML' that actual developers came to think it was a good thing

Then again, formats like JSON, YAML, csv, or standard .ini all have their places.

Generally speaking, the XML format is easy to inspect manually, in the event you need to debug or update an item.

In addition, structure of an XML document makes a nice fit for nested menus, which can easily be parsed into a TreeView type structure or for simple table structures, so you can quickly make a "portable database" to parse/manipulate/save for your application.

There are lots of XML parsing libraries out there, and lots of applications that will read XML with minimal hassle, so if you want to open your application to third parties, API's, etc., this makes for a nice way to do it.

Finally, by using XML with XSLT, you can quickly translate your data into various formats, which makes for an ideal way to use the same data and present it on a web page, an RSS reader, a mobile device, etc.

There are definitely some drawbacks with XML, the bloated size, complexity issues beyond simple structures, and having passwords in clear text, but for a lot of quick and simple applications/configurations, XML works nicely.

I find it's because different technologies like different formats that complements their "style" of coding. For example, java tends to use XML because of it's ability to use namespaces and versioning to break up the data. Where as javascript tends to use JSON to store data due to it's simple/fast/easy-to-understand nature.

PHP doesn't have one standard encoding for storing data.

Regarding speed is required, it's best to store them as valid PHP using var_export to write them and require to read them. There are a number of frameworks that do something along these lines to make configure reading fast. As long as the files are decently small the opcode caching will keep any reads to these files very fast. Though there is no reason why you couldn't (and shouldn't) use XML, YAML, JSON if speed isn't your number one priority.

config.php

<?
return array( "db_name" => ..., "db_user" => ... );
?>

read-config.php

<?
$db_configure = require( "config.php" );
//do stuff with $db_configure
?>

Clarity is one reason. Take a look at this .ini file for eclipse.

-showsplash
org.eclipse.platform
--launcher.XXMaxPermSize
256m
-vmargs
-Xms40m
-Xmx256m

Right there, we have a few different conventions. It would be more obvious if this were setup as something like :

<showsplash>org.eclipse.platform</showsplash>
<launcher-param>
    <param-name>XXMaxPermSize</param-name>
    <param-value>256m</param-value>
</launcher-param>
<vmargs>
    <arg>-Xms40m</arg>
    <arg>-Xmx256m</arg>
</vmargs>

It's alot more verbose, and it also uses a few different conventions, but they are clearer than the ini version. at first, I wasn't totally sure that org.eclipse.platform was related to showsplash.

I tend to agree, though that XML is a bit over used.

i use XML because i don't want to have to write a file parser du-jour. i already have a well known file parser when the contents are XML.

And i don't want a binary format, because i want to be able to look at, and edit, the file in notepad when the time comes to fix something.

You are absolutely right, in every point.
XML is not intended for reading by humans and especially - for writing.
It is more a buzzword than anything else.
And it makes sense only with data interchange.

The only XML advantage is coming from it's popularity - many parsing/validation tools. Say, in PHP one can't parse ini.style data (param = value) coming from a database: there is only function to read a file. While you can always find some tool for XML. So, the reason is: XML is a standard. It is like PHP: many people using it despite of many deign flaws, but of because many advantages and strong community.