@User Totally agree with you. However it is difficult to evaluate xschem from the file format. There is almost no electronics concept in the file format. schematic files are a set of saved graphic primitives (text, lines, circles, etc) and references to symbol files (= component placements) (since in xschem there is no difference between schematic files and symbol files, the definition looks recursive 🙂 ). However every single graphic object (and symbol references as well) carries an attribute field. This makes possible to attach any kind of information to them. In addition to that the whole saved file has an attribute field (to be more precise one attribute per netlisting backend). There is no restriction on the format of all these attributes. I can attach a whole text file as an attribute for a line, for a component placed referencing a symbol, for a text string or as a global attribute for the file as a whole. Attribute fields are often used to define a set of 'token=value' items, for example a placement of an nmos transistor will probably have something like 'model=NLV W=10u L=0.09u' while a net segment will have 'lab=DATA[3]'. The only requirement for the file format is to be rich enough to be able to store any kind of circuit created by any (ab)user, be it digital, analog, stdcell based, full custom design, hierarchical, flat, with all the needed informations, and to produce valid code for all netlisting backends (currently Spice, VHDL, Verilog and tEDAx for pcb-rnd export). The file format is the lowest level, geometrical representation of the circuit. Xschem stores information (where needed) attached to these objects, so that a logical, higher level representation of the circuit can be built (at the logical abstraction level there is a concept of connectivity, electrical nodes, nets, pins, connected components). What i find strange is that some other schematic tools have file records for very specific things, like component footprint, partname, symbol reference, pin, label, ... Sometimes there is a predefined and limited set of fields for describing an object. I think this is not good as does not allow to scale up. Xschem file format does not have any predefined record or field, however any kind of description can be saved, for example if i need to store footprint information together with the component i just add 'footprint=DIP28' to its attributes. It is the netlister backend task (for example a pcb export) to look up these. Another interesting consideration is that netlisting rules for symbols are also stored as global symbol attributes (example: format="@name @pinlist @model w=@w l=@l"), and the '@' character is used to do attribute substitution, so if a component reference has '*name=m28*' attribute and symbol has format="@name...." the corresponding netlist line (for spice in this example) will be M28 .... You see that attributes are used extensively to avoid hardcoding things and give the circuit designer (or component library creator) maximum freedom. Another example: at the very beginning xschem did not have any possibility to change text font or color for schematic text strings. Without changing the file format now the graphic renderer supports multiple fonts and colors, and this additional info is stored as text attributes 'font=monospace layer=8'. Loading these new schematic files on an older xschem will be no problem, it will just ignore the newer attributes. Same thing for circles, recently a 'fill=true' attribute has been added. Anyway, even if i tried to be as general as possible i am interested in peer reviews, this is the best way to find bugs, missing features, design flaws. If you find something or if in doubt just ask me 🙂 Thank you for taking some time to evaluate xschem.

So there’s a low-level format, which alone, like format of json or XML, means little. Critical becomes the detailed “schema” or document-object-model describing specific/explicit attributes & their formats/relationships by which you get things done.

Exactly, of course there are specific attributes that are used to create a valid circuit: see a general discussion in the manual and see the pre-defined set of attributes for symbols and for components (that is, references to symbol files) . Reading some info about XML (it was not existing when i started xschem) i think the concept is exactly that, with the difference that the code for a XML reader/parser/writer is probably bigger than all XSCHEM combined.