The function model assumed that we would have two levels to check ZObjects, well-formedness and valid.
It seems that this is not exactly sufficient. In this task we try to figure out what conditions of quality control may be relevant, where they should happen, and to give them maybe names, etc.
Well-formedness: is a simple local test which is the same for every ZObject. Well-formedness means that the ZObject can be serialized to a JSON representation that fulfills the following condition:
That doesn't mean that we need to actually serialize it and then check the grammar of the serialization. We can also do that check in ZObject directly, by checking the keys, values, etc.
Valid: every ZObject has a Z1K1/type which points to a Z4/Type, which in turn has a Z4K3/validator that points to a Z8/Function. A ZObject is valid if the application of that function to the ZObject returns an empty list (i.e. returns no errors).
This is a potentially very heavy operation that requires plenty of look-ups. Also, it assumes that the core functions and types are all fine, or else we can't even run functions. That is why we need some inalienable truths, as defined by T260314 - these guarantee that we can actually run the validator.
So we need some term for this level of checking: this object conforms to the inalienable truths defined in T260314
Strawman proposal: call this level "conformant" or "conforming".
Further possible levels of checking:
- all references in a ZObject can be resolved (let's call this "linked")
- Z1K1 has a value of type Z4, which in turn has a Z4K3 of type Z8 (which is a necessary precondition for validation), let's call this "checkable"
All valid ZObjects must be both checkable and linked.
All checkable ZObjects must be conforming.
All conforming ZObjects must be well-formed.
For Z8/Functions and Z14/Implementations there is additionally the notion of Z20/Testers, and there should probably should be a term for an Z14/Implementation that passes all Z20/Testers of the given Z8/Function it implements. Let's call that "Tested". That is only relevant for Implementations. Suggestions: All tested Implementations must be valid (or, stated differently, only valid Implementations may be tested).
There are (at least) two major questions:
- when a ZObject is being edited (or created), what condition does the ZObject need to fulfil in order to be stored by the wiki?
- when a ZObject is being used in an evaluation, what conditions does the ZObject need to fulfil?
Let's quickly note down two features of each of the levels of checking described above: how fast and how self-contained is each level?
- Well-formedness: fast and self-contained. Changes to other ZObjects in the wiki cannot impact the well-formedness of a given ZObject.
- Conforming: fast and self-contained. Changes to other ZObjects in the wiki cannot impact the conformicity of a given ZObject. This is only true because changes to other objects that break the inalienable truths are not allowed.
- Linked: fast and not self-contained. Referenced ZObjects may be deleted, which would turn a linked ZObject into a non-linked one, and creating ZObjects may turn a non-linked ZObject into a linked one.
- Checkable: variable speed, but likely fast-ish, and not self-contained. As this depends on the value of Z1K1, which often will be a reference to a Z4/Type stored in the wiki. This Z4/Type may be deleted or have itself an unlinked validator.
- Valid: variable speed, potentially slow-ish, and not self-contained. The validator may be changed, rendering perfectly valid objects invalid and the other way around.
- Tested: variable speed, potentially very slow, and not self-contained. The testers may change, or be removed, rendering tested implementations failing the tests and the other way around.
So, regarding the questions above:
- a ZObject being stored must be well-formed and conforming. It should probably be linked at the time of storing. It should be checkable at the time of storing. Should it be valid? (I would suggest yes, until the validation checks start taking so long that this becomes unfeasible, and then we revisit the issue). Do implementations need to be tested?
This seems to recommend that we need to have special pages that list unlinked, uncheckable, and invalid ZObjects, so that these can be maintained.
- it seems that a ZObject should only be evaluated if it is valid (otherwise implementations become super-defensive and hard to read and write). Now, doing the validation is a function call, so that is kind a self-referential definition in that case.
We probably need some kind of pragmatic resolution of that knot. Something like "yes, ZObjects must always be valid when being evaluated, but if the function call is the validation itself then this condition is cut". Given that the validation is done by the evaluation engine itself, it should be possible to resolve that issue inside the evaluation engine itself, and not call itself in an infinite loop.