Skip to content

Thomas' musings on PR#49

Thomas Fossati edited this page Feb 9, 2023 · 5 revisions

Musings on PR 49

PR#49 does many different things at the same time:

  1. extends the usual "environment" to also include some "base RVs"
  2. allows different "delta RVs" to be matched in association to the base RVs in an efficient way, as one doesn't need to repeat the base
  3. allows optional endorsed values to be accepted conditional to matching the contextually specified RVs
  4. allows defining the matching precedence explicitly

There's a bunch of new (useful) semantics mixed with some encoding optimisations.

So, lots of good stuff that we may want to use in a way or another.

However, and this is the main problem I have with the proposal as is, it uses a complex construct whose semantics are potentially larger than those envisaged.

I personally prefer smaller, simpler constructs that can be composed into complex statements rather than a fat, polysemic thing that tries to do many things at once.

So, I'd like to take what is good here and move it to our base triples.

First and foremost I think a simple and powerful thing we could lift from PR#49 is the "composite environment" concept that, especially in the context of endorsed values, allows us to address the ambiguity:

  • Is this endorsed value applicable to the environment in general?
  • Or to a specific instance of the environment which has these additional features (i.e., measured values)?

Composite Environment

We could extend the triple subjects to also allow a composite env in a backwards compatible way wrt the TCG spec:

start = new-endval-triple
 
environment-map = "FAKE-environment-map"
measurement-map = "FAKE-measurement-map"
 
; MUST match both the env map && the reference values
ext-environment-record = [
  env: environment-map
  rvs: [ + measurement-map ]
]
 
new-endval-triple = [
  env: environment-map / ext-environment-record
  ev:  measurement-map
]

Multiple Measurements per Triple

Another design decision we may want to reconsider is the 1:1 cardinality of the environment-map -- measurement-map relationship. 1:m seems to be an interesting option that we could achieve again in a backwards compatible way by doing:

new-endval-triple = [
  env: environment-map / ext-environment-record
  evs: measurement-map / [ + measurement-map ]
]