A Canonical S-expression (or csexp) is a binary encoding form of a subset of general S-expression. It was designed for use in SPKI to retain the power of S-expressions and ensure canonical form for applications such as digital signatures while achieving the compactness of a binary form and maximizing the speed of parsing.
The particular subset of general S-expressions applicable here is composed of atoms, which are byte strings, and parentheses used to delimit lists or sub-lists. These S-expressions are fully recursive.
While S-expressions are typically encoded as text, with spaces delimiting atoms and quotation marks used to surround atoms that contain spaces, when using the canonical encoding each atom is encoded as a length-prefixed byte string. No whitespace separating adjacent elements in a list is permitted. The length of an atom is expressed as an ASCII decimal number followed by a ":".
(this "Canonical S-expression" has 5 atoms)
becomes the csexp
Note that no quotation marks are required to escape the space character internal to the atom "Canonical S-expression", because the length prefix clearly points to the end of the atom. Note also that there is no whitespace separating an atom from the next element in the list.
- Uniqueness of canonical encoding: Forbidding whitespace between list elements and providing just one way of encoding atoms ensures that every S-expression has exactly one encoded form. Since the unique encoded form is itself a sequence of bytes, by hashing it we can provide every S-expression with a unique hash value. Furthermore, we can decide whether two S-expressions are equivalent by comparing their encodings.
- Support for binary data: Atoms can be any binary string. So, a cryptographic hash value or a public key modulus that would otherwise have to be encoded in base64 or some other printable encoding can be expressed in csexp as its binary bytes.
- Support for type-tagging encoded information: A csexp includes a non-S-expression construct for indicating the encoding of a string, when that encoding is not obvious. Any atom in csexp can be prefixed by a single atom in square brackets - such as "[4:JPEG]" or "[24:text/plain;charset=utf-8]".
Interpretation and Restrictions
While csexps generally permit empty lists, empty atoms, and so forth, certain uses of csexps impose additional restrictions. For example, csexps as used in SPKI have one limitation compared to csexps in general: every list must start with an atom, and therefore there can be no empty lists.
Typically, a list's first atom is treated as one treats an element name in XML.
Comparisons to other encodings
There are other encodings in common use:
Generally, csexp has a parser one or two decimal orders of magnitude smaller than that of either XML or ASN.1. This small size and corresponding speed give csexp its main advantage. In addition to the parsing advantage, there are other differences.
csexp vs. XML
The biggest difference between csexp and XML is probably that csexp is primarily a data-representation format, while XML includes a data-representation format and a schema mechanism. Thus, XML anticipates that XML data will conform to some grammar (say, HTML, ATOM, Docbook, MathML, or whatever), and provides a language DTD for expressing such grammars. However, both XML and csexp can operate with schemas implemented at a higher level, or with no schemas at all.
In terms of data representation csexp is roughly as expressive as XML. This is not surprising, since XML can be described as a differently-punctuated form for LISP-like S-expressions. An XML element has a name and a sequence of children: some may be elements, and some may be text strings. So far this is exactly like csexp, except that (see below) a cdexp "string" may have any byte sequence whatsoever, while XML text content requires alternate representations for a few characters (such as "<" and most control characters).
An XML element may also have attributes, a construct that csexp does not share. To represent XML data in csexp, one must choose a representation for such attributes; an obvious one is to reserve the second item in each s-expression for a list of (name value) pairs, analogous to the LISP association list. The XML ID and IDREF attributes have no equivalent in csexp, but can be easily implemented by a csexp application program.
Finally, an XML element may contain comments and/or processing instructions. csexp has no specific equivalents, but they are trivial to represent, merely by reserving a name for each. For example, naming them "*COM" and "*PI" (the "*" prevents ever colliding with XML element type names):
(4:*COM15:Text of comment) (3:*PI6:target11:font="helv")
The first atom in a csexp list - which roughly corresponds to an XML element type name - can be any atom in any encoding (e.g., a JPEG, a UNICODE string, a WAV file, ...). XML element names are identifiers, and constrained to certain characters (for example, no spaces, control characters, or dingbats, and only a few punctuation marks).
Similarly, csexp atoms are binary (consisting of a length prefix followed by totally arbitrary bytes), while XML is designed to be human-readable - so arbitrary bytes in XML must be encoded somehow (for example, a bitmapped image can be included using base64). This means that storing large amounts of non-readable information in uncompressed XML takes more space; on the other hand, it will survive translation between alternate character sets (including transmission through network hosts that may apply differing character sets, line-end conventions, etc.).
It has been suggested that XML "merges" a sequence of strings within one element into a single string, while csexp allows a sequence of atoms within a list and those atoms remain separate from one another; but this is incorrect. Exactly like s-expressions and csexp, XML has a notion of a "sequence of strings" only if the "strings" are separated somehow:
<s>String A</s><s>String B</s> versus <s>String AString B</s>
("String A" "String B") versus ("String AString B")
(8:String A8:String B) versus (16:String AString B)
csexp vs. ASN.1
ASN.1 is a popular binary encoding form. However, it expresses only syntax (data types), not semantics. Two different structures - each a SEQUENCE of two INTEGERS - have identical representations on the wire (barring special tag choices to distinguish them). To parse an ASN.1 structure, one must tell the parser what set of structures one is expecting and the parser must match the data type being parsed against the structure options. This adds to the complexity of an ASN.1 parser.
A csexp structure carries some indication of its own semantics (encoded in element names), and the parser for a csexp structure does not care what structure is being parsed. Once a wire-format expression has been parsed into an internal tree form (similar to XML's DOM), the consumer of that structure can examine it for conformance to what was expected. As noted above, an XML document without a schema works just like csexp in this respect, while an XML document with them can work more like ASN.1.
- Ron Rivest's sexp page
- Ron Rivest's IETF-draft describing S-expressions
- various uses of csexp, including s2x: translating csexp to XML
Notes and references
- This similarity was known to the framers of XML. For example, Steven DeRose discussed it in The SGML FAQ Book: Understanding the Relationship of SGML and XML, Kluwer Academic Publishers, 1997. ISBN 978-0-7923-9943-8.
- The SAX interface to XML allows an XML parser to break up (single) text strings any way it likes. Some implementations return multiple lines as single text nodes, which may have led to this common misunderstanding.