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

uckelman uckelman at nomic.net
Fri Sep 14 01:39:42 MST 2012

[This message has been edited.]

Thus spake alitur:
> "uckelman" wrote:
> > 
> > Code:
> > 
> >   {FRONT}
> > 
> > 
> > 
> > My reason for having no contents for img elements is that they're
> > 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

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


<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.

> Now the properties of the piece could be found under the properties
> 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.

Read this topic online here:

More information about the messages mailing list