> >> Any other thoughts?
>
> 1 - The data storage should be plain text so it would be highly portable
> and easily debugged, at least as a start.
>
> 2 - The parsing of the data should not mandate the use of higher level
> tools (like bison/yacc). This means simple structure and strong use of
> delimiters.
>
> 3 - The standard should be highly extensible (like XML - but XML breaks
> #2). This includes versioning support and branching support so everyone
> gets to play with his own version if they want to.
>
> 4 - The standard should cover more data than present standards, such as
> combining SPICE models with geometric descriptions, pad layouts, physical
> dimensions and maybe even standard application schematics and abbreviated
> datasheet data where applicable.
>
> 5 - It should provide for linking in of existing (non-open) standards and
> data, such as Eagle library elements (as external files), pdf files, and
> whatever one can think up.
>
> I am well aware that all this can be done in XML but XML is a moving
> target and it requires a relatively heavy infrastructure for parsing and
> editing.
>
> A VHDL-like (which is Pascal-like in a way) approach would look best
> (my opinion) imho.
>
> So keep talking ...

I haven't been able to find any other projects of this nature.  Maybe
I should take that as a hint that it's not a good idea, but I prefer
to go fearlessly forward.

I figure the bare minimum of information required for a part would be
a pad layout, a schematic symbol (or enough info to generate a
symbol), and enough information to identify the part (name,
manufacturer, technology, etc.)

I agree, definitely a plain ASCII text file format, with multiple
files optionally archived into a single library file for
distribution (similar to static libraries for gcc).

I would like to be able to keep part libraries in a CVS repository.
Because of this, I tend to prefer many small files rather than large
monolithic files.

XML is more complicated file format, however, it is widely used and
many libraries are already available to parse XML files.
Anyone else have any other thoughts?  XML, VHDL-like, ??

Depending on my how much time I have, I may start a sourceforge
project to begin discussing this, rather than consuming the piclist
bandwidth.

Mike

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu