XML element ordering

[IBBoard]

Currently, a lot of elements in the schema/files can be in any order (e.g. unit stats don't have to come before equipment). I did that originally because we didn't need to force an order. The down-side is that it constrains the ease of extensibility (we've got to have a special tag to contain extensions). Does anyone make use of the ability to have race definition tags in any order, or is it an unnecessary leniency? I'm just thinking about post-v0.1, extensibility and ease of use vs ease of coding again

[snowblizz]

Assuming that we eventually get an editor it will not matter that there are underlying "requirements" as to the order of the XML tags. I put them in the "correct" order for no other reason than they were listed so.

Would this enable the program to be more informative as to the issues in tags? I was adding equipment to units yesterday and had a bug I just didn't want to find. Turned out the copy/paste led to </unitequipment> coming before some <unitequipmentitem> tags the program and loading it in a browser could only tell me it was a problem with </unitequipment> on line xxx, and unfortunately that xxx line wasn't exactly the same in any editor I tried. Ie if it says line 965 it could be anything from say 940-990. Or even more (likely less but with lots of lines and only a vague problem description the bug was persistent). Took me a while to find that damned extra tag.

[IBBoard]

I'm not sure it'd help with the line numbers (which are normally correct for most problems, but a closing tag for an element that isn't opened may point to something other than the incorrect closing element) but it'd help keep the files more easily extensible. It'd still be possible with the structure we have, but just a little more complex.

As you said, once we get an editor then it won't be a problem what the ordering is as it'll always get it right. I guess the problem is finding the time for all the features that you want and the editor

[furrie]

I use the same order as snowblizz for my race files, so that shouldn't be a problem.

[IBBoard]

Good - I'd already committed some changes, since Snowblizz's point about the editor made sense

[IBBoard]

Do we need anything else in the XML for a unit? I'm at a rather annoying point right now, having wasted a good chunk of the day on XML-related stuff.

Currently everything compiles and runs fine in Mono/MonoDevelop, but I've just tested it in Visual Studio and it seems it gets upset with the schemas. Basically, because we've got lots of optional tags and then a special "any" value in the schema then MS' .Net gets confused as to whether the XML element "race:unitAbilities" refers to the "race:unitAbilities" definition or the undefined "any".

It looks like this situation (which has quite an obvious solution - if it is specifically defined then use it) is fixed by the Xml Schema standard v1.1, but Microsoft are, of course, lagging on picking it up. The two alternatives are:

1) Go back to the ugly arbitrary "core:other" element to contain the "any" so that it doesn't get confused
2) Put something in just before the "any" that isn't optional
3) Pray for a miracle and hope that MS will back-port Xml Schema 1.1 to .Net 2.0 and later

It may be that I have to accept the use of (1) in some situations. I think I'll be dead before 3) happens, and 2) is possible but means that we a) need a non-optional element and b) break all existing data files.

Gah! So damned frustrating that development isn't going as fast as I want anyway and then the XML fights back >:(

[snowblizz]

Do we need anything else in the XML for a unit?

Such as? It's 9am on a Sunday and I'm awake having been up till 3am so I'm a bit blunt...
could you expand on that perchance.

There's stuff I'd like to see but I'm not sure they are XML related though.

[IBBoard]

Nothing in particular - it was more just an irrational and irritated stab at what I could do to fix the problem. At the end of the day, the schema is about correct as it stands and doesn't really need any extra elements (certainly not fixed ones) but that's what MS .Net needs to make it handle the existing schemas "properly" (as Mono does).

I'm going to look at some alternatives I'd found before and see if they resolve anything.