[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: gEDA-user: PCB suggestion



> On Friday 07 January 2005 09:44, Evan Lavelle wrote:
> >
> > Maybe I'm being thick here, but what exactly would the advantages of an
> > XML file format be?
> 
> The main point is that XML is self-describing for people reading the file, 
> which makes backward and forward compatibility trivial compared to what we 
> have now.  
> 
> If you look at the documentation for some PCB feature, it will say there are 
> four arguments, but the the output file will have six arguments.  You don't 
> know what the last two are, so you set them to zero when you add to the file, 
> but that causes PCB to crash.

This is not a problem with the file format, this is a problem with the
documentation.   The PCB documentation is kind of old, and a little
disorganized.  This is not to slag it off, since the developers have
done a lot of hard work on the program and the documentation.  Rather,
it is just a result of PCB's long & meandering history.

FWIW, Steve Meier wrote a nice doc containing info about the newlib
footprints.  I've thrown some stuff in there too.  It is a work in
progress; we're waiting for input from the PCB developers since some
footprint elements aren't fully documented yet.  However, if you want
to see the latest rev, download the doc from:

www.meierrippin.com/land_patterns_20041229.pdf

BTW:  We'd appreciate any input from others.  If you are interested, I
can send you an OpenOffice .sxw file for you to edit.  Please feel
free to take the .sxw doc and rev it & send the updated copy to me. 

=================================================================

As for an XML fileformat, this topic seems to come up with some
regularity.  It doesn't make a bit of sense, IMHO.  The two reasons
offered for an XML file format are easily refuted: 

Pro reason 1.  XML is human readable.  True, but any well-documented
ASCII file format is human readable.  We already have an ASCII file
format for PCB.  We just need to fix the PCB documentation. 

Pro reason 2.  XML is easily parsed using open-source parsers.  True
enough, but parsing is only a small, first step in reading a file
into PCB.  The real job when reading any file is to fill out the
data structures with the data which has been read in.  This is already
done using the current PCB input routines.  Switching to an XML file
format would involve integrating one of the available parsers into the
rest of PCB, which would be a lot of work, but offer no advantages
over the existing file format. 

There are plenty of reasons to not use an XML file format.  Here are
two big ones:

1.  XML is unnecessarily bloated & complicated.  Particularly for
simple, well-structured, nearly flat data like PCB's files, there is
no need to use the awesome power and multifaceted flexibility of XML.
XML is better suited to encapsulating complicated, polymorphous,
tree-structured data.  

The requirements for PCB's file format are simple: 
it's basically a list of graphical objects, and some info about where
to place them.  It is at most two levels of hierarchy -- one for the
footprint, and one for the lines, pads, pins, etc. making up the
footprint.  XML's power doesn't buy anything for this kind of data.

2.  The biggest reason to not use XML is that we already have a
working file format with associated file reading and writing code.
Transitioning to XML is a major, architectural change to PCB.
Everybody talks about changing the program; almost nobody actually
implements the changes.  If I had my druthers for PCB, I'd rather see
developer effort used to upgrade the UI to GTK, rather than wasted on
migrating to an XML file format -- a change which would be invisible
to ordinary users.

Stuart