# [ d20statblock.org ] a grammar



## jmettraux (Aug 28, 2002)

> _Originally posted by CRGreathouse_
> > If I have some time, I will come up with a grammar describing your
> > standard.
> 
> ...




So I've come up with a first draft of this standard d20statblock  grammar.

I've put it in a CVS tree, so it's version controlled.

You can find it here :

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dgsh/dgsh/import_samples/standard.ebnf

(direct link to the latest version : http://cvs.sourceforge.net/cgi-bin/...rev=HEAD&content-type=text/vnd.viewcvs-markup)

Comments and corrections are welcome.


----------



## CRGreathouse (Aug 28, 2002)

Does anyone else feel like brushing up on EBNF?


----------



## MJEggertson (Aug 28, 2002)

EBNF? Is that some sofware thingy that's preventing the links from working?

The acronym-impaired,
-Mike


----------



## CRGreathouse (Aug 29, 2002)

MJEggertson said:
			
		

> *EBNF? Is that some sofware thingy that's preventing the links from working?*




It stands for (_CRGreathouse cuts and pastes_) Extended Backus-Naur Form.  It's kind of like a DTD - it defines a particular language or format.


----------



## MJEggertson (Aug 29, 2002)

Hehehe. I definitely don't blame you on needing to copy and paste that. Good one.


----------



## jmettraux (Aug 29, 2002)

new version of the grammar issued, the usual links are still :
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dgsh/dgsh/import_samples/standard.ebnf
http://cvs.sourceforge.net/cgi-bin/...rev=HEAD&content-type=text/vnd.viewcvs-markup
The diff to the previous version : 
http://cvs.sourceforge.net/cgi-bin/...port_samples/standard.ebnf.diff?r1=1.1&r2=1.2



The goals of this grammar :

1) define a standard stat block exactly  And be able to discuss the subtleties of the standard more easily

2) be used to generate stat block parsers 

2b) validate stat blocks as being 'standard' 


Comments and corrections on the grammar and its goals are welcome.


----------



## CRGreathouse (Aug 29, 2002)

jmettraux said:
			
		

> *be used to generate stat block parsers *




Do you have a good parser generator?  I've been trying to get one to work, but no such luck so far.


----------



## jmettraux (Aug 29, 2002)

CRGreathouse said:
			
		

> *
> 
> Do you have a good parser generator?  *




Some hints here :

http://catalog.compilertools.net/lexparse.html
http://www.first.gmd.de/cogent/catalog/java.html

It seems the variety of EBNF I currently use is not the right one for the tools available on these URLS. Anyway, adaptation shall be easy as soon as we find the right tool.


----------



## jmettraux (Aug 29, 2002)

This might also be useful :

http://www.gnu.org/manual/bison/html_mono/bison.html


----------



## Leopold (Aug 29, 2002)

also if you guys have all the monsters and stuff in statblock format and stuff from SRD posted it would be a GREAT help to the community.


I know you are trying to set a standard here but if you could take, say the monster manual, and convert it into statblock or even the Creature collection that would be awesome!


----------



## CRGreathouse (Aug 29, 2002)

jmettraux said:
			
		

> *It seems the variety of EBNF I currently use is not the right one for the tools available on these URLS. Anyway, adaptation shall be easy as soon as we find the right tool. *




Yeah, each one's different.  I wouldn't worry about it; I'll have to make minor changes afetr the fact anyway.



			
				Leopold said:
			
		

> *also if you guys have all the monsters and stuff in statblock format and stuff from SRD posted it would be a GREAT help to the community.
> 
> 
> I know you are trying to set a standard here but if you could take, say the monster manual, and convert it into statblock or even the Creature collection that would be awesome! *




I'd like to do this some time.  Perhaps the SRD information is written well enough that I could parse it directly (with a program I have yet to write), but until then there are others who have put the MM into less predictable, but still useful stat blocks.


----------



## jmettraux (Aug 29, 2002)

Leopold said:
			
		

> *also if you guys have all the monsters and stuff in statblock format and stuff from SRD posted it would be a GREAT help to the community.
> 
> 
> I know you are trying to set a standard*




Of course it would be a perfect _pivot_ format.

People could also exchange their character sheets and their NPCs among all the progs supporting this format.

I'm sure Eric is working on an XSL doc for outputting eTools characters into the _standard_.

When I downloaded PCGEN's 3.0.0, I couldn't find any stat block template for export, is it included in 3.1.0 now ?


----------



## CRGreathouse (Aug 29, 2002)

jmettraux said:
			
		

> *When I downloaded PCGEN's 3.0.0, I couldn't find any stat block template for export, is it included in 3.1.0 now ? *




I was working on a PC Gen standard stat block output, but the template is restrictive - there are things that are hard-coded that prevent full compliance.


----------



## jmettraux (Aug 29, 2002)

CRGreathouse said:
			
		

> *
> 
> I was working on a PC Gen standard stat block output, but the template is restrictive - there are things that are hard-coded that prevent full compliance. *




Could you write a small report of those hard-coded things you encountered : it could speed up PC Gen developers. 
I know it's not their priority right now...
But being able to generate a [N]PC with PC Gen and then do 'in flight' management with dgsh or RPM is .

Please !


----------



## jmettraux (Aug 29, 2002)

Another version of the grammar :

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dgsh/dgsh/import_samples/standard.ebnf
http://cvs.sourceforge.net/cgi-bin/...rev=HEAD&content-type=text/vnd.viewcvs-markup

diff:
http://cvs.sourceforge.net/cgi-bin/...port_samples/standard.ebnf.diff?r1=1.2&r2=1.3


Charles, could you validate my assumptions about the 'Spd' elements ?

Could you also validate this stat block :



> Variant Orc: CR 1/2; Medium-size Humanoid; hd 1d8; hp 4; Init +1; Speed 20 ft, climb 15 ft, base 30 ft, climb 20 ft; AC 15; Melee longsword +2 (1d8/crit 19-20); Melee battle axe (1d8/crit x3); Ranged short bow +2 (1d6/crit x3); SQ low-light vision, light sensitivity; SV Fort +2, Ref +1, Will -1; Str 12, Dex 13, Con 11, Int 8, Wis 8, Cha 7.
> 
> Skills and Feats: Listen +4, Spot +3; Alertness.




Thanks !


----------



## CRGreathouse (Aug 29, 2002)

jmettraux said:
			
		

> *Variant Orc: CR 1/2; Medium-size Humanoid; hd 1d8; hp 4; Init +1; Speed 20 ft, climb 15 ft, base 30 ft, climb 20 ft; AC 15; Melee longsword +2 (1d8/crit 19-20); Melee battle axe (1d8/crit x3); Ranged short bow +2 (1d6/crit x3); SQ low-light vision, light sensitivity; SV Fort +2, Ref +1, Will -1; Str 12, Dex 13, Con 11, Int 8, Wis 8, Cha 7.
> 
> Skills and Feats: Listen +4, Spot +3; Alertness.*




Variant Orc: CR 1/2; Medium-size Humanoid (orc); HD 1d8; hp 4; Init +1; Speed 20 ft, climb 15 ft; AC 15 (+1 Dex, +4 scale mail); Melee longsword +2 (1d8+1/crit 19-20), battleaxe +2 (1d8+1/crit x3); Ranged short bow +2 (1d6/crit x3); SQ low-light vision, light sensitivity; SV Fort +2, Ref +1, Will -1; Str 12, Dex 13, Con 11, Int 8, Wis 8, Cha 7.

Skills and Feats: Listen +4, Spot +3; Alertness.

****

A shortcoming (in my opinion) of the format is that it does not include base speed.  Perhaps this should be changed: it was originally chosen because it was easy to figure out, but with classed monsters, it's not so easy.

The two lines between "Cha 7." and "Skills and Feats" aren't required (only one is needed), but it's allowed.

I'll have to tweak these eventually, to account for the 3 possible formats (like HTML's transitional, frameset, and strict).


----------



## CRGreathouse (Aug 29, 2002)

jmettraux said:
			
		

> *This might also be useful :
> 
> http://www.gnu.org/manual/bison/html_mono/bison.html *




I wasn't having any luck downloading this.  Is it just me, or is the link dead?

Edit: The doenload link, not the link you provided.


----------



## DMFTodd (Aug 29, 2002)

> I'm sure Eric is working on an XSL doc for outputting eTools characters into the standard.




I had a fan put one together for DM's Familiar already. You can find it on the DMF webpage, download section.

There's a PCGen sheet there as well that does a standard stat block.




> But being able to generate a [N]PC with PC Gen and then do 'in flight' management with dgsh or RPM is .




What's DM's Familiar, chopped liver  ? DMF can already do this for PCGen and E:Tools.


----------



## jmettraux (Aug 30, 2002)

DMFTodd said:
			
		

> *
> 
> What's DM's Familiar, chopped liver  ? DMF can already do this for PCGen and E:Tools. *




Sorry, I didn't mention your product 

The bravest logo dragon is yours.

And DM Familiar is listed in d20statblock.org's supporters.

All my excuses to you, Todd.


----------



## jmettraux (Aug 30, 2002)

CRGreathouse said:
			
		

> *
> 
> The two lines between "Cha 7." and "Skills and Feats" aren't required (only one is needed), but it's allowed. *




<=>



> statBlock:	headSection newLine skillsAndFeatsSection newLine specialSection newLine spellsPreparedSection+ newLine domainSpellsSection newLine knownSpellsSection+ newLine equipmentSection
> 
> newLine:	("\n" | "\n\n")


----------



## Luke (Aug 30, 2002)

I think codifying things to the point of having them in some kind of BNF/EBNF/DTD is a great idea.

I think there are some important areas not yet covered by the style guide, and it's mostly because of the informality of the approach.

For example:
- How are templates supposed to be displayed (eg. Half-Dragon)?
- How are special powers supposed to be described in magical weapons or armor (eg "+2 longsword (defending)")?

If things can be better codified, and that becomes standard, it also helps "corral" d20 publishers creating new material. This makes more likely that new material will fit a well defined "database format".

Coming from another angle, For compl

Regards,


----------



## CRGreathouse (Aug 30, 2002)

Luke said:
			
		

> *I think codifying things to the point of having them in some kind of BNF/EBNF/DTD is a great idea.*




Yeah, so do I.  I was thinking of making a DTD, but never actualy did anything.   Jmettraux's been doing everything - thanks a ton,  jmettraux! 



			
				Luke said:
			
		

> *- How are templates supposed to be displayed (eg. Half-Dragon)?
> - How are special powers supposed to be described in magical weapons or armor (eg "+2 longsword (defending)")?*




I'll certainly work on this, but not until the basics are covered.  the nice thing about ENBF is that it's easy to work with - anyone can tweak them once they're set up.



			
				Luke said:
			
		

> *If things can be better codified, and that becomes standard, it also helps "corral" d20 publishers creating new material. This makes more likely that new material will fit a well defined "database format".*




That's my hope!


----------



## MJEggertson (Aug 31, 2002)

I'm very intersted in all this, and it's actually on my list of things I want to do for my project. Although, it's a more distant goal. My current understanding of xml (etc...) is pretty minimal, so I'm trying to implement other things first.

I've been looking for a formal standard to emerge, and my lack of kowledge of these markups (and limited time to learn) has kept me at lurker status in all these discussions.

/me watches with confused interest.

But I do think an agreed standard would go a long way to making everyone's software much more accepted. Most people, it seems, like every piece of software for a few reasons, and don't use any one product exclusively. Transparent data-porting I think would be a great goal for everyone to work on.


----------



## jmettraux (Aug 31, 2002)

CRGreathouse said:
			
		

> *
> ...Bison...
> 
> I wasn't having any luck downloading this.  Is it just me, or is the link dead?
> ...




Charles,

Go to http://www.cygwin.com/ and install cygwin, you'll have all the unix tools on your windows desktop. If you need assistance for the installation, just send me a private email.

But, well... I don't think you will need bison right away, we want to turn your standard vision into a "E"? "BNF" document at first, any parser will come later. So your  referee skills are required now 


- The grammar -

Latest version :
http://cvs.sourceforge.net/cgi-bin/...?rev=1.5&content-type=text/vnd.viewcvs-markup
Diff :
http://cvs.sourceforge.net/cgi-bin/...port_samples/standard.ebnf.diff?r1=1.3&r2=1.5


----------



## CRGreathouse (Aug 31, 2002)

jmettraux said:
			
		

> *But, well... I don't think you will need bison right away, we want to turn your standard vision into a "E"? "BNF" document at first, any parser will come later. So your  referee skills are required now *




I think that testing it with a parser generator could help us get there, that's all.


----------



## jmettraux (Aug 31, 2002)

CRGreathouse said:
			
		

> *
> 
> I think that testing it with a parser generator could help us get there, that's all.
> 
> I've made a few changes (especially to the size and type section); *




OK ! The sooner we get to a format used by a parser generator, the less work we will have.

I will commit your changes to the grammar monday morning. Well done !

What would you think of :


> languages:    "Languages spoken: " language (", " language)*
> language:    String


----------



## CRGreathouse (Sep 1, 2002)

jmettraux said:
			
		

> *What would you think of : [language section omitted] *




It's an oft-requested feature.  Actually, now that I think about it, I don't know why I didn't just put it in from the start - normally I don't weant to add more options than needed, but this one would be easy enough for a person or program to ignore since it's broken out.


----------



## jmettraux (Sep 2, 2002)

New version of the grammar :
http://cvs.sourceforge.net/cgi-bin/...rev=HEAD&content-type=text/vnd.viewcvs-markup
diff :
http://cvs.sourceforge.net/cgi-bin/...port_samples/standard.ebnf.diff?r1=1.5&r2=1.7

Thanks Charles ! Your refinements are smart.


Two propositions :

1) I'm sure you already thought about it, but shouldn't this thread appear somehow in the d20 publishers forum ?

2) We could run a sourceforge project just for d20statblock.org's documents, so we could more easily collaborate. (Though the grammar itself will reach a 'stable' state sooner or later)


----------



## CRGreathouse (Sep 2, 2002)

jmettraux said:
			
		

> *1) I'm sure you already thought about it, but shouldn't this thread appear somehow in the d20 publishers forum ?
> 
> 2) We could run a sourceforge project just for d20statblock.org's documents, so we could more easily collaborate. (Though the grammar itself will reach a 'stable' state sooner or later) *




1. I'd prefer to wait until it's a little more mature.  Right now we're just working out the major bugs.
2. I've never worked with sourceforge.  What are the advantages?  What things would be moved there?  In general, I  have no objection - but I'd like to know more.


----------



## jmettraux (Sep 2, 2002)

CRGreathouse said:
			
		

> *
> 1. I'd prefer to wait until it's a little more mature.  Right now we're just working out the major bugs.
> 2. I've never worked with sourceforge.  What are the advantages?  What things would be moved there?  In general, I  have no objection - but I'd like to know more.
> *




1)  

2)

You would be able to commit your changes directly.

We should move there the grammar itself and any other document related. A lot of examples should be stored there too.

The source code for a validation parser (a parser that just says 'yes this stat block is standard') could be a nice addon.
(We could run it online somewhere).

You could also store there your web site like I do for dgsh :
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dgsh/dgsh/doc/


----------



## CRGreathouse (Sep 2, 2002)

jmettraux said:
			
		

> *You would be able to commit your changes directly.
> 
> We should move there the grammar itself and any other document related. A lot of examples should be stored there too.
> 
> ...




This sounds interesting, I'll have to look into it.

I went through an interesting excercise with the grammar: I decided to make the shortest legal stat block.  I chose "X" for all strings and "0" for all integers (and d% as the die).  This helped me find many minor bugs that I would have otherwise missed.

X: CR 0; Fine Fey; HD 0d%; hp 0; Init +0; Spd 0m; AC 0; Melee X +0; AL N; SV Fort +0, Ref +0, Will +0; Str 0, Dex 0, Con 0, Int 0, Wis 0, Cha 0.
Skills and Feats: X +0; X.
Equipment: X.

I'm editing my above post to include my changes.

Edit: (from above)

Is there a way to force capitalization?  Some sections could use it:
domains, languages, deities, etc.  Should I just make a lString: "a" | "b"... or what?
Also, how does a String work?  Is it (character)+ or (character)*


----------



## jmettraux (Sep 3, 2002)

CRGreathouse said:
			
		

> *
> Is there a way to force capitalization?  Some sections could use it:
> domains, languages, deities, etc.  Should I just make a lString: "a" | "b"... or what?
> Also, how does a String work?  Is it (character)+ or (character)* *




Proposition :



> string:    (specialCharacter | lowAlpha | upAlpha)*
> specialCharacter:    " " | "'" | "-"
> lowAlpha:    "a" | ... | "z"
> upAlpha:    "A" | ... | "Z"
> ...




last version of the grammar :
http://cvs.sourceforge.net/cgi-bin/...rev=HEAD&content-type=text/vnd.viewcvs-markup
diff :
http://cvs.sourceforge.net/cgi-bin/...port_samples/standard.ebnf.diff?r1=1.7&r2=1.8


----------



## smetzger (Sep 3, 2002)

Leopold said:
			
		

> *also if you guys have all the monsters and stuff in statblock format and stuff from SRD posted it would be a GREAT help to the community.
> 
> 
> I know you are trying to set a standard here but if you could take, say the monster manual, and convert it into statblock or even the Creature collection that would be awesome! *




My Monster program will save stablocks of all the Monsters in Luke's RPM database (which is almost all of the creatures in the SRD).

I don't think a statblock is the best way to build interoperability between programs.  I would think that time would be wasted writing a parser and a writer.  I think XML or even a standard format Access database file would work better.


----------



## jmettraux (Sep 3, 2002)

smetzger said:
			
		

> *I would think that time would be wasted writing a parser and a writer.  I think XML or even a standard format Access database file would work better. *




Once the grammar is OK, generating a parser can be automatically done. 
Implementing stat block output is not much time consuming.

You're right when you say that XML would be a better 'pivot' between programs.

Access on the other hand should not be considered as something 'standard'. Perhaps the SQL92 transcription of the tables used by eTools could be considered as standard.

Which version of stat blocks do you use for storing SRD monsters into RPM ?


----------



## smetzger (Sep 3, 2002)

jmettraux said:
			
		

> *
> Which version of stat blocks do you use for storing SRD monsters into RPM ? *




I don't store them into RPM.  I read some tables in RPM and output a statblock.  I use my own format which I believe is similare to the SSB.


----------



## jmettraux (Sep 4, 2002)

smetzger said:
			
		

> *
> I don't store them into RPM.  I read some tables in RPM and output a statblock.  I use my own format which I believe is similare to the SSB. *




So if you switched to SSB, that would be really fair, and Leopold's wish would be almost exauced.


----------



## smetzger (Sep 4, 2002)

jmettraux said:
			
		

> *
> 
> So if you switched to SSB, that would be really fair, and Leopold's wish would be almost exauced. *




Yes, but I use my own format because I think its better.  Why do you need to have it in SSB format?


----------



## jmettraux (Sep 4, 2002)

smetzger said:
			
		

> *
> 
> Why do you need to have it in SSB format? *




Because a standard is good for everyone.

If you think your stat block format is better than d20statblock.org's one, you should use this thread to explain us what makes your format better, so that we can make a better standard.

Your stat blocks are intended for human eyes only, ours target humans and programs.


----------



## jmettraux (Sep 4, 2002)

Charles,

1) How should a weapon's range be displayed ?

2) The current grammar authorizes things like "Lolth / Drow, Spider and Evil". There is one domain that is not needed.

3) Are specialty spells (necromancers, invokers, ...) displayed like domain spells ?
(If you want I can just go a 'copy-paste-adjust' domainSpellsSection in specialtySpellsSection)


----------



## smetzger (Sep 4, 2002)

jmettraux said:
			
		

> *
> Your stat blocks are intended for human eyes only, ours target humans and programs. *




Correct.  I don't think a statblock should target computer programs.

Like CRGreathouse said "That sounds good, but what is the purpose of this type of definition?
Is it primarily designed for human or machine reading? "

Perhaps if you could elaborate on the answers to these questions and why you feel a statblock should be used as a target for computer programs.


----------



## jmettraux (Sep 4, 2002)

smetzger said:
			
		

> *
> Like CRGreathouse said "That sounds good, but what is the purpose of this type of definition?
> Is it primarily designed for human or machine reading? "
> 
> Perhaps if you could elaborate on the answers to these questions and why you feel a statblock should be used as a target for computer programs. *




Currently, the grammar could be seen as way to define _precisely_ how informations in a stat block should be displayed.
I came with this grammar because the style guide is rather fuzzy.

Generating parsers automatically is a secondary effect that is not immediately targeted.

What's great about XML is that it is also human-readable, what's great about a standard stat block format is that it is also computer-readable.

As dgsh conceptor I want to be able to get on an online generator site, copy a stat block and 'feed' it to dgsh without too much hassle. This could benefit to all 'in-flight' programs and DM Familiar for example, clearly states in its new features that it can parse other program's stat blocks.

If you don't want all the monsters you've taken out of RPM's database and displayed in stat blocks to be parsed by another's program : OK, don't use the standard.
But if Luke is listed in d20statblock.org's supporters, why not follow his path and support the standard (when it's stable  ) ?

smetzger, you'll always be right, XML is a better format for programs interoperability.
But if a computer can parse a fiscal declaration why not stat blocks ?

If other RPG software developers could issue an opinion about a stat block standard, we could have a clear view about 'computers parsing stat blocks'.


----------



## CRGreathouse (Sep 5, 2002)

jmettraux said:
			
		

> *As dgsh conceptor I want to be able to get on an online generator site, copy a stat block and 'feed' it to dgsh without too much hassle. This could benefit to all 'in-flight' programs and DM Familiar for example, clearly states in its new features that it can parse other program's stat blocks.*




This is essentially why I want the statdnard - some programs are better at certain things than others, and having a single format makes it easy to use whatever's best for the particular job for just that job.



			
				jmettraux said:
			
		

> *1) How should a weapon's range be displayed ?
> 
> 2) The current grammar authorizes things like "Lolth / Drow, Spider and Evil". There is one domain that is not needed.
> 
> ...




1. Range is listed (optionally) after crit: longbow +6 (1d8/crit x3, range 50 ft)
2. This is intentional - there are prestige classes (and an epic feat) that grant extra domains.
3. No, they're mixed in with normal spells.  It hasn't caused problems yet, and I don't see why it would.


----------



## jmettraux (Sep 5, 2002)

new revision of the grammar :

http://cvs.sourceforge.net/cgi-bin/...rev=HEAD&content-type=text/vnd.viewcvs-markup


"String" is not implicit. I used it in the beginning as a handy abstraction tool. Now we've defined it and it's fine.
Integer and Float aren't implicit too, but it isn't hard to define them.

In this new revision of the grammar I changed the reference from "String" to "string".

Concerning name and raceName... Will ever a computer program have enough common sense to differentiate two such strings ?
At least, here, the standard is clear for human beings, for the computer, it ends up manipulating 2 strings, not 2 concepts.

Thanks for the replies up there.
I brought the specialized spells on the "negociation table" because you clearly separated domain spells from other prepared spells. Specialized wizards have a bonus spell a day from their school, it's quite similar to a domain spell. (I also have less business logic to implement if the specialized spells are clearly tagged as such.  )


----------



## CRGreathouse (Sep 5, 2002)

jmettraux said:
			
		

> *"String" is not implicit. I used it in the beginning as a handy abstraction tool. Now we've defined it and it's fine.
> Integer and Float aren't implicit too, but it isn't hard to define them.
> 
> In this new revision of the grammar I changed the reference from "String" to "string".
> ...




OK, I'll define Integer and Float; I might as well do it now.

I don't think there's any way to tell the difference between name and raceName, since new raceNames are added constantly.  If it doesn't cause problems for the parser generator, I don't care, but I thought it might.

I'm going to go through it again to use the new lowerAlpha and so forth.  Really, this is a tricky part - names starting with a lowerAlpha *are* valid (e.g. PC's emBroth).  I'll have to consider which special characters should be valid.  For now, how about upperAlpha, lowerAlpha, accented characters, ', and -.  Can you think of anything else?


----------



## jmettraux (Sep 5, 2002)

CRGreathouse said:
			
		

> *Really, this is a tricky part - names starting with a lowerAlpha *are* valid (e.g. PC's emBroth).  I'll have to consider which special characters should be valid.  For now, how about upperAlpha, lowerAlpha, accented characters, ', and -.  Can you think of anything else? *




Anything UTF-8 should appear in both lowAlpha and upAlpha (it includes orcish alphabet, but not the kobold one...)

For special characters, I can't think of anything more than "'" and "-". They are ambushing somewhere on our way.



> integer:    zero | (nonZero digit*)
> float:    integer "." digit
> zero:    "0"
> nonZero:    "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"
> digit:    zero | nonZero


----------



## CRGreathouse (Sep 5, 2002)

lowAlpha
upAlpha

How's this for the skills and feats section?


```
skillsAndFeatSection:
		"Skills and Feats: " skills "; " feats "."

skills:		skill (", " skill)*
feats:		feat (", " feat)*

skill:		string " " modifier ( " (" ranks ")" )?
ranks:		Integer
skillName:	upAlpha lowAlpha* ((" "|"-") upAlpha lowAlpha*)*
feat:		upAlpha lowAlpha* ((" "|"-") upAlpha lowAlpha*)* ("(" string (", " string)* ")")?
```

Allowed: "Alertness", "Combat Reflexes", "Blind-Fight"
Disallowed: "alertness", "CombatReflexes", "Blind-fight", "*^%^$^^$^#@"


----------



## smetzger (Sep 6, 2002)

CRGreathouse said:
			
		

> *lowAlpha
> upAlpha
> 
> How's this for the skills and feats section?
> *




What about feats with a comma in the name?
How is a parser supposed to distinguish the difference between a skill and a feat?  A feat could have a + in the name followed by an integer, how would a parser determine if it was a skill or a feat?
How do you designate the 'subtype' of a feat?  ex Weapon Focus
What if there are two or more subtypes?  ex skill related feats that give +2 to two different skills
How do you designate virtual feats?  racial feats?


----------



## CRGreathouse (Sep 6, 2002)

smetzger said:
			
		

> *What about feats with a comma in the name?*




Disallowed.  This would interfere with parsing the feats, since they're seperated with commas.



			
				smetzger said:
			
		

> *How is a parser supposed to distinguish the difference between a skill and a feat?*




It doesn't have to.  The semicolon between the skills and feats should give it away.



			
				smetzger said:
			
		

> *How do you designate the 'subtype' of a feat?  ex Weapon Focus
> What if there are two or more subtypes?  ex skill related feats that give +2 to two different skills*




As a parenthetical note.  That's why that portion is in the style guide.



			
				smetzger said:
			
		

> *How do you designate virtual feats?  racial feats? *




Racial feats are included normally.

Virtual feats, now there's an issue... I wish I had a quarter for every *page* I've written about virtual feats and their place (or lack therof?) in a stat block.  This is ambiguous in the format itself and will have to be decided.

It's not an issue for the parser, but it's a major issue for the format itself.


----------



## CRGreathouse (Sep 6, 2002)

I've made lots of minor changes and comments, plus a rewrite of the skills and feats section.


----------



## jmettraux (Sep 6, 2002)

New version of the grammar :
http://cvs.sourceforge.net/cgi-bin/...rev=HEAD&content-type=text/vnd.viewcvs-markup
diff :
http://cvs.sourceforge.net/cgi-bin/...rt_samples/standard.ebnf.diff?r1=1.10&r2=1.11

The skills and feats section may be ugly, but it seems it's the best way to define it. Well done.

Charles, could you attach your new versions ? It will be easier for me to commit it. Thanks in advance.


----------



## smetzger (Sep 6, 2002)

CRGreathouse said:
			
		

> *
> Virtual feats, now there's an issue... I wish I had a quarter for every *page* I've written about virtual feats and their place (or lack therof?) in a stat block.  This is ambiguous in the format itself and will have to be decided.
> 
> It's not an issue for the parser, but it's a major issue for the format itself. *




If I were to parse a statblock it would be an issue for me. 

What about racial 'Feats'  which aren't actually Feats?  Like the Elf proficiency in longsword and bow?  There is not  a feat for a single martial weapon proficiency.  Are these to be listed?


----------



## jmettraux (Sep 6, 2002)

> _(on virtual feats)_
> 
> _Originally posted by smetzger _
> *
> ...




* Implementing a bit of common sense in a parser is not that hard.

For example, the attack modifiers stated in a stat block are not necessary for a program as it can compute them from abilities, classes and feats. If the computed result is different than the statistic, the parser can add spontaneously the missing feat.

For dgsh, I simply added a delta, which keeps track of the difference between a computed modifier and a stated one.

* Correcting the character/monster after it's generated is not forbidden either.


----------



## CRGreathouse (Sep 6, 2002)

smetzger said:
			
		

> *If I were to parse a statblock it would be an issue for me.*




I understand that.  It's not an issue for this parser, since it's 'dumb', but it would obviously be an issue for any meaningful input program.



			
				smetzger said:
			
		

> *What about racial 'Feats'  which aren't actually Feats?  Like the Elf proficiency in longsword and bow?  There is not  a feat for a single martial weapon proficiency.  Are these to be listed? *




If they aren't feats, don't include them under any circumstances.  (Martial Weapon Proficiency with a single weapon, incidentally, is a feat.  Simple Weapon Proficiency is the only one that covers the whole field.)

Edit: I don't recommend including weapon proficiencies (except those bought with feats) in the feats section at all.  They are included in the stat block, though - class proficiencies follow from the class section, and racial weapon proficiencies go under SQ (elf traits).  Example:

Character, male elf War1: CR 1/2; ECL 1; Medium-size Humanoid (elf); HD 1d8-1; hp 3; Init +1; Spd 30 ft; AC 11 (+1 Dex); Melee unarmed strike +0 (1d3); SQ elven traits; AL N; SV Fort +1, Ref +1, Will +0; Str 11, Dex 12, Con 8, Int 11, Wis 11, Cha 11.
SQ--Elven Traits (Ex): Sleep immunity, +2 save vs. Enchantment, low-light vision, proficient: longsword or rapier, proficient: longbows and shortbows.


----------



## CRGreathouse (Sep 6, 2002)

jmettraux said:
			
		

> *The skills and feats section may be ugly, but it seems it's the best way to define it. Well done.*




Thanks!  



			
				jmettraux said:
			
		

> *Charles, could you attach your new versions ? It will be easier for me to commit it. Thanks in advance. *




Oh, sure.  I originally posted them because I thought you'd just go over it & copy in what I changed - I expected to make many mistakes since I didn't know about EBNF until you brought it to my attention.  Now it looks like I have a good understanding of how to use it, so attaching it would be best.  (I'll have to make it a txt, though; I can't attach an ebnf file here.)


----------



## CRGreathouse (Sep 7, 2002)

I've attached my latest version of the grammar.  Changes: masive revision of all things numeric, continued effort to specify strings more closely*, grouping of related elements, minor spell revision.

Edit: What about other symbols, like the slashed O?  What are we missing?

* I want to find a good common theme to all the specific coding I'm doing (feats, gods, etc.) with strings, but I'm not sure how best to go about it.


----------



## jmettraux (Sep 8, 2002)

New revision of the grammar :
http://cvs.sourceforge.net/cgi-bin/...rev=HEAD&content-type=text/vnd.viewcvs-markup
diff : 
http://cvs.sourceforge.net/cgi-bin/...rt_samples/standard.ebnf.diff?r1=1.11&r2=1.12

In fact, internationally speaking, a lot of characters are missing. Names in french, italian, german and of course english are currently possible, but as an example, the "n~" is missing, so not all spanish names are expressable.
I wonder about portuguese (brazilian) as there are more and more people role-playing in Brasil.

We should take a look at the UTF-8 standard (unicode for short), there is certainly a short way of describing what we want with our string stuff.


----------



## hong (Sep 8, 2002)

Okay, I'll preface this by saying that I'm not a computer geek. I'm a different subspecies of geek, a D&D geek. 

That said, I'm thinking like Smetzger: why do you need a precise format for a statblock? A statblock is just a condensed summary of a character sheet, meant purely for human consumption. I just don't see the need to go to the trouble of a formal grammar, except as an intellectual exercise. Human beings tend to have a better ability to disambiguate information from context, unlike computers.

In any case, the information in a statblock is incomplete, which makes life difficult sometimes, especially when dealing with buffing spells. For example, suppose someone has a Reflex save of +10. This doesn't tell you what components went into it. They might have a resistance bonus, a morale bonus, or a luck bonus, or any combination (or none) of the three. This sort of information is important when you have a bard in the party, or spells that give various typed bonuses: sometimes they count, and sometimes they don't. The statblock doesn't tell you any of this, as far as I can tell.

Now, what I _would_ like to see a standard, open format for, is a character file. This would include all the various factors that are present behind the scenes, but don't appear in the statblock:
- breakdown of each bonus (attack, damage, saves, skills, etc) by type (base/ranks, ability, competence, morale, dodge, luck, untyped, etc)
- which skills are class/cross-class/excluded
- XP spare for item creation purposes
- grapple check bonus
- proficiencies
- virtual feats
- etc, etc.

If necessary, a program could take such a file as an input and _generate_ a statblock, and the precise format of that statblock would be as the programmer desired (perhaps using any guidelines published by the SSBF). As long as it was recognisably a statblock, with all the entries in the right places, I wouldn't be too concerned if they used commas instead of semicolons, or inserted spurious linebreaks, or whatever.

Is there something like this already? Is, say, PCGen's file format an accepted standard that can be read by any other character generator program/DMing tool out there?

And BTW, XML isn't readable. At least not to me.


----------



## jmettraux (Sep 8, 2002)

hong said:
			
		

> *That said, I'm thinking like Smetzger: why do you need a precise format for a statblock?
> *



I've reread everything Smetzger wrote in this thread and he never said this.
As I understand his opinion, he thinks we shouldn't focus on statblocks readable by computers, but rather on statblocks readable by people.



			
				hong said:
			
		

> *And BTW, XML isn't readable. At least not to me. *



Kanji isn't readable for me, though I'm human and it is human-readable .


Your post is valuable, though you should read the grammar and perhaps you'll have direct ideas to bring to us.

EBNF is a computer science technique for expressing languages. Being used for generating parsers is considered by us a second effect as the first goal is to set a precise format. This has been stated at the beginning of this thread.


----------



## CRGreathouse (Sep 8, 2002)

jmettraux said:
			
		

> *EBNF is a computer science technique for expressing languages. Being used for generating parsers is considered by us a second effect as the first goal is to set a precise format. This has been stated at the beginning of this thread. *




I would've written a long response to hong's post, except that your post really sums up my feeling well.

*****

I have some other minor changes to make, but it seems to be getting close.  I've sent a copy to Florian to look over - maybe he'll see something I missed.


----------



## hong (Sep 9, 2002)

jmettraux said:
			
		

> *
> I've reread everything Smetzger wrote in this thread and he never said this.
> As I understand his opinion, he thinks we shouldn't focus on statblocks readable by computers, but rather on statblocks readable by people.
> *




But that's my point. You don't _need_ a formal grammar to make statblocks that are readable by people. The main use of formal grammars is in language specifications, to allow generation of code that's readable by computers. If your final objective doesn't involve making statblocks that are readable by computers, I still don't see why you need a grammar.

Not to mention that I also don't see why you need a statblock that's computer-readable anyway. As said before.



> *
> Kanji isn't readable for me, though I'm human and it is human-readable .*




Ah, but a statblock isn't kanji. It's just an abbreviated form of a character sheet. Are you suggesting that regular D&D gamers should need to learn kanji (or XML) to read a statblock...? 



> *
> EBNF is a computer science technique for expressing languages. Being used for generating parsers is considered by us a second effect as the first goal is to set a precise format. This has been stated at the beginning of this thread. *




I'm aware of what EBNF is. I just don't know why it's relevant here.

As I said before, working towards a standard character file format is something that I think _would_ be very valuable. It's there that all the language tools would come in handy (grammars, parsers, lexers, go wild).


----------



## jmettraux (Sep 9, 2002)

At first, a supplication : please read the grammar before posting here.






			
				hong said:
			
		

> *If your final objective doesn't involve making statblocks that are readable by computers, I still don't see why you need a grammar.
> 
> Not to mention that I also don't see why you need a statblock that's computer-readable anyway. As said before.*




So Mr Hong, please enlighten us with your description of what a stat block should look like.
Please, don't forget all the details you were happy to mention in your initial post. But please, do it in another thread.

EBNF is just a tool.


----------



## hong (Sep 9, 2002)

jmettraux said:
			
		

> *
> So Mr Hong, please enlighten us with your description of what a stat block should look like.*




"For examples of what a stat block should look like, see the following."

[list 3 or 4 examples]

It's good enough for a lot of academic journals, when it comes to telling authors how to cite a reference. It should be good enough for a statblock.



> *
> Please, don't forget all the details you were happy to mention in your initial post. *




These details are not part of a statblock, and I'm pretty sure they've never been.



> *But please, do it in another thread.*




No.



> *
> EBNF is just a tool. *




Of course.


----------



## CRGreathouse (Sep 10, 2002)

hong said:
			
		

> *"For examples of what a stat block should look like, see the following."
> 
> [list 3 or 4 examples]
> 
> It's good enough for a lot of academic journals, when it comes to telling authors how to cite a reference. It should be good enough for a statblock.*




http://www.d20statblock.org/standard/d20standard.html

We've done that, but it's not enough.  I get many emails asking about specific nuances of the format, often the same minor aspect over and over, but sometimes a new feature I'd never really considered.

This is just the next step in a process for us.


----------



## CRGreathouse (Sep 10, 2002)

Edit: Hmm, it didn't work.  Let me try again...


----------



## CRGreathouse (Sep 10, 2002)

OK, this is try #2 for my EBNF update.


----------



## tarchon (Sep 10, 2002)

CRGreathouse's question on another board got me looking at this.  I think it is a good idea to have a standard format guide, but the restrictive way it's implemented seems excessive.

For instance, should we restrict _string_ to a particular character set?  Does that add something useful to the grammar?  Sure, you need to keep out non-quoted delimiters, but why rule out, say, feat names like "Rock & Roll"?  Another problem with the way this is done is that you haven't defined a character set.  Very commonly, non-American platforms (even in English speaking countries) and even many older US computers will use different code pages from Latin-1 or alternative typefaces for localized encoding.  If one of those is being used, you might be excluding half the alphabet and including any number of punctuation elements.

Also, if you do use UTF-8 (as someone recommended, and it's not a bad idea), restricting your characters the way you've done it will utterly hork with the encoding system.  The only safe way to filter UTF-8 with single byte characters is to allow all 8-bit characters with the MSB set (see http://czyborra.com/utf/).

Personally, as an ex-software internationalizer, I would be inclined to recommend against any restriction on the makeup of strings besides what you need to avoid delimiter conflicts, which as far as I can tell excludes only ',' and ';' (and perhaps '(' and ')').  Maybe creating a field to indicate the character encoding would be good, but I think it's best left to the applications programmers to decide what they want to their apps to do with like Latin-4.    Pass it through, don't mess with it if you don't have to mess with it.

Similarly, the capitalization restriction is unnecessary and potentially interferes with localization of the format.  Many languages don't even have letter cases, and virtually all of those that do have different capitalization rules from English.  Plus you again run into the problem that Ï in Latin-1 may not correspond to the capital of ï in a random character set.

Also, should _type_ be restricted?  If this is a general d20 format, I think it's safe to say there's a good chance that somebody with some d20 setting will want to use a different monster type someday.  Same goes for Elemental subtypes.  Dust, shadow, steam elemental, I've seen those in many contexts

It might be best not to wed the format to the 9-point alignment system either. 

As a general rule with something like this, it's usually best not to restrict the options for the various fields any more than necessary.


----------



## jmettraux (Sep 10, 2002)

Tarchon issued a nice piece of advice, thanks ! 

We are perhaps losing ourselves with all these character sets.

We could step back a little (not defining "string") and leave those refinements to people that really want to generate parsers.

Our grammar should keep the focus on complementing the style guide. We could consider turning the grammar into a real parser generation grammar as a 2nd project.


----------



## CRGreathouse (Sep 10, 2002)

I want to make something clear: This style guide is the English style guide.  If it were not English, it would not include terms like "Skills and Feats" hardcoded.

The special characters are there for two main reasons:
* Many people play D&D using English for the rules and their native/preferred language for character names, etc.
* Many native English speakers use 'exotic' characters to make their names 'cool'.

I think that making style guides for other languages would be useful, but my command of foreign languages isn't great, I don't own a translated copy of the PH, and I think a native speaker would do a better job in all cases.


----------



## jmettraux (Sep 10, 2002)

CRGreathouse said:
			
		

> *I want to make something clear: This style guide is the English style guide.  If it were not English, it would not include terms like "Skills and Feats" hardcoded.*




So let's remove accents in the grammar ! Simplification is good.

(My PHB is a french edition  )


----------



## CRGreathouse (Sep 10, 2002)

jmettraux said:
			
		

> *So let's remove accents in the grammar ! Simplification is good.*




It's as I mentioned - many English (American?) speakers like the 'exotic' feel of accented or Old English letters.



			
				jmettraux said:
			
		

> *(My PHB is a french edition  ) *




How many of the hardcoded terms would have to be changed to make a French version?  Obviously "skills and feats", but what about "Init", "Spd" ("Vit" sounds wrong, somehow), etc.?

I'm mainly just curious - though it's quite possible to make 3 versions once the main one's done (English/French/German).


----------



## DMFTodd (Sep 10, 2002)

> But that's my point. You don't _need_ a formal grammar to make statblocks that are readable by people.




Yes, we do. 

Here's a real-world example of why: My program, DM's Familiar, can import stat blocks. As long as the stat block follows a standard format, my program can import it. Where might a stat block come from?

It might come from software: PCGen, E:Tools, etc. 

It might come from a human: Typed in by hand, Typed in based on an adventure the user has, scanned from Dungeon mag.

If I had decided on a computer-based import (reading the PCGen file, or the E:Tools file, or some "standard"), then my program wouldn't work for any of the "human" ways of creating a stat block. 

If I had decided on a computer-based import, then anything that didn't create the computer file wouldn't work with my program, period (Jamis Buck NPC generator). By using a "English" standard stat block, a user can take the Jamis stat block, tweak it by hand, and then import it. If it was a computer-based format, the Jamis file wouldn't work. 

That's why we need a standard.


----------



## CRGreathouse (Sep 10, 2002)

DMFTodd said:
			
		

> *Yes, we do.
> 
> Here's a real-world example of why: My program, DM's Familiar, can import stat blocks. As long as the stat block follows a standard format, my program can import it. Where might a stat block come from?*




Thanks, Todd.  I actually have similar plans for importing stat blocks, though mine are deep alpha now.

RPM imports stat blocks (Jamis format), as does PCProfiler (standard format).  Does anyone know of other programs that import from some stat block?


----------



## DMFTodd (Sep 10, 2002)

First off, I'd like to say thanks for taking the time to do this stuff. The software community needs it. 

Secondly, that grammer is making my head hurt. As someone who has something at stake in this process (please don't blow up the current standard, I'm using it!), I want to get involved but I think you have enough cooks already (and it makes my head hurt as noted). I kinda want to wait til you guys get done then throw in my 2 cents. 

Thirdly, do you want comments from the peanut gallery? Assuming you do, here's some thoughts (and since I haven't studied the standard enough, maybe these are there. Keep in my that these suggestions come from real-world users. These are things that the DMF users have asked for in the stat block so they can be imported):

What about a section for "custom" additions to the stat block? Things that I would want to support but that wouldn't be necessarily part of the standard. Should they have their own section or do they get included anywhere in the top portion? 

What about people like me who want to create their own unqiue identifiers? Would they get added into the grammer for other people to include down the road?

Here are some that have come up for me with DMF already (these are the identifiers I'm using, they can go anywhere in the statblock is how I support it):

BAB:, Melee BAB:, Ranged BAB:, XP:


----------



## CRGreathouse (Sep 10, 2002)

DMFTodd said:
			
		

> *Thirdly, do you want comments from the peanut gallery?*




Yes, please!



			
				DMFTodd said:
			
		

> *What about a section for "custom" additions to the stat block? Things that I would want to support but that wouldn't be necessarily part of the standard. Should they have their own section or do they get included anywhere in the top portion?
> 
> What about people like me who want to create their own unqiue identifiers? Would they get added into the grammer for other people to include down the road?*




I'll have to think about this one.  Actually, I'll have to think a lot about this one - it's a good point, and raises many other issues.



			
				DMFTodd said:
			
		

> *BAB:, Melee BAB:, Ranged BAB:, XP: *




There are no "Melee BAB" and "Ranged BAB" in core D&D.  There are only three 'flavors' of base attack bonus: normal, unarmed, and epic (which isn't considered 'base', but acts much like it).  Did you mean "Melee AB" and "Ranged AB"?

In any case, I'll get back to you on this.  Some things are pragmatic (how many new tags, and how intercompatible) and others are legal (d20 STL and XP - I'll have brush up to see what we can and can't do).


----------



## smetzger (Sep 10, 2002)

DMFTodd said:
			
		

> *
> 
> Yes, we do.
> 
> ...




But that is not a human reading the statblock.  That is a computer.  I am sure that IF e-tools and PCGen exported a character in XML format as well as statblock that you would have used the XML interface.

I don't mind having a standard for a human readable statblock.  However, if we are going to have a standard for computers reeading a character I think it should be XML or even comma delimited.

There is not much we can do about e-tools in its present incarnation.  However, if an XML standard was made I am sure that most if not all the 3rd party software development people could be convinced to use it.  I also think that there is an equal chance to convince future incarnations of e-tools to follow an XML standard as there is of convincing them to follow a statblock standard.


----------



## CRGreathouse (Sep 10, 2002)

smetzger said:
			
		

> *But that is not a human reading the statblock.  That is a computer.  I am sure that IF e-tools and PCGen exported a character in XML format as well as statblock that you would have used the XML interface.
> 
> I don't mind having a standard for a human readable statblock.  However, if we are going to have a standard for computers reeading a character I think it should be XML or even comma delimited.*




Since we'll have a human-readable format, why not make it computer-readable, too?  Todd, along with some others I mentioned, have showed that it's quite possible - and useful - to have such a feature.  I intend to follow in their footsteps (though I thought of it independantly, I'm a little slow on implementation).


----------



## DMFTodd (Sep 10, 2002)

> that IF e-tools and PCGen exported a character in XML format as well as statblock that you would have used the XML interface.




You would be wrong. 

I wanted an import routine that would work with the widest range of possibilities -- both COMPUTER and HUMAN. 

Dungeon Magazine does not provide XML monster stats. My users could not sit down and type/edit XML monster stats. 

Dungeon Mag DOES provide stat blocks. My users CAN read/type/edit a stat block. PCGen and E:Tools CAN both create stat blocks as do other programs. 

Hence, I decided that my import routine would use stat blocks. That seems like a simple explanation. Am I missing something?


----------



## CRGreathouse (Sep 10, 2002)

DMFTodd said:
			
		

> * Dungeon Mag DOES provide stat blocks. My users CAN read/type/edit a stat block. PCGen and E:Tools CAN both create stat blocks as do other programs.*




Wait a sec - you mean I'm not the only one who's imported a character by manually copying a stat block?  Cool!


----------



## jmettraux (Sep 10, 2002)

smetzger said:
			
		

> *However, if an XML standard was made I am sure that most if not all the 3rd party software development people could be convinced to use it.  I also think that there is an equal chance to convince future incarnations of e-tools to follow an XML standard as there is of convincing them to follow a statblock standard. *



check this :
http://groups.yahoo.com/group/d20-xml/
http://groups.yahoo.com/group/pcgen-xml/


			
				DMFTodd said:
			
		

> *By using a "English" standard stat block, a user can take the Jamis stat block, tweak it by hand, and then import it. If it was a computer-based format, the Jamis file wouldn't work.*



Thanks Todd, this use case shows the strength behind the standard.


			
				CRGreathouse said:
			
		

> *Does anyone know of other programs that import from some stat block?*



My small dgsh has a tool  for turning a standard stat block into its own XML.


----------



## CRGreathouse (Sep 10, 2002)

jmettraux said:
			
		

> *My small dgsh has a tool  for turning a standard stat block into its own XML. *




(smacks self on forehead)

Of course!


----------



## jmettraux (Sep 15, 2002)

Newest version (as attached by CRGreathouse).

Strings are scrambled...

http://cvs.sourceforge.net/cgi-bin/...rev=HEAD&content-type=text/vnd.viewcvs-markup


----------



## CRGreathouse (Sep 15, 2002)

I think the boards don't like my UTF-8.  Should I email it to you?


----------



## jmettraux (Sep 15, 2002)

CRGreathouse said:
			
		

> *I think the boards don't like my UTF-8.  Should I email it to you? *




Oh yeah, please, but wait til tomorrow, my mail server is down.

John


----------



## CRGreathouse (Sep 15, 2002)

jmettraux said:
			
		

> *
> 
> Oh yeah, please, but wait til tomorrow, my mail server is down.
> 
> John *




That's why my first email didn't work.  I'll send it next (EST) morning.


----------



## MJEggertson (Sep 16, 2002)

Could you rifle me off a copy too? I still can't really contribute, but I'm eager to learn, and have a few ideas bouncing around in my head.

I think a unified format would be a very good solution. It will be a very easy way to move data around from program to program for two reasons. 1) Cut&Paste. 2) You're moving human readable data around, so it's real easy to compare what you input to what comes out after the import process.

Plus, importing directly from native application formats is clumsy at best, for every app forever changes their formats. Maintaining support fror an app's import processes becomes exponential to the number of formats you wish to support.

An xml statblock format would be much easier for a computer to manipulate, but I fail to see the point in it. Why bother with XML if the same can be done with a much nicer looking human-readable format?

I wonder what value a distributed dll would be once the format has been specified. One that parses the input, and that a hosting app could then query using id commands to extract out the info. It shouldn't be too hard to make, but I question the usefulness of something like that. I program in C++/MFC, but I think most other projects are platform independent, so the library wouldn't be too useful to others...

Hmm...


----------



## smetzger (Sep 16, 2002)

MJEggertson said:
			
		

> *I wonder what value a distributed dll would be once the format has been specified. One that parses the input, and that a hosting app could then query using id commands to extract out the info. It shouldn't be too hard to make, but I question the usefulness of something like that. I program in C++/MFC, but I think most other projects are platform independent, so the library wouldn't be too useful to others...
> 
> Hmm... *




If you release the source code and try to make sure its cross-compiler and cross-platform . . .


----------



## CRGreathouse (Sep 16, 2002)

MJEggertson said:
			
		

> *Could you rifle me off a copy too?*




Sent.



			
				smetzger said:
			
		

> *If you release the source code and try to make sure its cross-compiler and cross-platform . . . *




I don't really use Java, but I may try to write a parser in it anyway, since it's nice nad cross-platform.


----------



## smetzger (Sep 16, 2002)

CRGreathouse said:
			
		

> *
> 
> I don't really use Java, but I may try to write a parser in it anyway, since it's nice nad cross-platform. *




You can use C++ for cross platform development.  This is especially true for something that doesn't have a GUI.  If you stayed away from the MFC, were ANSI C++ compliant, and released the source code than people could recompile with whatever compiler or OS they used.  I am not sure how one would go about 'calling' a Java library from a C++ program.


----------



## CRGreathouse (Sep 16, 2002)

smetzger said:
			
		

> *You can use C++ for cross platform development.*




I agree, but Java seems made for it.  I'll consider C, though.


----------



## jmettraux (Sep 17, 2002)

Another try at encoding :
http://cvs.sourceforge.net/cgi-bin/...rev=HEAD&content-type=text/vnd.viewcvs-markup


----------



## CRGreathouse (Sep 17, 2002)

Mike - the email I sent you just bounded back.  Would you email you with whatever address you use now so I can update my address book & send you a copy of the EBNF?


----------



## MJEggertson (Sep 17, 2002)

Charles, I'll do so when I get home. Thanks.

I think an open-source parser tool in C++ would be an excellent project. It wouldn't be useful unto its own, but it could be implemented in any application that wanted to use it, since if it's well constructed, it can be platform independent.

A java tool would have much overhead, and I think that any application that is written in another language, or is compiled, would frown upon the overhead required to use the java tool.


----------

