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

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



> 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.

> 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.

> 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.

> 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.


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