The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Designing a simple file format

Hello,
I am trying to design a simple file format/decide how to parse it.
Criterias:
C1: easy for users to edit such a file by hand.
C2: easy for me to parse it.

Most of the file could be of the following form: 
var1=val1
var2=val2

In order to make the file a bit more tidy it would be useful to group variables together. This could e.g. be done by comments and/or namespaces:
% Section 1
section1::var1=val1
section1::var2=val2
% Section 2
section2::var1=val1
section2::var2=val2

Instead of hardcoding the variable names I could have a "grammar" file:
section1::var1
section1::var2
section2::var1
section2::var2
and match the input file with this.

Here comes the difficult part however: 
Some parts of the file however need to be conditional a la:
type=cartesian
re=1.0
im=1.0
OR
type=polar
r=1.41
phi=45
(the number of variables may also depend on type).
I do not understand how I should specify this in my "grammar" file or how I automate the parsing of such a file.
 
I program in C++ and use the Qt toolkit.

Thanks in advance for any suggestions!
Andreas Werner Paulsen Send private email
Sunday, January 07, 2007
 
 
XML?
JW
Sunday, January 07, 2007
 
 
Or YAML.  Or, indeed, from the examples given, it's not clear why something basic like the old INI format wouldn't suffice; there are numerous libraries that handle formats like that.

Even if none of the many existing configuration file libraries quite suit your needs, by looking around you should be able to get some good hints as to how to design your own.
Iago
Sunday, January 07, 2007
 
 
This approach would have some advantages: less work for me to parse and I could use DTD for specifying the grammar.

Would it be possible to specify conditional sections like in my example with DTD? 

On the other hand I worry that the user will find such a file hard to read and edit by hand.
To me XML often appear verbose and difficult to read.
Especially having to tag around values e.g:
<var2>val2</var2>
instead of merely
var2=val2
may annoy some users.
Andreas Werner Paulsen Send private email
Sunday, January 07, 2007
 
 
Sorry:
my latest post was referring to XML.
Andreas Werner Paulsen Send private email
Sunday, January 07, 2007
 
 
XML is easy to read and write using the QDOM* classes in Qt.

If you want something easy for users to edit by hand you could try the old-style .ini files.
Andy Brice Send private email
Sunday, January 07, 2007
 
 
XML seems like a great fit. Why would your users need to edit the raw data anyway! Surely they should have a nice GUI for that. If need be there are good free XML editors around they can use.
Neville Franks Send private email
Sunday, January 07, 2007
 
 
Anybody with enough technical savvy to edit an .ini file won't have a problem with XML.

Now, using a make file would be a different story...
*myName Send private email
Sunday, January 07, 2007
 
 
It's pretty easy for even relatively tech savvy people to screw up an XML file. Any unescaped & < or > will make it blow up. Ampersands crop up pretty regularly in URLs.
Duncan Smart
Monday, January 08, 2007
 
 
Whatever you do, please allow comments.

Nothing's worse than an .ini file with a hundred different parameters in it, but no way to comment what each one is supposed to be.

Especially if that .ini file is supposed to be manually edited or verified at some point.
AllanL5
Monday, January 08, 2007
 
 
Oh, and one thing I have found helpful is to define a "continuation character" -- like an '_' all by itself -- so that long strings can be broken across lines.
AllanL5
Monday, January 08, 2007
 
 
> easy for users to edit such a file by hand

If you are designing for this, it must imply they have a *need* or *desire* to edit it by hand.

If it is a *need*, then maybe you need to work on your GUI.

If it is a *desire*, then your customers are probably hardened Linux/Unix users, in which case use a format they are familiar with.
Adrian
Monday, January 08, 2007
 
 
I vote for XML, ampersands notwithstanding.  You can define a simple XML grammar or schema to validate the file and use an off the shelf XML parser to load the data into objects and/or output validation errors.

<cartesian re="1.0" im="1.0"/>
<polar r="1.41" phi="45"/>


If the nodes need a type or name then something like

<node name="foo" type="cartesian" re="1.0" im="1.0"/>
<node name="bar" type="polar" r="1.41" phi="45"/>

You could make it easier to read by laying it out thus:

<
cartesian
re="1.0"
im="1.0"
/>


<
polar
r="1.41"
phi="45"
/>


Failing that I would second the suggestions to investigate INI file parsers.
Dan Fleet Send private email
Monday, January 08, 2007
 
 
You could use a a parser generator like Antlr, if you learn how to use it, then making parsers becomes almost trivial and are more flexible than most handwritten parsers.
Jason Moore Send private email
Monday, January 08, 2007
 
 
I would vote for XML over INI just because it is much easier to implement lists/groups and relationsships in XML. Even if you don't need these things now you could in the near future. Trying to implement a list of related values in an INI file is a pain.
Turtle Rustler
Tuesday, January 09, 2007
 
 
Lua seems perfect for your requirements.
http://www.lua.org.
Chris
Wednesday, January 10, 2007
 
 
Maybe JSON?
Gary van der Merwe Send private email
Thursday, January 11, 2007
 
 
Simplest format that I know of like this is the .INI format:

[Section_1]
abc=xyz
def=pdq

; yes, there's a space
[Section Two]
X123 = -54



Lots of parsers for that.

XML, JSON, etc., way too much work unless you need to send this file between programs.
frustrated
Friday, January 19, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz