[messages] [Developers] Design of property and piece XML for V4

Joel Uckelman uckelman at nomic.net
Fri Sep 14 01:36:44 MST 2012


Thus spake alitur:
> 
> "uckelman" wrote:
> > 
> > Code:
> > 
> >   <img>{FRONT}</img>
> > 
> > 
> > 
> > My reason for having no contents for img elements is that they're all
> > intended to be references to images defined elsewhere.
> > 
> 
> Yeah, I wasn't 100% sure about this. Can you explain why a piece knows
> its image and not the other way round? Because the image itself is not
> essential part of the "piece" concept. There could be for example
> different tilesets representing pieces. I think that piece should not
> reference image at all.
>

A piece face doesn't know what image it has---it knows an image ID. What
image a particular ID refers to will depend on the image definition file
which is loaded, so the way I've defined it already supports multiple
imagesets.

I see your point about keeping presentation information out of the
formal definitions of piece faces, but I'm worried that having the
association betwen piece faces and images elsewhere could be error
prone, tedious and more verbose. E.g., you'd need to give each face an
id

> <face id="SU 1 Shock front"/>

and then you'd have to have an image mapping

> <img src="some.svg" face="SU 1 Shock front"/>

Hmm. I'll have to think about this.

> "uckelman" wrote:
> > 
> > 
> > Code:
> > 
> >   <property type="int" id="movement allowance">4</property>
> > 
> > 
> > 
> > How would you validate that the contents of property elements are the
> > correct type this way? Ainulindale brought this up over IRC this
> > evening.
> > 
> 
> 
> Huh, did a lot of googling and I think I stepped in a trap here. It
> indeed is not possible to give the element type in an attribute. On the
> other hand those "stringproperty"-tags also seemed odd to me. How about
> this:
> 
> Code:
> 
> <gamebox xmlns="http://www.vassalengine.org/v4.xsd"
> xmlns:bfm="http://www.vassalengine.org/mods/bfm/battleformoscow.xsd">
> <piece id="Soviet army" abstract="true">
>  <name>abstract</name> <!-- this is common for all pieces -->
>  <properties>
>   <bfm:movement_allowance>4</bfm:movement_allowance>
>  </properties>
> </piece>
> 
> 
> 
> 
> Now the properties of the piece could be found under the properties tag.
> Property name would be the element name. The validation that
> movement_allowance should be int could be defined in
> battleformoscow.xsd. But is this only leading us to the next step?

This prefents us from having a common schema for all modules. Creating
a correct schema isn't easy, and having that will save us endless
trouble from bad input. An incorrect schema means that we can't trust
the integrity of the input we get. Few module designers will have ever
heard of schmata, let alone be able to create ones which have no holes.
 
-- 
J.


More information about the messages mailing list