I also have trouble with uploading files here, so I got a webmatrix hosting for my tests. Here you can see the schemas I'm using in my PC. Look at them so we might start trying some UI/Server interaction next week.
Hm, they're fairly easy but I'm thinking I'll reupload when I add some comments (in a few minutes), so if you download them and don't get something just wait a little or post the question here.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
UpperSection is a bad name. It might be upper on character sheet, but there is no Up in XML ;). How about <bio>?
Wrapping every value inside a "Valor" attribute seems unnecessary. Why not record is as value, like <foo>1234</foo>? Descriptions are best left to nWoD books and are useless in computer-munched data files that only we will read.
Temporary/permanent attributes are best stored as two separate sections - one with complete "current" data, and the other with "persistent" stuff. Since we are going to munch each set pretty much independently (for instance, show only current or only permanent stats), splitting them would be somewhat cleaner.
Since Ghosts do not have all 9 stats, but rather just Power, Finesse and Resistance, why don't we go with the following kind of stat block?
Ghost version:
<stats type="current">
<power>5</power>
<finesse>3</finesse>
<resistance>4</resistance>
</stats>
Normal version:
<stats type="current">
<power>
<strength>3</strength>
<intelligence>2</dexterity>
<presence>3</stamina>
</power>
<finesse><!--snipped for brevity--></finesse>
<resistance><!--snipped for brevity--></resistance>
</stats>
Of course, if we tried to be very verbose, we could start using <physical>, <social> and <mental> tags instead of trait names (with real names hidden inside an attribute), but that appears to be an overkill.
I would prefer to see TType and TClass die. Those are way too clunky. If we want to know the type of an element, we should be able to look up it's ancestors (via XPath or whatever we will use).
Your Description attribute is not clean English word - it seems that first "i" is actually some weird accented version.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I used attributes instead of values because usually attributes use less bytes. Well, that and because the Intellisense made me type less when using attributes xD
The Bio part it's ok, I'll change that.
The descriptions are stored for merits that need them, like Contacts 2 (a policeman and a drug dealer). It's not there for storing what does the trait do (but maybe we could give anoption to the player to type down a short note on each trait, so he can keep there the data for quick reference).
The nice part about the schema is that most attributes aren't required, so you don't need to give value to the temporary value if the trait is permanent, and you can check if the trait is variable or pemanent by checking if it has the TemporaryValue attribute. And I think we need to display always both values (when you check your WP, you want to know your temporary WP but seeing the permanent is always good to keep in mind)
The ghosts will have their own schema, that inherits the "character" schema, so yes, they will have traits named "power" "finesse" and "resistance", completely different from the "human" traits. There will be the main "character" schema, "human" schema inherits "character", "vampire" inherits "human", "werewolf" inherits "human" and so on. Keep that in mind for the Java objects you load the XML on.
You're right on the TType TClass. They're removed on the OtherCharacter schema. Do you really think we need to store on every character sheet that Strength is a Physical Power Attribute? Since the elements must always be in the same order, we can put that part on the client logic (as in "the first attribute is intelligence, so I'll check it as Mental and Power Attribute. Here comes the second, it must be Wits, so i'll check it as Mental Finesse" and so on). I just don't see the need to keep it as data, because the computer already knows what each trait is.
On merits and maybe secondary skills it could be usefull to keep track of wich is Physical Mental or Social, but that's only if the rules have some difference between diferent types (<stupid example>all mental merits require that you spend 1 WP to activate</stupid example> then we would really need to know wich merit is mental)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Shaving off bytes by using attributes is somewhat damaging the "style" of document. While there is no hard and fast way to determine what should be an attribute or a text element, general recommendations seem to say that "important" content should be put in text elements, while data that is not essential and behind-the-scenes might be a candidate for attribute.
Shaving off size is a noble goal, but if you actually want to do this, you should drop XML first ;). XML was not designed to fit "minimal size" concept, and getting minimal size out of it is like jamming a square peg into round hole.
Description - I understand what it is for now. Thanks.
On temporary and permanent - still not convinced. By splitting temporary and permanent into two sections, we can have functions that do something with set of stats and don't need to know whether the stats are temporary or permanent. If we store stuff in different attributes, every function that works on stats will need to be passed the attribute name (as opposed to be simply given a branch of tree to work on).
TType and TClass - good riddance.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, I don't have any problem with using text elements instead of attributes, but then teh files will grow a lot bigger, and that means bandwith. I'm going to make a couple tests and then will post again.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You see, XML is not suited for low-bandwidth data transfer from the beginning. It is possible to modify a "regular" kind of schema to use somewhat less bandwidth (by using shorter tag and attribute names, and putting all data in attributes), but this is not going to help you much, since XML is quite ineffecient to begin with. Try comparing 3 hard numbers:
Amount of data you need to encode all 9 base stats in XML (attribute way).
Amount of data you need to encode all 9 base stats in XML (text element way).
Size of that 9 stat array if packed into binary.
[let's assume that both temporary and permanent value is stored]
For binary packing and one byte per stat (quite generous), we need 18 bytes. If we wanted, we could even get away with 9 (and hope that 15 dots is enough for everybody).
XML in attribute form would look like this:
<Attributes>
<Intelligence Value="5" Temp="5"/>
<Wits Value="5" Temp="5"/>
<Resolve Value="5" Temp="5"/>
<Strength Value="5" Temp="5"/>
<Dexterity Value="5" Temp="5"/>
<Stamina Value="5" Temp="5"/>
<Presence Value="5" Temp="5"/>
<Manipulation Value="5" Temp="5"/>
<Composure Value="5" Temp="5"/>
</Attributes>
for a total of 320 bytes (144 gzipped).
And a text element version looks like this:
<Attributes type="temporary">
<Intelligence>5</Intelligence>
<Wits>5</Wits>
<Resolve>5</Resolve>
<Strength>5</Strength>
<Dexterity>5</Dexterity>
<Stamina>5</Stamina>
<Presence>5</Presence>
<Manipulation>5</Manipulation>
<Composure>5</Composure>
</Attributes>
<Attributes type="permanent">
<Intelligence>5</Intelligence>
<Wits>5</Wits>
<Resolve>5</Resolve>
<Strength>5</Strength>
<Dexterity>5</Dexterity>
<Stamina>5</Stamina>
<Presence>5</Presence>
<Manipulation>5</Manipulation>
<Composure>5</Composure>
</Attributes>
for a total of 538 bytes (182 gzipped).
Gzip options: -n -9
Summing up:
Binary - 9 or 18 (depending on whether >15 dots is possible)
Attr XML: 144
Text XML: 182
If data size is important for us, it is a lot better to go binary for transmission. If it does not matter, we could use text element-based XML, since it is not that far away from attr-based and is easier to process.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I also have trouble with uploading files here, so I got a webmatrix hosting for my tests. Here you can see the schemas I'm using in my PC. Look at them so we might start trying some UI/Server interaction next week.
- The base character schema, with the common types definitions.
http://ankhmadriz.europe.webmatrixhosting.net/character.xsd
-The human schema, uses types from character
http://ankhmadriz.europe.webmatrixhosting.net/human.xsd
-This is a sample character sheet with all traits filled and so
http://ankhmadriz.europe.webmatrixhosting.net/JohnSmith.xml
-This is another character class that stores less data.
http://ankhmadriz.europe.webmatrixhosting.net/OtherCharacter.xsd
Hm, they're fairly easy but I'm thinking I'll reupload when I add some comments (in a few minutes), so if you download them and don't get something just wait a little or post the question here.
The best way to upload things to the server on a Win32 is to use Putty tools.
search putty on google and download putty.zip.
There is a tool called pscp.exe
this is a secure copy program.
in CMD , run
pscp.exe name-of-files username@sourceforge.net:/home/groups/n/nw/nwdo/htdocs
This should do it.
I'm all about the interface and server interaction =)
do you have any good programming examples on how I can connect to your xml webservice and get information?
"above the earth, beneath the sky"
- Daedius
lol, just read through your schemas, great job =)
Hm, hadn't seen this post. In 10 minutes I'll post some links on connecting to a webservice on java.
http://www-106.ibm.com/developerworks/webservices/library/ws-appwsif.html
This seems like good, with some code samples and everything. Try it out, and if you don't get it, google it! xDDDD
Here are some comments for you:
UpperSection is a bad name. It might be upper on character sheet, but there is no Up in XML ;). How about <bio>?
Wrapping every value inside a "Valor" attribute seems unnecessary. Why not record is as value, like <foo>1234</foo>? Descriptions are best left to nWoD books and are useless in computer-munched data files that only we will read.
Temporary/permanent attributes are best stored as two separate sections - one with complete "current" data, and the other with "persistent" stuff. Since we are going to munch each set pretty much independently (for instance, show only current or only permanent stats), splitting them would be somewhat cleaner.
Since Ghosts do not have all 9 stats, but rather just Power, Finesse and Resistance, why don't we go with the following kind of stat block?
Ghost version:
<stats type="current">
<power>5</power>
<finesse>3</finesse>
<resistance>4</resistance>
</stats>
Normal version:
<stats type="current">
<power>
<strength>3</strength>
<intelligence>2</dexterity>
<presence>3</stamina>
</power>
<finesse><!--snipped for brevity--></finesse>
<resistance><!--snipped for brevity--></resistance>
</stats>
Of course, if we tried to be very verbose, we could start using <physical>, <social> and <mental> tags instead of trait names (with real names hidden inside an attribute), but that appears to be an overkill.
I would prefer to see TType and TClass die. Those are way too clunky. If we want to know the type of an element, we should be able to look up it's ancestors (via XPath or whatever we will use).
Your Description attribute is not clean English word - it seems that first "i" is actually some weird accented version.
I used attributes instead of values because usually attributes use less bytes. Well, that and because the Intellisense made me type less when using attributes xD
The Bio part it's ok, I'll change that.
The descriptions are stored for merits that need them, like Contacts 2 (a policeman and a drug dealer). It's not there for storing what does the trait do (but maybe we could give anoption to the player to type down a short note on each trait, so he can keep there the data for quick reference).
The nice part about the schema is that most attributes aren't required, so you don't need to give value to the temporary value if the trait is permanent, and you can check if the trait is variable or pemanent by checking if it has the TemporaryValue attribute. And I think we need to display always both values (when you check your WP, you want to know your temporary WP but seeing the permanent is always good to keep in mind)
The ghosts will have their own schema, that inherits the "character" schema, so yes, they will have traits named "power" "finesse" and "resistance", completely different from the "human" traits. There will be the main "character" schema, "human" schema inherits "character", "vampire" inherits "human", "werewolf" inherits "human" and so on. Keep that in mind for the Java objects you load the XML on.
You're right on the TType TClass. They're removed on the OtherCharacter schema. Do you really think we need to store on every character sheet that Strength is a Physical Power Attribute? Since the elements must always be in the same order, we can put that part on the client logic (as in "the first attribute is intelligence, so I'll check it as Mental and Power Attribute. Here comes the second, it must be Wits, so i'll check it as Mental Finesse" and so on). I just don't see the need to keep it as data, because the computer already knows what each trait is.
On merits and maybe secondary skills it could be usefull to keep track of wich is Physical Mental or Social, but that's only if the rules have some difference between diferent types (<stupid example>all mental merits require that you spend 1 WP to activate</stupid example> then we would really need to know wich merit is mental)
Shaving off bytes by using attributes is somewhat damaging the "style" of document. While there is no hard and fast way to determine what should be an attribute or a text element, general recommendations seem to say that "important" content should be put in text elements, while data that is not essential and behind-the-scenes might be a candidate for attribute.
Shaving off size is a noble goal, but if you actually want to do this, you should drop XML first ;). XML was not designed to fit "minimal size" concept, and getting minimal size out of it is like jamming a square peg into round hole.
Description - I understand what it is for now. Thanks.
On temporary and permanent - still not convinced. By splitting temporary and permanent into two sections, we can have functions that do something with set of stats and don't need to know whether the stats are temporary or permanent. If we store stuff in different attributes, every function that works on stats will need to be passed the attribute name (as opposed to be simply given a branch of tree to work on).
TType and TClass - good riddance.
Well, I don't have any problem with using text elements instead of attributes, but then teh files will grow a lot bigger, and that means bandwith. I'm going to make a couple tests and then will post again.
You see, XML is not suited for low-bandwidth data transfer from the beginning. It is possible to modify a "regular" kind of schema to use somewhat less bandwidth (by using shorter tag and attribute names, and putting all data in attributes), but this is not going to help you much, since XML is quite ineffecient to begin with. Try comparing 3 hard numbers:
Amount of data you need to encode all 9 base stats in XML (attribute way).
Amount of data you need to encode all 9 base stats in XML (text element way).
Size of that 9 stat array if packed into binary.
[let's assume that both temporary and permanent value is stored]
For binary packing and one byte per stat (quite generous), we need 18 bytes. If we wanted, we could even get away with 9 (and hope that 15 dots is enough for everybody).
XML in attribute form would look like this:
<Attributes>
<Intelligence Value="5" Temp="5"/>
<Wits Value="5" Temp="5"/>
<Resolve Value="5" Temp="5"/>
<Strength Value="5" Temp="5"/>
<Dexterity Value="5" Temp="5"/>
<Stamina Value="5" Temp="5"/>
<Presence Value="5" Temp="5"/>
<Manipulation Value="5" Temp="5"/>
<Composure Value="5" Temp="5"/>
</Attributes>
for a total of 320 bytes (144 gzipped).
And a text element version looks like this:
<Attributes type="temporary">
<Intelligence>5</Intelligence>
<Wits>5</Wits>
<Resolve>5</Resolve>
<Strength>5</Strength>
<Dexterity>5</Dexterity>
<Stamina>5</Stamina>
<Presence>5</Presence>
<Manipulation>5</Manipulation>
<Composure>5</Composure>
</Attributes>
<Attributes type="permanent">
<Intelligence>5</Intelligence>
<Wits>5</Wits>
<Resolve>5</Resolve>
<Strength>5</Strength>
<Dexterity>5</Dexterity>
<Stamina>5</Stamina>
<Presence>5</Presence>
<Manipulation>5</Manipulation>
<Composure>5</Composure>
</Attributes>
for a total of 538 bytes (182 gzipped).
Gzip options: -n -9
Summing up:
Binary - 9 or 18 (depending on whether >15 dots is possible)
Attr XML: 144
Text XML: 182
If data size is important for us, it is a lot better to go binary for transmission. If it does not matter, we could use text element-based XML, since it is not that far away from attr-based and is easier to process.