docs: update roadmap and value type documentation

Author: jrentlez

README.md

@@ -18,20 +18,20 @@ Data engineers can use Jayvee and its interpreter to clean and preprocess data f
 
 Explore a glimpse of our upcoming features in the following list. This overview is broad and subject to evolution. We're excited to share our vision of the exciting journey ahead, and we invite you to accompany us on this adventure!
 
-- ✅ Blocks and pipes 
+- ✅ Blocks and pipes
 - ✅ Simple value types and constraints
 - ✅ Natively support table-based data
 - ✅ Column-based transformations
 - ✅ Describe blocks via builtin block types in Jayvee
 - ✅ Compose logic of multiple blocks via composite block types
 - ✅ Multi-file Jayvee to distribute programs over multiple files
 - ✅ Jayvee formatter
-- ⌛ Improve the syntax of value types (see [RFC 0014](https://github.com/jvalue/jayvee/pull/409))
+- ✅ Improve the syntax of value types (see [RFC 0014](https://github.com/jvalue/jayvee/pull/409))
+- ✅ Composite value types (with multiple fields)
 - ⌛ Reusable libraries (with a package manager)
 - ⌛ Further extractors and sinks
-- 🤔 Composite value types (with multiple fields)
+- ⌛ Valuetypes parsers (to read and write different formats)
 - 🤔 Natively support tree data (XML, JSON)
-- 🤔 Valuetypes parsers (to read and write different formats)
 - 🤔 Customizable invalid value handling (default value, average, median, interpolation, ...)
 - 🤔 VSCode Debugger
 - 🤔 Block types with multiple ports (e.g., for merging different data)

apps/docs/docs/user/core-concepts.md

@@ -67,7 +67,7 @@ We differentiate the following kinds of _value types_:
 - _Primitive value types_ can be defined by the user to model domain-specific data types and represent a single value.
   _Constraints_ can be added to a _primitive value types_.
   See [primitive value types](./value-types/primitive-value-types).
-- _Compound value types_: UPCOMING.
+- _Compound value types_: IN DEVELOPMENT.
 
 ```jayvee
 valuetype GasFillLevel {

apps/docs/docs/user/value-types/primitive-value-types.md

@@ -4,45 +4,58 @@ sidebar_position: 2
 
 # Primitive Value Types
 
-_Primitive value types_ are based on _built-in value types_ and use a collection of _constraints_ to restrict the range of valid values.
-Such _constraints_ are implicitly connected via a logical `AND` relation.
-Note that the _constraints_ need to be applicable to the base-type of the _value type_ - indicated by the identifier after the keyword `oftype`:
+_Primitive value types_ are comprised of _properties_.
 
 ```jayvee
 valuetype GasFillLevel {
     property level oftype integer;
-    constraint levelRange: GasFillLevelRange on level;
 }
 ```
 
-## Constraints
+A _Property_ is a named "part" with its own _value type_ (type cycles are
+forbidden). _Value types_ with multiple _properties_ are allowed in the
+language, but not yet supported by the interpreter.
 
-_Constraints_ for _value types_ declare the validity criteria that each concrete value is checked against.
 
-### Syntax 1: Expression syntax
+## Constraints
 
-The syntax of expression-based _constraints_ uses an expression that evaluates to `true` or `false` for the given `value`. The type of the values the expression is working in is indicated ofter the keyword `on`:
+_Constraints_ restrict the range of valid values.
 
 ```jayvee
-constraint GasFillLevelRange on decimal:
-    value >= 0 and value <= 100;
+valuetype GasFillLevel {
+    property level oftype integer;
+    constraint levelRange: level >= 0 and level <= 100;
+}
 ```
 
-Refer to the [expression documentation](../expressions.md) for further reading on expressions.
+A _value type_ can have zero or more _constraints_, which are implicitly
+connected via a logical `AND` operation.
+
+_Constraints_ use an _expression_ that evaluates to `true` or `false` and can
+reference every _property_ of the _value type_.
+In the above example, `level >= 0 and level <= 100` is evaluated for each value
+of type `GasFillLevel`, `level` being replaced by that properties actual value.
 
-### Syntax 2: Block-like syntax
+Refer to the [expression documentation](../expressions.md) for further reading
+on _expressions_.
 
-The syntax of _constraints_ is similar to the syntax of _blocks_.
-The availability of property keys and their respective _value types_ is determined by the type of the _constraint_ - indicated by the identifier after the keyword `oftype`:
+### Outline definition.
+
+_Constraints_ can also be defined outside of value types, allowing them to be
+reused.
 
 ```jayvee
-constraint GasFillLevelRange oftype RangeConstraint {
-    lowerBound: 0;
-    lowerBoundInclusive: true;
-    upperBound: 100;
-    upperBoundInclusive: true;
+valuetype GasFillLevel {
+    property level oftype integer;
+    constraint levelRange: GasFillLevelRange on level;
 }
+
+constraint GasFillLevelRange on decimal:
+    value >= 0 and value <= 100;
 ```
 
-Note that the type of _constraint_ also determines its applicability to _value types_.
-For instance, a `RangeConstraint` can only be applied to the numerical types `integer` and `decimal`.
+Since there are no _properties_ to reference from the _constraint_ definition,
+the special `value` keyword represents the tested value.
+Note that reusable _constraints_ need to be applied to exactly one _property_ of
+the _value type_ - indicated by the identifier after the keyword `on`.
+