XML What is it good for?
Miscellaneous Forums/General Discussion/XML What is it good for?
Hey guys,
I'm working on a coding project that needs a lot of data files in text format. Somebody brought up XML, but I've never used it. Anyone have any experience with it? What are the advantages?
I've always found it to be a worthless bunch of overhead. The supposed advantage is that it delimits fields - but a good file spec does the same thing with a lot less overhead.
Well it depends on exactly what you use it for.
XML files are human readable, which means that you can easily see their contents
It is a standard format that can be read by almost any modern coding language/platform, making the files easy to share and use in other applications.
It is easy to perform basic validation of XML files providing a schema has been defined.
The are a lot of tools/technologies associated with XML, such as XSL:T which can do things useful things like change files from one schema to another.
That said, there are some situations where it might not be suitable, e.g. large volumes of data. It cannot replace a database in most situations.
Well, the advantages are that it's quite organized and easy to read and understand. Also, there are tons of editors made for it that can check for syntax errors, have auto-complete functions and so on.
However, if you are talking about large amounts of data that are only processed by the application (no need to be readable) then I suggest you go for binary as XML can get pretty big pretty fast. That is ofc if you care about size in this project. :D
I use XML quite often, usually for config files or map files, because it's a pretty common format and you can find parsers/editors immediately. All you have to do to parse your config file is sommething like:
Antialias = GetAttributeValue(GetNode(GetNode(Root,"Graphics"),"Antialias"),"Value")
Ofc, this depends on the parser.
And your file looks like:
<Config>
<Graphics>
<Antialias Value="8x"/>
<--!
Other graphics options here
-->
</Graphics>
</Config>
Somebody brought up XML, but I've never used it
I wouldn't worry about it. It's not widely used.
o_O
We sometimes use compressed XML to pass realtime data over the internet. Works quite well.
We use XML all the time, but it depends on the data what is the best for your project.
HTML is maybe the best example, so your using a form of XML when opening a website.
<HTML>
<BODY>
Hello World!
</BODY>
</HTML>
XML can be used for many things and is ideal if every object have a different amount of options.
<OBJECT1>
<OPTION1>
</OPTION1>
<OPTION2>
</OPTION2>
</OBJECT1>
<OBJECT1>
<OPTION1>
</OPTION1>
</OBJECT1>
If I want to use the same options for object I would rather go for a CSV type of data file.
"OBJECT1","OPTION1","OPTION2"
"OBJECT2","OPTION1","OPTION2"
"OBJECT3","OPTION1","OPTION2"
xml nodes have parent and child nodes which is useful for all sorts of things, like being able to put objects in a chest for example
Anyone have any experience with it?
Yes. Quite.
What are the advantages?
Compared to what? XML in general, and SGML in particular is good for storing semantic information within documents, for example the <strong></strong> tags which add emphasis to passages in HTML documents.
Mayor benefits of XML:
* Open Web Standard - no price of admission, can be parsed in practically every language on practically every platform.
* Widely Adopted - hundreds of tools allow you very easy access to data, in very visual tools - you do not have to be a programmer.
* Easy Integration - Using XSLT you can easily convert between different formats (for instance XML and XHTML) or between two differently structured XML documents.
* Strict Syntax - XML does not play well with people who write rubbish data. Thus using a simple validator against a given XML Shema, you can easily determine whether the entered data is incorrect or not.
* Scalable - There is no (theoretical) upper limit to how large XML documents can be, and since they're stored in a machine-readable form of plaintext, they can be read for a very, very long time.
Hello.
And, of course, it's easier to spell than CSV.
Happy New Year to All.
Goodbye.
<itemstypes>
<item>
<name>Apple</name>
<weight>1</weight>
<color>red</color>
<type>
<class>nutrition</class>
<energy>10</energy>
</type>
</item>
<item>
<name>Grapefruit</name>
<weight>2</weight>
<color>yellow</color>
<type>
<class>nutrition</class>
<energy>15</energy>
</type>
</item>
</itemstypes>
Perfect for game design!
I'm a bit anti-xml too myself, if overused. You don't have to just throw xml at every single file you ever create. The supposed benefit of xml is that you `mark up` various pieces of data to describe what they MEAN, so that when you have more than one xml file being interpreted you'll be able to understand what the meaning of the fields are - like sharing recipies with lists of ingredients and cooking instructions in them. I don't see that putting stuff in xml for a preference file or most other files is of much benefit at all. If it's an attempt to make the information `human readable` I think that's a pretty crappy interface for the average user who will not likely understand xml. It's perhaps useful for transferring information with a given meaning between programs, though. I agree that it's mostly a way of greatly bloating text with unnecessary tags.
The whole idea behind XML was to provide a commonly accepted semantics to exchange data between otherwise incompatible systems. The DTD file accompanying the XML file describes the structure of the data, and the receiving system/software can then import that data to its own database/filing system.
Again: The important factor behind XML is that it is an accepted semantics throughout the entire IT landscape, from insurance companies and banks to everything and everybody else.
If you do not have the need to exchange data with other IT systems, there will be alternatives that are easier to implement and use than XML.
I think it's good for exporting to support simple conversions, but other then that for just saving/loading data I think it's a bloated, slow turd. Binary ftw.
XML What is it good for?
Not as much as it used to be since Microsoft's bastardized version of XML was adopted as an ISO standard.
I have two main problems with XML.
First is that it is extremely wordy, requiring the same bracketing to be used repeatedly. (I'm lazy, and reading it is a pain in the neck)
Second and far more important, the LEAST troublesome part of using any data is the file spec it was saved in(*), the part that is hard is knowing what to do with the data proper. Every time I hear "you can import and use that data, it's in XML" I want to pull my hair out...
Actually nothing wrong with XML, it's just hyped as something more then it really is.
XML is not really about STORING information, but more about transporting it between systems. BUT: It's ace for configuration files and stuff. I also love that you can provide metadata about the data you're describing / transporting.
dynaman, I don't get your points about 'reading' xml. It's not meant to be 'read' and closing tags can be forgotten about while reading it as a human being anyway. And I think the MOST troublesome part of using data is the spec it was saved in. With XML you can see the data name/purpose and value, and how it's related to other data.. Try to do that with a binary file... What's not to love about it?
Still, using text based .ini files is powerful enough for most local configuration purposes. But when you have internal relations ships in your data then XML is awesome. I love storing and reading treeviews in xml.
I like it, very easy to edit flow levels in a text edit and merge delete stuff if you don't want to use FlowED, plus you can still compile it into a binary format if you want.
> Try to do that with a binary file... What's not to love about it?
I've done it any number of times, if supplied with a proper spec of the file it is no problem.
The real problem with XML is not the layout, once again it is the fact that people seem to think that since it is in XML you automatically know what to do with the information saved in it, which is almost never the case.
First is that it is extremely wordy, requiring the same bracketing to be used repeatedly.
Seconded.
Personally I prefer JSON. Not as wordy, but supports more or less the same features.
Also, for storing lots of small data, XML is the wrong format in my opinion. It has too much overhead and is slow. A binary format, or simply using sqlite would probably be a better idea.
Apple abuses/overuses XML files, and they've had to convert their XML to binary, so their applications are usable.
First is that it is extremely wordy, requiring the same bracketing to be used repeatedly. (I'm lazy, and reading it is a pain in the neck)
Then use something like XMLSpy if it's such a big deal for you.
I've done it any number of times, if supplied with a proper spec of the file it is no problem.
No it's not. The problem is you have to write your own parser, and for complex information this can be quite the pain in the backside, particularly if some information is optional. With XML you can just fire up your favorite XML DOM or SAX parser (depending on requirements) and off you go. You don't NEED to know how the data is organized, you just need to know what it means.
Personally I prefer JSON. Not as wordy, but supports more or less the same features.
What? No it doesn't. JSON is a data format. XML is a document format. They are not designed for the same things. JSON is designed to allow serialization of JavaScript objects, XML is designed to provide semantics to a document. It's like saying that PNG and MP3 support more or less the same features. They both store media. The main difference obviously being what KIND of media they store. XML for instance provides no way to define an associative array (because it isn't designed to handle data structures) where as JSON does.
A piece of XML is usually called a "document", but that doesn't mean it can't be used to store data, and it is. This is one way to have an associative array in XML:
<Object>
<Entry Key="Blue"><String>0x0000ff</String></Add>
<Entry Key="Green"><String>0x00ff00</String></Add>
<Entry Key="Red"><String>0xff0000</String></Add>
</Object>
There's extra verbiage, of course, but with decent XPath support you can then select from the object with something like /Object/Entry[@Key="Red"]/*[1] to get the <String> element inside <Add Key="Red">
If the values of a given associative array are also always strings, you could just use the attributes of a single element.
I'm working on a coding project that needs a lot of data files in text format.
That's probably a good example of where to use XML, especially if the data should be available to more than one program or module. Unless the amount of data is huge, using XML should not be too slow. Also, for those concerned about file size, it compresses well.
> Then use something like XMLSpy if it's such a big deal for you.
Sure I could, but I can just use notepad with a properly formatted plain text file
> With XML you can just fire up your favorite XML DOM or SAX parser
Not if the language I use does not have that parser. VB6 in this case, I'm sure there is a parser out there for it by now but I can't be bothered to go looking for one at this point.
I use crimson editor, seems to be a really nice all rounder for text editing, helped by the fact that it has syntax highlighting for Ogre material files. Handy if your using flow.
XML is an excellent format despite a few peoples obvious prejudice. Half of which is probably MS bashing. If you like it use it.
Why anyone would want to use notepad, unless your trying to say your some part of a grassroots computer using organization or something. Only other reason I can think of to not use something else if you can't be bothered to use anything else and it's conveniently there. If I use it it's because its only a right click away when I'm feeling lazy and need to create a new file.
> Why anyone would want to use notepad
Because I have to do setup on client machines, and like you say "it's convientantly there"
> Half of which is probably MS bashing. If you like it use it.
You got me there, I didn't know XML was MS based - I know they extended upon it for another purpose though (forget what exactly it was).
Ive always seen it as a standard "chunking" format.
Its useful as its kind of a standard way of storing information. What that data is, how you use it and how it is stored is entirely up to you.
Eg. an xml from a 3d program and from a wordprocessor would be chalk and cheese. The only thing they would have in common other than mabe the header would be the way the data is read and written (the formatting that lies in the file).
Perhaps ther is more to it, but thats how i know it.
A piece of XML is usually called a "document", but that doesn't mean it can't be used to store data, and it is.
Yes it does actually mean just that. Yes people use it for data, and yes that's most people who have a poor opinion of XML in here have such a low opinion of it. It's a bit like Flash. In itself Flash is really good, people just use it for things it's not supposed to.
This is one way to have an associative array in XML:
That's not an associative array. It's a document that can be interpreted as an associative array, and that's XMLs weakness compared to for instance JSON, when you need to store data. How about a graph or digraph?
Half of which is probably MS bashing. If you like it use it.
Whats XML got to do with microsoft??
I thought it all started with sun microsystems or something like that. I believe it was MS who were actually rocking the whole 'open format' boat back then for obvious reasons.
I think INI files are ten thousand times better than xml (to hold config that, that is)... too bad it's windows only :P
I think INI files are ten thousand times better than xml (to hold config that, that is)... too bad it's windows only :P
XML can be much easier to parse for the programmer, since it doesn't really matter what order the data is in since the tag can indicate what it is that you're dealing with.
I think INI files are ten thousand times better than xml (to hold config that, that is)... too bad it's windows only :P
You mean Java Properties files? Yeah those are pretty useful for storing lists of key-value pairs (if that's your fancy), but useless for storing semantic documents or complex data structures, so not really a suitable replacement for either XML or JSON.
You mean Java Properties files?
no, I think he means ini files.... which aside from key-value are slightly different with the most obvious being lack sections in .properties. not to mention that ini files have been around far longer than "java properties". while not suitable for complex data they are perfectly suitable for simple config parameters. I also beg to differ... with[out] a prewritten xml parser, the ini file is far easier for the programmer.