kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

> This sounds like a sane workflow to me. Dick, please feel free to
> forward me example XML when you are ready.
>
> Best Regards,
>
> Brian.
>
>   


In my experience with XML, working with lower case element and attribute
names leads to better clarity and leaves the values in the lime light
since they can contain upper case characters.  (This is what we had said
for the upcoming S-expression files also.)

There are only a few key XML elements in the generic netlist export, and
the component is certainly one of them.  I am trying to reach the right
comprise between clarity and lack of verbosity, and to avoid situations
where we have to change ' ' with '_' by keeping things wrapped with
proper XML syntax.


Below is what I am thinking, starting with <component>.  The presence of
elements within <fields> after <value> are subject to their presence
within the schematic.  I have promoted "ref" to attribute status instead
of considering it to be a field.  It would not be my intention to remove
spaces from the spellings of the values, I don't see why this needs to
be done since we have delimiters on all values, either a ".." or <>..</>

The user defined field names are the exception to the lower case
desire.  Here I think we have to respect the spelling chosen by the guy
who added these user defined field names so that we can generate a
reasonable BOM from them.

Spacing/formatting is arbitrary of course.

<netlist>

<!--one for every component instantiation: -->

<component ref="R23">
  <fields>
     <value>123k</value>

     <!-- present only if non blank -->
     <footprint>SM0201</footprint> <!-- desired
     <datasheet>dontsheetonmydesk.pdf</datasheet>

     <!-- user defined fields start here. this user is trying to help
          himself in the BOM creation process and has extra fields:
      -->
     <Manufacturer>TI</Manufacturer>
     <Vendor>Digikey ABCD123</Vendor>
  </fields>

  <tstamp>45DC86E7</tstamp>

  <libsource>libname.partname</libsource>

  <!-- pins are intentionally not described here since
       we really don't want to repeat something verbose
       that would need to be duplicated per instance.
  -->

</component>


Then there could be something like specctra's image, one for each unique
part:

<image libsource="libname.partname">

    <!-- image is from specctra, a better name is possible -->

    <!-- here could be a full work up on the pins of
         the part, and as much
         graphical detail as needed.
    -->

    <pins>  <!--generically speaking -->

        help welcomed

    </pins>

</image>

Then one block of nets

<nets>

  <net name="/cfcard.sch/WAIT#">
    <node comp="R23" pin="1"/>
    <node comp="U18" pin="12"/>
  </net>

  <net>
     :
  </net>

  :

</nets>


</netlist>


Please offer any feedback on what you see.  (I don't care as much about
what you don't see, since we can and will add more later.)

And man, after writing this I went and looked at a specctra DSN file
which has the S-expressions and I cannot believe the better readability
of the S-expression files.  It is startling, the difference.

Dick