Skip to content
Common Expression Language -- specification and binary representation
Branch: master
Clone or download
JimLarson Tests for non-shadowing of constants. (#70)
See #71 for more tests to be added.
Latest commit 90bbd60 Jun 13, 2019
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
doc Update the docs for the standard operators. (#61) Apr 25, 2019
proto/test/v1 Conformance test suite for runtime support of checker environment (#60) Apr 23, 2019
testdata Remove protos which are now in googleapis. (#35) Dec 19, 2018
tests Tests for non-shadowing of constants. (#70) Jun 13, 2019
tools Lint fixes to the CEL Spec Go code. (#52) Feb 12, 2019
.gitignore Remove BUILD targets not supported by Bazel. Mar 14, 2018
.travis.yml Fix map comparison and make fixed tests live. (#62) Jun 8, 2019
CODE_OF_CONDUCT.md
CONTRIBUTING.md Sync CEL proto changes to cel spec. (#16) Apr 6, 2018
LICENSE Rename license file to satisfy Cross linter Aug 23, 2017
README.md
WORKSPACE Fix map comparison and make fixed tests live. (#62) Jun 8, 2019
travis.sh Conformance test driver (#37) Jan 16, 2019

README.md

Common Expression Language

Build Status

The Common Expression Language (CEL) implements common semantics for expression evaluation, enabling different applications to more easily interoperate.

Key Applications

  • Security policy: organization have complex infrastructure and need common tooling to reason about the system as a whole
  • Protocols: expressions are a useful data type and require interoperability across programming languages and platforms.

Guiding philosophy:

  1. Keep it small & fast.
    • CEL evaluates in linear time, is mutation free, and not Turing-complete. This limitation is a feature of the language design, which allows the implementation to evaluate orders of magnitude faster than equivalently sandboxed JavaScript.
  2. Make it extensible.
    • CEL is designed to be embedded in applications, and allows for extensibility via its context which allows for functions and data to be provided by the software that embeds it.
  3. Developer-friendly.
    • The language is approachable to developers. The initial spec was based on the experience of developing Firebase Rules and usability testing many prior iterations.
    • The library itself and accompanying toolings should be easy to adopt by teams that seek to integrate CEL into their platforms.

The required components of a system that supports CEL are:

  • The textual representation of an expression as written by a developer. It is of similar syntax to expressions in C/C++/Java/JavaScript
  • A binary representation of an expression. It is an abstract syntax tree (AST).
  • A compiler library that converts the textual representation to the binary representation. This can be done ahead of time (in the control plane) or just before evaluation (in the data plane).
  • A context containing one or more typed variables, often protobuf messages. Most use-cases will use attribute_context.proto
  • An evaluator library that takes the binary format in the context and produces a result, usually a Boolean.

Example of boolean conditions and object construction:

// Condition
account.balance >= transaction.withdrawal
    || (account.overdraftProtection
    && account.overdraftLimit >= transaction.withdrawal  - account.balance)

// Object construction
common.GeoPoint{ latitude: 10.0, longitude: -5.5 }

For more detail, see:

Released under the Apache License.

Disclaimer: This is not an official Google product.

You can’t perform that action at this time.