First draft of JSON Official Schema released

As you can imagine, verifying that the CircuitData JSON files you will output from your application or directly from your ERP-system are in accordance with the standard is of vital importance. The same goes for files you receive - you want to check them before you import them.

The first draft version of the schema is released now. We have focused on JSON files, and have no immediate plans for starting with a XML schema.  In the hand of a developer, schemas become very powerful tools and very necessary to insure that what you send out or receive is valid. Let me give you an example:

In Elmatica, we have created a functionality which allows everybody that receives an offer from us, and the factories that are asked to quote or produce, the possibility to download a CircuitData compatible JSON file. This files can be input into their own system (if they are compliant with the standard), eliminating  the need to punch data manually. 

When the solution that connects to our system and creates the CircuitData JSON was created, a few hours of development was required. The developer went through all the information about the PCB that was stored in stored in the ERP-system, found the syntax for expressing this in the CircuitData language, and created a function to do this on the fly. But without a schema, there is no real way of knowing that the result is valid. With the schema, it becomes a question of just a few lines of code. Let me demonstrate how this is done in Ruby (a development language).

$ irb
2.3.0 :001 > require "json-schema"
 => true
2.3.0 :002 > JSON::Validator.validate!("", "example.json")
JSON::Schema::ValidationError: The property '#/open_trade_transfer_package/products/EXAMPLE-PCB/printed_circuits_fabrication_data/dielectric/0' contains additional properties ["material"] outside of the schema when none are allowed in schema

The first line of code starts a ruby interactive console. The second requires the appropriate validator. The third runs the validator against an example file.

Three lines of code that immediately gives a validation result, and all because of a schema that tells the validator how the standard should look. In this case, the validation failed. And because of the beautiful way the validator is built, it also tell us why: There is something wrong with how we output the dielectric laminate. So instead of sending out faulty files, we can correct the actual problem.

The schema is a vital part of this project and will grow together with it. Right now, the draft is in the GitHub repository under the "v1" folder. It is still lacking some of the more complex functionality such as a stackup, but it is a great start and the result of about a lot of hours. If you want to help us out keeping this project great - get involved!

Reply Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
Like Follow
  • 4 yrs agoLast active
  • 277Views
  • 1 Following