Design of property and piece XML for V4

[alitur]

@uckelman

The extra schema is precisely what I’m objecting to. If it’s user-supplied, then we no longer have any assurance that it we’re getting valid data.

I actually managed to write an vassal.xsd file that demands the property tags to be for example integer type or string types (see attachment). So now the module writer cannot write the game.xsd wrong (and thus game.xml) and Vassal engine always knows that it will be getting string or integers from the properties tag. So, even though the module builder provides the schema, it still has to obey vassal.xsd.

@uckelman

@alitur

Also, are these files really written by hand?

Some will be. And we will definitely spend some time examining them to find module bugs, written by hand or not.

By writing the game files with schema in mind the file validates itself. I think xsd does not support for example validating following tag:

<intProperty name="movement_allowance" minValue="0">-5</intProperty>

That line will break in the Vassal xml parser or even deeper (-5 < 0). If there would be schema behind properties, their validation would happen in the xml editor.

@uckelman

@alitur

One can also write an xslt that can do the transformation between those two formats.

I can. But I don’t expect that the average module designer can, nor to I expect that the average module designer can write a correct schema. (I don’t expect that we’re going to devise an editor which generates schemata, either.) If we’re setting up a system where the hard things have to be done for each module by nonexperts rather than once by experts, then we’re setting up a system which is doomed to fail.

My point here was that by providing the xslt (which does not have to be game specific, just common) vassal could provide and take in “human-friendly” xml and also “machine-friendly” xml+xsd. Although, don’t know if this just messes things up more.