Re: gEDA-user: Driving the netlist from PCB (instead of gschem)

[Peter Clifton <pcjc2@xxxxxxxxx>]

On Tue, 2008-09-30 at 12:43 -0400, DJ Delorie wrote:
> > Since it is portable, and externally maintained, the only reason not to
> > consider a library like this would be depending on how "maintained" it
> > is, and how frequently it is going to break ABI.
> 
> We'd still have to define a language to use within the XML syntax; XML
> is just a container.  However, we'd have to do that anyway.

I was refering to IPC-2581. I know XML is just a syntax / grammar.

> > Is there any direct benefit to supporting it (as is) as a native format?
> > If "the industry" support reading / writing it, then perhaps the answer
> > is yes - otherwise we need a native file format, + an importer /
> > exporter for this one.
> 
> "industry support" for xml is like "industry support" for zip files.
> It's not the syntax that's important, it's the data structure within
> it.  Just because we're using XML does NOT mean that other XML-aware
> programs can understand it.

Again, IPC-2581.

> > Could we support a look-alike syntax without being truly XML? (There is
> > probably a lot of XML overheard which isn't even used).
> 
> This is the resource file format.

Thats not what I meant..

I was specifically meaning - support a syntax which is legal "XML", but
not actually "XML". Then you wouldn't have to support xpath, xinclude,
and all the other baggage associated with XML.

You could, for example, define the white-space formatting to be stricter
than XML, choose not to support those features of the XML you don't
need.

> > Could we translitteate the guts of it into a non-XML, more line-based
> > format? (Again, if people are dead-against XML for some or other
> > reason.)
> 
> I understand the desire for line-based files, but I'm pretty sure
> anything flexible enough for our "next generation" format will not be
> one-item-per-line.  At best, it will be one-clause-per-line, so a perl
> or awk script would be able to parse it, but that assumes (as we
> currently do) that the files are kept in a sane formatting.  Our
> current spec does not require one-item-per-line, for example, yet by
> convention we assume it does.

Yes, indeed. That was kindof what I meant. "Line based" was meant to
imply that we'd enforce some stricter formating rules to allow easier
text-based manipulation with sed / awk scripts, and / or make our lives
easier writing the parser for any new format.

Still.. the more complex the structure of the file becomes, the more
intelligence is required to process it, even with awk etc.. As soon as
you have hierarchy in the data, you may have to track opening / closing
of different stanzas etc. - unless your script doesn't care about
_where_ it makes whatever update it is doing.

-- 
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)



_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user