Design of property and piece XML for V4

Ainulindale and I have recently been discussing in the IRC channel what we might do for representing piece and property data in V4. I’d like to present some of it here, in order to get comments and criticism. Please give this a read through and consider whether it covers the kinds of cases you’re likely to encounter in module construction.

First, a few notes:

  1. I’m purposely omitting anything to do with piece behavior, and being vague about how piece faces are connected to images in order to let us focus on one part of the problem, namely representing piece properties.

  2. I’m presenting elements in dependency order, so that in each example, all elements other than the one being defined have already been defined themselves. The structure will become clearer as you go.

  3. I’m not intending for the average module designer to look at the XML; for those users, it’s important that the XML support the kind of structure we want to expose in the module editor. But there will be users who want to manipulate the XML directly or with scripts, or will need to look at it for troubleshooting purposes, and for those users I want the XML to be readable, while still making complex things possible.

  4. What’s below is derived from what Ainulindale came up with two weeks ago, but he hasn’t seen my proposed templating system, so don’t assume he’s endorsing it. :slight_smile:

Now for the proposal:

Enumerations:

  <enum id="direction">
    <item>north</item>
    <item>south</item>
    <item>east</item>
    <item>west</item>
  </enum>

An enum element has an id which names it, and contains zero or more item elements which indicate the values contained in the enumeration. (If you’re familiar with C, C++, or Java, this is intended to have the same meaning as enums in those languages.) The purpose of an enum is to define a type with a limited range of values.

Properties:

  <stringProperty id="name" value="101 Airborne"/>
  <intProperty id="movement" value="4"/>
  <floatProperty id="angle" value="60.0"/>
  <enumProperty id="direction" value="north"/>

Each property element has an id attribute which names the property and a value attribute which provides the value of the property. The type of the value is encoded in the name of the property element. E.g., intProperty is intended for holding integers, stringProperty for holding strings, and so on. The permissible range of values for an enumProperty is the same as the items in the enum named by the enumProperty’s id attribute. (Question: Would it make more sense to have an “enum” attribute for enumProperty, so that the enum referred to need not have the same name as the enumProperty?) This isn’t intended to be an exhaustive list of property elements. (Question: What other types might we want? E.g., other numeric types—such as bool, or unsigned types, or maybe numeric types range-limited in other ways—or dates, or a refProperty which takes an id reference as a value.)

Faces:

  <face img="101 Abn front">
    ... properties ...
  </face>

A face element has an img attribute which refers to the image to be used for that face. Face elements may contain any number of property elements as children.

Pieces:

  <piece id="101 Airborne">
    <intProperty id="movement" value="4"/>
    ...
    <face img="">
      ...
    </face>
    ...
  </piece>

A piece may have any number of properties and any number of faces.

Templates:

Now for something abstract. A template establishes a pattern to be reused elsewhere. Here’s an example:

  <template id="infantry">
    <body>
      <enumProperty id="type" value="infantry"/>
      <intProperty id="movement allowance" value="4"/>
    </body>
  </template>

  <piece id="10/1/1">
    <use template="infantry"/>
  </piece>

The template element establishes a named block of XML which can be inserted elsewhere by reference. The use element indicates the location where the body of template it refers to should be inserted. Effectively, the above is equivalent to:

  <piece id="10/1/1">
    <enumProperty id="type" value="infantry"/>
    <intProperty id="movement allowance" value="4"/>
  </piece>

Old hands will recognize this as a V3 piece prototype. The templates I’m proposing here generalize prototypes somewhat, by accepting named parameters:

  <template id="infantry">
    <parameter id="MOVE"/>
    <body>
      <enumProperty id="type" value="infantry"/>
      <intProperty id="movement allowance" value="{MOVE}"/>
    </body>
  </template>

  <piece id="10/1/1">
    <use template="infantry">
      <parameter id="MOVE" value="4"/>
    </use>
  </piece>

I’ve added three things here: First, there is a parameter element in the template. The intent of this is to signal that the template expects to be called with a parameter named “MOVE”. Second, the use element now has a parameter element as a child with “MOVE” as its id (to match the parameter name in the template) and “4” as its value. Third, if you look into the template body, you can see “{MOVE}” as the value of the “movement allowance” property. This signals where the value of MOVE will be inserted when the template is expanded. This second template example is intended to define a piece equivalent to the one which the first example does.

Furthermore, it might be convenient for templates to specify default values for their parameters, like so:

  <template id="infantry">
    <parameter id="MOVE" default="4"/>
    <body>
      <enumProperty id="type" value="infantry"/>
      <intProperty id="movement allowance" value="{MOVE}"/>
    </body>
  </template>

This way, if the “infantry” template is used without a value for MOVE, MOVE will default to “4”.

More complex things are possible: A template may have multiple parameters. More than one parameter may be substituted into an attribute value (e.g., name="{OWNER} {SIZE} {TYPE}"). Templates may be nested. This:

  <template id="foo">
    <parameter id="X"/>
    <body>
      <intProperty id="x" value="{X}"/>
    </body>
  </template>

  <template id="bar">
    <parameter id="Y"/>
    <body>
      <use template="foo">
        <parameter id="X" value="{Y}"/>
      </use>
    </body>    
  </template>

  <use template="bar">
    <parameter id="Y" value="1"/>
  </use>

is equivalent to this:

  <intProperty id="x" value="1"/>

I’m not recommending that you write a simple property in such a complex way; rather this is an example showing one way one might compose templates.

The scope of template parameters is the entirety of body of the template where they are defined. Template parameter values are not inherited by templates used within other templates. If you’re familiar with C++ templates, you might be thinking this looks rather familiar. You’d be right, as I modeled this on C++ templates. (NB: The body element in templates could be dispensed with. I don’t see an obvious need for it right now.)

So, some questions:

Does this look sufficiently powerful to capture what we want to represent for pieces?

For those of you who might work with this by hand or with scripts, does this look like something you’d want to use?

Can you think of improvements to the syntax?

I’ve attached an example using the pieces from the game Battle for Moscow, to give you a sense of how this might look in practice.

On Sun, Sep 9, 2012 at 11:18 PM, uckelman uckelman@nomic.net wrote:

  1. What’s below is derived from what Ainulindale came up with two weeks
    ago, but he hasn’t seen my proposed templating system, so don’t assume
    he’s endorsing it. :slight_smile:

Likeable disclaimer :slight_smile:

> > > > > (Question: Would it make more sense to have an "enum" > attribute for enumProperty, so that the enum referred to need not have > the same name as the enumProperty?)

As I told you before, your use of the key of an enum as the id for the
instantiation of that enum seems to be a syntaxic abuse to me.
Plus, if we picture a piece such as a tank which will have a “direction”
it’s going to, as well as a direction he’s pointing to (being able to
rotate its guns), then we’d have two directions.
So in this specific case, I’d instantiate the property and define its type,
eg:

This isn’t intended to be an

exhaustive list of property elements. (Question: What other types might
we want? E.g., other numeric types—such as bool, or unsigned types, or
maybe numeric types range-limited in other ways—or dates, or a
refProperty which takes an id reference as a value.)

I think we’ll pretty much have to implement simple types such as int,
float, date, string, bool. After that we should apply constraints on the
elements.

For example let’s take my point about tanks and assume that the direction
of the guns is between 1 and 6, and due to the rotation, wraps at 1 when
going beyond 6:

This emulates pretty much the numeric dynamic property, and I think this
has some value.
Obviously we should come up with a syntax which will be transversal to
types (so maybe as child elements).

Templates:

Now for something abstract. A template establishes a pattern to be
reused elsewhere. Here’s an example:

What annoys me in your “template model” is that it is confusing if used in
the wrong way (as designers will obviously do).
Sure, we need to be able to refer to “rules” or behaviors from one piece to
another, that’s agreed upon. But we also need to define types of objects
which will be of the same nature, that is, for C++/Java/OO guys,
inheritance. Maybe they’re technically the same, but your way to explain
templates does not imply as much as I would like it to.

So for instance, let’s say I have unit pieces which will always have a
specific property for their hit points, as well as a specific face for when
they’re dead. I’d say:

So, to me, all major objects types should be templatable, doing a clear
distinction between an object type (face, piece, map) and a template (a
repeatable portion of XML). The former being of the same nature (one can
say “all units”), and the latter allowing concision in the code for
different pieces having the same behavior.
The next question is, should we treat such types as object inheritance or
interfaces, object-oriented wise? The latter may be more flexible IMHO.

So, some questions:

Does this look sufficiently powerful to capture what we want to
represent for pieces?

It’s yet to be less verbose in my opinion (see above).

For those of you who might work with this by hand or with scripts, does
this look like something you’d want to use?

Obviously yes, although it lacks // and ;;

Can you think of improvements to the syntax?

A lot but there’s not enough room in the margin :slight_smile:


Julien Cassignol
ainulindale.net

Uckelman asked me to clarify. Here’s the (hopefully effective)
clarification. Beware, it’s long.

First, please consider that I’m more inclined towards types because I think
that this enforces a way to design which I deem more desirable. It forces
the designer to structure its objects in terms of a hierarchical tree in
which objects have shared properties.
A good example is the units, we’ll have something such as :

         UNIT
  /                 \

INFANTRY VEHICLE
/
TANK BIKE

Translated: a bike is a vehicle, but also an unit. An infantry isn’t a
vehicle but is a unit. A tank is a vehicle but is not a bike.
Your typical object model.
The fact that one is strictly forced to model its thoughts using that kind
of thought process is of value, to me, in terms of what we allow and what
we will have to debug.

In terms of functionnality, Uckelman’s concepts as well as mine are, I
think, the same with more or less verbosity depending on the situation. I
just think that his is too much permissive or doesn’t give enough
information to the engine.
That’s why I think that having a type hierarchy in the XML, with “abstract”
objects extended by implementing objects, is easier.

In the following examples, I assume that parameters are transferrable
through hierarchy of template or type uses, as well as the usability of
“id” as a parameter.

Here’s an example. Consider 4 decks of cards, each with one color from 1 to
K:

Both solutions will share this:

...

My proposal:

...

Uckelman’s proposal:

...

Another example illustrating what I wrote before for units:


My proposal:


Uckelman’s proposal:

Now if we suppose that in scripts or even in XML, we’d like to implement
behaviors such as “impassable for vehicles” (lets say, a river), here comes
the difference: uckelman’s proposal will need to define a property to
define the type of the object. Mine won’t as it’s implicit in the
modelization.

Even though the functionnality is the same, I like to be able to say “a
river isn’t crossable by vehicles”, and see the same in the grammar, say,
hypothetical implementation:

I hope this gave you food for thoughts.


Julien Cassignol
ainulindale.net

I think you need to use code tags for us to see your examples.

I sure wish I could. I posted that through the mailing list, it seems it didn’t went through. Now I can’t edit for no reason.

Here are the concatenated posts:

Likeable disclaimer :slight_smile:

As I told you before, your use of the key of an enum as the id for the instantiation of that enum seems to be a syntaxic abuse to me.
Plus, if we picture a piece such as a tank which will have a “direction” it’s going to, as well as a direction he’s pointing to (being able to rotate its guns), then we’d have two directions.
So in this specific case, I’d instantiate the property and define its type, eg:

I think we’ll pretty much have to implement simple types such as int, float, date, string, bool. After that we should apply constraints on the elements.

For example let’s take my point about tanks and assume that the direction of the guns is between 1 and 6, and due to the rotation, wraps at 1 when going beyond 6:

<intProperty name="direction" value="1" minValue="1" maxValue="6" wrap="true" />

This emulates pretty much the numeric dynamic property, and I think this has some value.
Obviously we should come up with a syntax which will be transversal to types (so maybe as child elements).

What annoys me in your “template model” is that it is confusing if used in the wrong way (as designers will obviously do).
Sure, we need to be able to refer to “rules” or behaviors from one piece to another, that’s agreed upon. But we also need to define types of objects which will be of the same nature, that is, for C++/Java/OO guys, inheritance. Maybe they’re technically the same, but your way to explain templates does not imply as much as I would like it to.

So for instance, let’s say I have unit pieces which will always have a specific property for their hit points, as well as a specific face for when they’re dead. I’d say:

[code]

[/code]

So, to me, all major objects types should be templatable, doing a clear distinction between an object type (face, piece, map) and a template (a repeatable portion of XML). The former being of the same nature (one can say “all units”), and the latter allowing concision in the code for different pieces having the same behavior.
The next question is, should we treat such types as object inheritance or interfaces, object-oriented wise? The latter may be more flexible IMHO.

It’s yet to be less verbose in my opinion (see above).

Obviously yes, although it lacks // and ;;

A lot but there’s not enough room in the margin :slight_smile:

Uckelman asked me to clarify. Here’s the (hopefully effective) clarification. Beware, it’s long.

First, please consider that I’m more inclined towards types because I think that this enforces a way to design which I deem more desirable. It forces the designer to structure its objects in terms of a hierarchical tree in which objects have shared properties.
A good example is the units, we’ll have something such as :

             UNIT
      /                 \
INFANTRY              VEHICLE
                        /      \
                   TANK      BIKE

Translated: a bike is a vehicle, but also an unit. An infantry isn’t a vehicle but is a unit. A tank is a vehicle but is not a bike.
Your typical object model.
The fact that one is strictly forced to model its thoughts using that kind of thought process is of value, to me, in terms of what we allow and what we will have to debug.

In terms of functionnality, Uckelman’s concepts as well as mine are, I think, the same with more or less verbosity depending on the situation. I just think that his is too much permissive or doesn’t give enough information to the engine.
That’s why I think that having a type hierarchy in the XML, with “abstract” objects extended by implementing objects, is easier.

In the following examples, I assume that parameters are transferrable through hierarchy of template or type uses, as well as the usability of “id” as a parameter.

Here’s an example. Consider 4 decks of cards, each with one color from 1 to K:

Both solutions will share this:

<image id="1-hearts" img="image/1-hearts.png" /> <image id="2-hearts" img="image/2-hearts.png" /> ... <image id="K-spades" img="image/K-spbackK-spades.png" /> <image id="back" img="image/tubgirl.png" />

My proposal:

[code]

...




[/code]

Uckelman’s proposal:

<template id="card">
  <parameter id="COLOR">
  <body>
    <stringProperty id="color" value="{COLOR}" />
    <face id="front" img="{id}-{COLOR}" />
    <face id="back" img="back" />
  </body>
</template>

<template id="carddeck">
  <parameter id="COLOR"/>
  <body>
    <piece id="1" extends="card">
    <piece id="2" extends="card">
    <piece id="3" extends="card">
    ...
    <piece id="Q" extends="card">
    <piece id="K" extends="card">
  </body>
</template>

<deck id="hearts" extends="carddeck">
  <use template="deck">
    <parameter id="COLOR" value="hearts" />
  </use>
</deck>

<deck id="spades" extends="carddeck">
  <use template="deck">
    <parameter id="COLOR" value="hearts" />
  </use>
</deck>

<deck id="clubs" extends="carddeck">
  <use template="deck">
    <parameter id="COLOR" value="hearts" />
  </use>
</deck>

<deck id="diamonds" extends="carddeck">
  <use template="deck">
    <parameter id="COLOR" value="hearts" />
  </use>
</deck>

Another example illustrating what I wrote before for units:


My proposal:

[code]




[/code]

Uckelman’s proposal:

[code]

[/code]

Now if we suppose that in scripts or even in XML, we’d like to implement behaviors such as “impassable for vehicles” (lets say, a river), here comes the difference: uckelman’s proposal will need to define a property to define the type of the object. Mine won’t as it’s implicit in the modelization.

Even though the functionnality is the same, I like to be able to say “a river isn’t crossable by vehicles”, and see the same in the grammar, say, hypothetical implementation:

<token id="river"> <disallowedPieces> <piece type="vehicle" /> </disallowedPieces> </token>

I hope this gave you food for thoughts.

I have to comment on the xml syntax. It isn’t very … xml-ish. As I have developed xml consumers before I suggest to get it right from the get-go. I have combined suggestions from previous posts and my own points about the xml syntax to following:

<?xml version="1.0" encoding="UTF-8"?>
<gamebox xmlns="http://www.vassalengine.org/v4.xsd">
  <enum id="side">
   <item>SU</item>
   <item>DE</item>
  </enum>
  <template id="faces">
    <parameter id="FRONT"/>
    <parameter id="BACK"/>
    <parameter id="FULL"/>
    <parameter id="HALF"/>
    <body>
      <face>
        <img>{FRONT}</img>
        <property type="int" id="combat strength" value>{FULL}</property>
      </face>
      <face>
       <img>{BACK}</img>
       <property type="int" id="combat strength">{HALF}</property>
      </face>
    </body>
  </template>  

  <piece id="Soviet army" abstract="true">
      <property type="int" default="8" id="FULL"/>
      <property type="int" default="4" id="HALF"/>
      <property type="string" id="name"/>
      <property type="enum" ref="side">SU</property>
      <property type="int" id="movement allowance">4</property>
      <use ref="faces">
         <parameter ref="FRONT"><propertyvalue ref="name"/> front</parameter>
<!-- or maybe better with something like -->
         <parameter ref="BACK">{name} back</parameter>
      </use>
  </piece>
  <piece id="SU 1 Shock" extends="Soviet army">
    <property id="name">SU 1 Shock</property> <!-- This overrides "Soviet Army" property "name" -->
  </piece>
...

I will list my notes here:

  • xml declaration at the top
  • Namespace (xmlns) should be defined. It keeps the format in shape and xml validation is easy.
  • Keep values inside elements and metadata (data about data) on attributes (check the properties in my example)
  • Property type should be an attribute. I do not want to write xml parser that has to find all intproperties, stringproperties, enumproperties etc. I just want to enumerate over properties.
  • When you reference another element in the xml document, use ref="". Inside a node I thnk {property-id} is sufficient placeholder.
  <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.

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

Agreed, we’ve been omitting these to keep extraneous noise out of the examples.

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.

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:

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

<gamebox xmlns="http://www.vassalengine.org/v4.xsd" xmlns:bfm="http://www.vassalengine.org/mods/bfm/battleformoscow.xsd">
<pieces>
 <bfm:soviet_army abstract="true">
  <name>abstract</name> <!-- this is common for all pieces -->
  <properties>
   <bfm:movement_allowance>4</bfm:movement_allowance>
  </properties>
 </bfm:soviet_army>
 <bfm:su_1_shock extends="bfm:soviet_army">
  <name>SU 1 Shock</name>
 </bfm:su_1_shock>
</pieces>

That would be even more xml-ish but it splits the definition to two files (xml and xsd).

I actually made some example xsd and xml files. There is now vassal.xsd that defines the schema for pieces and their attributes. Then there is batformos.xsd and batformos.xml that define the game.

Thus spake alitur:

“uckelman” wrote:

Code:

{FRONT}

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.

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.

Actually the common schema (vassal.xsd) would be common for all modules. It only says that piece has to have some properties. That is common for all the modules. The “extra” schema would be just for the game specific properties. So instead of writing

<intProperty id="movement_allowance" minValue="0">5</intProperty>

where the property type and restrictions are in the tag, one could write the metadata to a different file (game.xsd) and the actual value to another (game.xml).

game.xsd
<xsd:element name="movement_allowance">
 <xsd:simpleType>
  <xsd:restriction base="xsd:int">
   <xsd:minExclusive value="0"/>
  </xsd:restriction>
 </xsd:simpleType>
</xsd:element>

game.xml
<movement_allowance>5</movement_allowance>

Okay, I have to admit the first one is easier to write. On the other hand the latter xml file is easier to read and does not contain all the metadata. The property definitions are also more reusable. Think of writing many pieces with movement_allowance.
Also, are these files really written by hand? One can also write an xslt that can do the transformation between those two formats.

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.

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

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.

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.

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.

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.

Hey,

I already built such a thing (xsd), check previous messages. Your
implementation is not strongly typed: property can be of both int and
string types, which doesn’t seem simple to handle properly both in terms of
validation and in the engine.
On Sep 14, 2012 2:07 PM, “alitur” juho.rutila@gmail.com wrote:

“uckelman” wrote:

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” wrote:

“alitur” wrote:

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:

Code:

-5

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” wrote:

“alitur” wrote:

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.


Read this topic online here:
https://forum.vassalengine.org/t/design-of-property-and-piece-xml-for-v4/5261/14


messages mailing list
messages@vassalengine.org
vassalengine.org/mailman/listinfo/messages

That is true. The engine needs the information about the property type. Maybe those stringProperties are the way to go.
One more point about xml I missed on my first message: the id attribute value should be unique in the document. So no two elements with same id.

On Fri, Sep 14, 2012 at 8:47 PM, alitur juho.rutila@gmail.com wrote:

That is true. The engine needs the information about the property type.
Maybe those stringProperties are the way to go.
One more point about xml I missed on my first message: the id attribute
value should be unique in the document. So no two elements with same id.

Indeed.
You should really check the XSD I did, it’s in that spirit :slight_smile:


Julien Cassignol
ainulindale.net

Well, for datatypes one should perhaps look at XML Schema and the already
defined XSD types.
For example, see
w3schools.com/schema/schema_ … umeric.asp

and the specs
w3.org/TR/2004/REC-xmlschema … tures.html
w3.org/TR/xmlschema-2/ (<
w3.org/TR/xmlschema-2/#built-in-datatypes>)

Tom,

On Tue, Sep 18, 2012 at 5:38 AM, Tom Russ taruss2000@gmail.com wrote:

Well, for datatypes one should perhaps look at XML Schema and the already
defined XSD types.
For example, see
w3schools.com/schema/schema_ … umeric.asp

We looked and used it.
As a reminder, check out
ainulindale.net/vassal/vassalengine.xsdwhich is what I did
based on our discussions with Uckelman, and which we
reviewed together.
This is only a basis for discussion, but it gives you an idea of what we
can do with XSD as well as in terms of grammar.


Julien Cassignol
ainulindale.net

Excellent.

(I should have looked at the DTD rather than just what was posted in this
thread.)

On Tue, Sep 18, 2012 at 12:05 AM, Julien Cassignol ainulindale@gmail.comwrote:

Tom,

On Tue, Sep 18, 2012 at 5:38 AM, Tom Russ taruss2000@gmail.com wrote:

Well, for datatypes one should perhaps look at XML Schema and the already
defined XSD types.
For example, see
w3schools.com/schema/schema_ … umeric.asp

We looked and used it.
As a reminder, check out
ainulindale.net/vassal/vassalengine.xsd which is what I did
based on our discussions with Uckelman, and which we reviewed together.
This is only a basis for discussion, but it gives you an idea of what we
can do with XSD as well as in terms of grammar.


Julien Cassignol
ainulindale.net


messages mailing list
messages@vassalengine.org
vassalengine.org/mailman/listinfo/messages