Scripture Burrito 0.2.0 Beta Announcement

The Scripture Burrito working group is pleased to announce the release of the Scripture Burrito 0.2.0 Beta version of the specification!

The docs for this release are at


This standard is still a work in progress. Things may well change significantly before v1.0.0. Prototype code implementing SB is encouraged. Here are a couple of proof of concepts that demonstrate Scripture Burrito functionality:


The 0.2.0-beta release is a complete rewrite of the XML based 0.1.0-beta. We are now using JSON-Schema for defining the specification and the only valid expression of the metadata is JSON.

We have included 8 flavors in this release.

This release also includes variants, which are programmaticly derived from source burritos.


The road ahead includes a few high level items that may be of interest:

  • More specific information about ingredients, along with several example burritos
  • More flavors defined to handle different types of data
  • Refinement of the variant and recipe part of the specification.

For more details, see our issue queue in Github.


Feedback may be provided here, in this forum, or via the Scripture Burrito Github issues.

The committee invites comments on all aspects of this documentation, but has identified some specific issues about which decisions need to be taken:

JSON only for metadata

The 0.1.0 specification was based on an XML schema for metadata with a JSON representation. However, the goal for 0.2.0 was to switch to JSON Schema as the only representation of the metadata. This transition is now completed and 0.2.0-beta represents this change.

Confidentiality Options

The Confidentiality section includes three options, 1. unrestricted, 2. restricted, 3. private. Please comment on issue #90 if you have a use case which is not covered by this enum.

MD5 Checksums

For ingredient (file) checksums we are using the dated MD5 hashing algorithm. See our discussion about this issue. Please open an issue to let us know if this will be problematic for your use case.

USFM and USX for Scripture Text

The current proposal is based on the Digital Bible Library, which chose USX because it can be validated rigorously. As a result of this choice, several large publishing workflows including YouVersion and API.Bible use USX.

Much of the Bible translation world uses USFM, which is familiar to Bible translators, but which requires bespoke parsing tools, and which can be ambiguous in some circumstances. Also, USX contains machine-readable reference information that cannot be represented in USFM at this time. Valid USFM can be round-tripped to USX. USX cannot be round-tripped to USFM without losing the machine-readable references. Invalid USFM may not have an equivalent representation in USX.

Paratext currently uses both USFM and USX internally at various points.

The committee’s current proposal is

  • USFM for translations in progress
  • USX for valid content, orientated towards publication (incremental or otherwise)

The committee would appreciate proposals for constructive and technically feasible alternatives.


The Scripture Burrito working group would like to express our appreciation to Mark Howe for the exceptional work he has put into developing the current Scripture Burrito 0.2.0 specification.

1 Like