An open JSON Schema for electronic-component specifications. Every value records the test conditions under which it holds and a reference to its source in the datasheet. Existing standards omit both.
A datasheet is a PDF. A specified value has meaning only in the context of the table row and column that qualify it. Parametric databases and distributor APIs store a bare number and discard the conditions. Classification dictionaries standardize names and units but provide no field for a condition.
{ "vout": 3.3,
"dropout": 0.28,
"iq": 0.0000315 }
{ "key": "dropout_voltage",
"measurements": [
{ "limitClass": "characterized",
"value": { "typ": 0.28, "max": 0.45 },
"unit": "V",
"conditions": [
{ "param": "I_OUT", "value": 0.2, "unit": "A" } ],
"sourcePage": 5 } ] }
The flat form does not say at what load current the dropout is 0.28 V, whether 3.3 V is a minimum, typical, or maximum, or what the absolute-maximum input rating is. The conditioned form does, and it records the page the value came from.
The schema is small on purpose. One measurement shape, one field that replaces the separate datasheet tables, and one family-agnostic envelope.
A value carries min, typ, nom, max, a base-SI unit, a first-class typed list of test conditions, and the page it was read from.
One field marks a value as an absolute-maximum stress limit, a recommended operating range, or a characterized guarantee. A consumer never treats a stress limit as an operating value.
The parameter shape is family-agnostic. A family dictionary supplies the canonical keys, units, and vendor aliases. Adding a family needs no schema change.
A dictionary defines the canonical parameter keys for one component family. The schema stays agnostic. A validator checks each document's keys against the dictionary named by its family. Two families ship today, a linear regulator and a discrete transistor, which share one envelope.
| Family | Parameters | Covers |
|---|---|---|
ldo |
54 | regulation, dropout, current, protection, rejection and noise, enable, power-good, dynamic, stability, thermal, ESD |
mosfet |
28 | ratings, static, capacitance, gate charge, switching, body diode, thermal |
The same pinout structure carries a regulator's IN, OUT, GND and a transistor's G, D, S, because a pin function is an open controlled vocabulary rather than a fixed set.
Dropout depends strongly on load current, so a single scalar is not usable. The schema records one measurement per point, each with its own condition. This is a real extracted example.
{ "key": "dropout_voltage", "measurements": [
{ "limitClass":"characterized", "value":{"typ":1.0,"max":1.2}, "unit":"V",
"conditions":[{"param":"I_OUT","value":0.1,"unit":"A"}], "sourcePage":4 },
{ "limitClass":"characterized", "value":{"typ":1.05,"max":1.25}, "unit":"V",
"conditions":[{"param":"I_OUT","value":0.5,"unit":"A"}], "sourcePage":4 },
{ "limitClass":"characterized", "value":{"typ":1.2,"max":1.3}, "unit":"V",
"conditions":[{"param":"I_OUT","value":1,"unit":"A"}], "sourcePage":4 } ] }
See the full documents in examples/, spanning four real LDO manufacturers and an illustrative MOSFET.
The schema is self-contained, with no external references. Adopt it at whatever level fits: copy the file, validate against it, or import the typed bindings.
npx ajv-cli validate -s schema/datasheet-1.0.schema.json \ -d my-part.datasheet.json --spec=draft2020
npm i datasheet-schema import { datasheetSchema, ldoDictionary } from 'datasheet-schema'; import type { Datasheet } from 'datasheet-schema';
from datasheet_schema import validate_document doc = validate_document(loaded_json) # pydantic, then JSON Schema
https://nkorai.github.io/datasheet-schema/schema/datasheet-1.0.schema.json
An implementation is conforming if every document it emits validates against the schema. A validator is conforming if it accepts every fixture in the valid set and rejects every fixture in the invalid set. The negative fixtures define what wrong means, because a schema you cannot fail is not a specification.
Not a behavioral model, for which see IBIS and SPICE. Not a manufacturing format, for which see IPC-2581. Not a registration authority, for which see JEDEC.
IEC 61360 and eCl@ss standardize property names and units but have no condition field. Distributor APIs provide identity and flat specifications. None represent a value together with its test conditions and provenance. That is this schema's contribution.