Which XML module?

Hallo :-)

I'm looking at creating a format to store MaxGUI control layouts and settings which will become a base to generate code from.
I thought XML would be the best choice for persisting this data.

Are there many XML modules about for Max yet?
And do they work? :-)

Something that doesn't require a lot of code to create the node trees, and retrieve information from them, would be ideal.

what might you recommend?
thanks :-)

Although it's not a max module, the libxml2 has been put forward a few times as a decent, free, cross-platform XML module that would be good to provide a Max wrapper for. Not sure if that helps you much...

There's an idea for the weekend... never done wrappers before... I don't suppose I need to know *much* C to do it?

Will have a play anyways... what's the worst I can do? ;-)

Thanks.

Don't know how much it would help, but I wrote an HTML parser (not really a parser, more a tokenizer) thingy, it should work for XML as well (although it won't validate it).

I wrote one, I can send it to you if you want.

Take a look here:

http://www.blitzmax.com/Community/posts.php?topic=53834

I'm of the opinion that mine is better. ^_^

i would like to see a BRL module based on Libxml2 as it is complete, fast and open source.

In the same way that the LUA module is now a public module distributed with max, I see no reason why a libxml2 based module couldn't do the same. I believe skid may have previously given a tacit nod towards libxml2...

Now people... no fighting :-p
I'm sure one is as good as the other...

Official support for something would probably be good in the long term.

Try Noels. I can't vouch for it myself (haven't tried it), but people usually seem to like his stuff.

I would like a copy Noel

Naturally, I would reccomend mine:
MaXML


Why don't you upload yours? Then anyone will have the opertunity to choose for themselves.

I'm also interested in how yours is better than mine. Is it easier to use? Is is faster? Or does it only comply more fully to the XML standard?

the gauntlet has been thrown.

always nice to see a friendly competition.

I have used John J's MaXML and for my purposes it worked very well and was pretty fast.

If Noel would post a link to his library i would like to compare them.

anyway, XML can be very complicated. Most Blitz programmers (doing games, editors and small apps) will not need many of the advanced features.

for most of us, XML is just a nice way to save and load game data such as levels, graphics settings, scores, etc

Yes, yes, no. I don't care for standards when it comes to this work. As long as I can do <material name="blah"><property id="fooz"/></material> I'm happy.

Edit: And to cover a few other things..



Because I'm only going to give it to people who ask for it.



I release it on a per-request basis. Plus, since they're both free, I'm not going to actually compete with JohnJ's, since I was being humorous when I said mine was better.

Of course it would be fastest if you just stored in binary like:
1A

Where the number 1 represents material "blah" and the letter A represents property fooz. It would only take 2 bytes of space vs. 54 bytes of XML which also requires more processing. Binary is not really an issue as long as the specification is made public or sometimes for like say a dictionary there is really no need for a specification.

I just think XML is overhyped, I got tons of programs that store and retrieve data just fine without XML and they probably work faster for it.

Faster, yes.
More portable and extendable, no.

The idea is to make something that is easy to modify without having to write loads of editors for each format. Most software will compile a binary version of an Xml document and use that when no changes have been made to the document. Thus, all the benefits of having a human-readable format and the speed of binary.

As for filesize, you'll have to make some compromises. If ~200kb for all the Xml files is that big of a deal to you, you obviously won't use it.

You could of course zip them.

Extendability is quite a useful thing to have, I think.
For example, imagine you have something like this :

<control type="pushbutton">
	<attributes>
		<string name="name">button1</string>
		<int name="posX">10</int>
		<int name="posY">10</int>
		<int name="posWidth">10</int>
		<int name="posHeight">10</int>
		<color name="foreColor" use="true">
			<red>255</red>
			<green>0</green>
			<blue>0</blue>
		</color>
		<font name="font">
			<name>Arial</name>
			<size>12</size>
			<style>normal</style>
		</font>
	</attributes>
</control>

It's very easy to create a new attribute type and simply add it to whichever control-type might need it. The nice thing is that you can add extra tags that one particular program might not bother about and just ignore it.
You can also read the format without the need for a document which describes what the 3rd byte in every 6th block of 238 bytes is for... (indeed, it is practically self-documenting)
And because it is portable, if you required a need to transform the data for use elsewhere, there are lots of neat little toys that can do this for you with relative ease. Otherwise, you'd have to code converters for your very-custom binary format.
You can also, with XML, tweak data in your favourite text editor. It's great for throwing ideas at.... create some tags, add some attributes... ooh, nice schema for doing such and such... whereas you can't really make a binary format up as you go along. (unless you are microsoft and are creating a text-document format).

I wouldn't use XML for real-time game data storage - that's what types and variables are for. The only speed issue with XML files comes up during loading and saving. So far I've never had a problem with the speed of BlitzXML or MaXML, and I've tested it with files up to 1MB, which parse in a few seconds.


I agree.

Awesome work John! I might give it a go :)

I worked professionally withXML doing webservices and client apps and at one point we had some huge rules lists (in XML) and we simply had to convert it to a binary implementation of XML as loading these huge files would slow down the program startup too much.

Once loaded, it's fast enough though

Indeed, we've had issues with large XMLs where I work also.
Throwing chunky XML streams over the internet isn't always a good idea.

But for storing data in files, it is quite a capable format.