Reference · SemText · Data & tables
<sem-data-query>
SemText element
You write one query: pick columns, filter, sort, and limit. Joins are declared separately, and nothing can change the data. Readers see the results, and the query text stays visible.
Example
Live render boots with JavaScript — the authored source is alongside.
variant: SELECT * with ORDER BY … DESC
The whole-row form — `SELECT *` returns every column in bucket order and `ORDER BY port DESC` sorts the results table descending. No WHERE or LIMIT: both optional clauses are genuinely optional.
Live render boots with JavaScript — the authored source is alongside.
variant: WHERE with AND and IS NULL
Conditions combine with AND / OR (AND binds tighter) and compare against boolean, numeric or string literals. `IS NULL` matches the empty cell, which no `=` comparison ever can.
Live render boots with JavaScript — the authored source is alongside.
variant: a query over a declarative join bucket
The grammar has no JOIN — a `sem-data-join` materializes an extra bucket a query then addresses by name. Here `user-orders` is the inner join of `users` and `orders` on `user-id`: carol (no orders) drops, alice appears twice.
Live render boots with JavaScript — the authored source is alongside.
variant: authoring error — a bucket that does not resolve
A query naming a bucket the visualizer does not declare renders an inline `role=alert` naming the miss; the authored statement is preserved. The same alert appears for an unknown column, a syntax error or a mutating statement.
Live render boots with JavaScript — the authored source is alongside.
Source: spec/schema/sem-data-query.md