diff --git a/docs/_index.md b/docs/_index.md
index b3bf7f12e3..3986352f27 100644
--- a/docs/_index.md
+++ b/docs/_index.md
@@ -5,17 +5,17 @@ heading: SuperDB
---
SuperDB offers a new approach that makes it easier to manipulate and manage
-your data. With its [super-structured data model](formats/_index.md#2-a-super-structured-pattern),
+your data. With its [super-structured data model](formats#2-a-super-structured-pattern),
messy JSON data can easily be given the fully-typed precision of relational tables
without giving up JSON's uncanny ability to represent eclectic data.
## Getting Started
-Trying out SuperDB is easy: just [install](install.md) the command-line tool
-[`super`](commands/super.md) and run through the [tutorial](tutorials/zq.md).
+Trying out SuperDB is easy: just [install](install) the command-line tool
+[`super`](commands/super) and run through the [tutorial](tutorials/zq).
Compared to putting JSON data in a relational column, the
-[super-structured data model](formats/zed.md) makes it really easy to
+[super-structured data model](formats/zed) makes it really easy to
mash up JSON with your relational tables. The `super` command is a little
like [DuckDB](https://duckdb.org/) and a little like
[`jq`](https://stedolan.github.io/jq/) but super-structured data ties the
@@ -25,44 +25,44 @@ For a non-technical user, SuperDB is as easy to use as web search
while for a technical user, SuperDB exposes its technical underpinnings
in a gradual slope, providing as much detail as desired,
packaged up in the easy-to-understand
-[Super JSON data format](formats/jsup.md) and
-[SuperPipe language](language/_index.md).
+[Super JSON data format](formats/jsup) and
+[SuperPipe language](language).
While `super` and its accompanying data formats are production quality, the project's
-[SuperDB data lake](commands/super-db.md) is a bit earlier in development.
+[SuperDB data lake](commands/super-db) is a bit earlier in development.
## Terminology
"Super" is an umbrella term that describes
a number of different elements of the system:
-* The [super data model](formats/zed.md) is the abstract definition of the data types and semantics
+* The [super data model](formats/zed) is the abstract definition of the data types and semantics
that underlie the super-structured data formats.
-* The [super data formats](formats/_index.md) are a family of
-[human-readable (Super JSON, JSUP)](formats/jsup.md),
-[sequential (Super Binary, BSUP)](formats/bsup.md), and
-[columnar (Super Columnar, CSUP)](formats/csup.md) formats that all adhere to the
+* The [super data formats](formats) are a family of
+[human-readable (Super JSON, JSUP)](formats/jsup),
+[sequential (Super Binary, BSUP)](formats/bsup), and
+[columnar (Super Columnar, CSUP)](formats/csup) formats that all adhere to the
same abstract super data model.
-* The [SuperPipe language](language/_index.md) is the system's pipeline language for performing
+* The [SuperPipe language](language) is the system's pipeline language for performing
queries, searches, analytics, transformations, or any of the above combined together.
-* A [SuperPipe query](language/overview.md) is a script that performs
+* A [SuperPipe query](language/overview) is a script that performs
search and/or analytics.
-* A [SuperPipe shaper](language/shaping.md) is a script that performs
+* A [SuperPipe shaper](language/shaping) is a script that performs
data transformation to _shape_
the input data into the desired set of organizing super-structured data types called "shapes",
which are traditionally called _schemas_ in relational systems but are
much more flexible in SuperDB.
-* A [SuperDB data lake](commands/super-db.md) is a collection of super-structured data stored
-across one or more [data pools](commands/super-db.md#data-pools) with ACID commit semantics and
+* A [SuperDB data lake](commands/super-db) is a collection of super-structured data stored
+across one or more [data pools](commands/super-db#data-pools) with ACID commit semantics and
accessed via a [Git](https://git-scm.com/)-like API.
## Digging Deeper
-The [SuperPipe language documentation](language/_index.md)
+The [SuperPipe language documentation](language)
is the best way to learn about `super` in depth.
All of its examples use `super` commands run on the command line.
Run `super -h` for a list of command options and online help.
-The [`super db` documentation](commands/super-db.md)
+The [`super db` documentation](commands/super-db)
is the best way to learn about the SuperDB data lake.
All of its examples use `super db` commands run on the command line.
Run `super db -h` or `-h` with any subcommand for a list of command options
@@ -92,7 +92,7 @@ or other third-party services to interpret the lake data.
Once copied, a new service can be instantiated by pointing a `super db serve`
at the copy of the lake.
-Functionality like [data compaction](commands/super-db.md#manage) and retention are all API-driven.
+Functionality like [data compaction](commands/super-db#manage) and retention are all API-driven.
Bite-sized components are unified by the super-structured data, usually in the SUPZ format:
* All lake meta-data is available via meta-queries.
diff --git a/docs/commands/_index.md b/docs/commands/_index.md
index f618316376..02ad79c4ac 100644
--- a/docs/commands/_index.md
+++ b/docs/commands/_index.md
@@ -3,15 +3,15 @@ title: Commands
weight: 2
---
-The [`super` command](super.md) is used to execute command-line queries on
-inputs from files, HTTP URLs, or [S3](../integrations/amazon-s3.md).
+The [`super` command](super) is used to execute command-line queries on
+inputs from files, HTTP URLs, or [S3](../integrations/amazon-s3).
-The [`super db` sub-commands](super-db.md) are for creating, configuring, ingesting
+The [`super db` sub-commands](super-db) are for creating, configuring, ingesting
into, querying, and orchestrating SuperDB data lakes. These sub-commands are
organized into further subcommands like the familiar command patterns
of `docker` or `kubectl`.
-All operations with these commands utilize the [super data model](../formats/_index.md)
-and provide querying via [SuperSQL](../language/_index.md).
+All operations with these commands utilize the [super data model](../formats)
+and provide querying via [SuperSQL](../language).
Built-in help for `super` and all sub-commands is always accessible with the `-h` flag.
diff --git a/docs/commands/super-db.md b/docs/commands/super-db.md
index febae54da4..77c8699b08 100644
--- a/docs/commands/super-db.md
+++ b/docs/commands/super-db.md
@@ -5,7 +5,7 @@ title: super db
> **TL;DR** `super db` is a sub-command of `super` to manage and query SuperDB data lakes.
> You can import data from a variety of formats and it will automatically
-> be committed in [super-structured](../formats/_index.md)
+> be committed in [super-structured](../formats)
> format, providing full fidelity of the original format and the ability
> to reconstruct the original data without loss of information.
>
@@ -16,13 +16,13 @@ title: super db
:::tip Status
-While [`super`](super.md) and its accompanying [formats](../formats/_index.md)
+While [`super`](super) and its accompanying [formats](../formats)
are production quality, the SuperDB data lake is still fairly early in development
and alpha quality.
That said, SuperDB data lakes can be utilized quite effectively at small scale,
or at larger scales when scripted automation
is deployed to manage the lake's data layout via the
-[lake API](../lake/api.md).
+[lake API](../lake/api).
Enhanced scalability with self-tuning configuration is under development.
:::
@@ -32,7 +32,7 @@ Enhanced scalability with self-tuning configuration is under development.
A SuperDB data lake is a cloud-native arrangement of data, optimized for search,
analytics, ETL, data discovery, and data preparation
at scale based on data represented in accordance
-with the [super data model](../formats/zed.md).
+with the [super data model](../formats/zed).
A lake is organized into a collection of data pools forming a single
administrative domain. The current implementation supports
@@ -70,7 +70,7 @@ bite-sized chunks for learning how the system works and how the different
components come together.
While the CLI-first approach provides these benefits,
-all of the functionality is also exposed through [an API](../lake/api.md) to
+all of the functionality is also exposed through [an API](../lake/api) to
a lake service. Many use cases involve an application like
[SuperDB Desktop](https://zui.brimdata.io/) or a
programming environment like Python/Pandas interacting
@@ -115,8 +115,8 @@ replication easy to support and deploy.
The cloud objects that comprise a lake, e.g., data objects,
commit history, transaction journals, partial aggregations, etc.,
-are stored as super-structured data, i.e., either as [row-based Super Binary](../formats/bsup.md)
-or [Super Columnar](../formats/csup.md).
+are stored as super-structured data, i.e., either as [row-based Super Binary](../formats/bsup)
+or [Super Columnar](../formats/csup).
This makes introspection of the lake structure straightforward as many key
lake data structures can be queried with metadata queries and presented
to a client for further processing by downstream tooling.
@@ -261,11 +261,11 @@ which is the sort key for all data stored in the lake. Different data pools
can have different pool keys but all of the data in a pool must have the same
pool key.
-As pool data is often comprised of [records](../formats/zed.md#21-record) (analogous to JSON objects),
+As pool data is often comprised of [records](../formats/zed#21-record) (analogous to JSON objects),
the pool key is typically a field of the stored records.
When pool data is not structured as records/objects (e.g., scalar or arrays or other
non-record types), then the pool key would typically be configured
-as the [special value `this`](../language/pipeline-model.md#the-special-value-this).
+as the [special value `this`](../language/pipeline-model#the-special-value-this).
Data can be efficiently scanned if a query has a filter operating on the pool
key. For example, on a pool with pool key `ts`, the query `ts == 100`
@@ -294,7 +294,7 @@ optimize scans over such data is impaired.
Because commits are transactional and immutable, a query
sees its entire data scan as a fixed "snapshot" with respect to the
-commit history. In fact, the [`from` operator](../language/operators/from.md)
+commit history. In fact, the [`from` operator](../language/operators/from)
allows a commit object to be specified with the `@` suffix to a
pool reference, e.g.,
```
@@ -331,7 +331,7 @@ Time travel using timestamps is a forthcoming feature.
## `super db` Commands
-While `super db` is itself a sub-command of [`super`](super.md), it invokes
+While `super db` is itself a sub-command of [`super`](super), it invokes
a large number of interrelated sub-commands, similar to the
[`docker`](https://docs.docker.com/engine/reference/commandline/cli/)
or [`kubectl`](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands)
@@ -347,16 +347,16 @@ for that sub-command.
sub-command and so forth.
By default, commands that display lake metadata (e.g., [`log`](#log) or
-[`ls`](#ls)) use the human-readable [lake metadata output](super.md#superdb-data-lake-metadata-output)
+[`ls`](#ls)) use the human-readable [lake metadata output](super#superdb-data-lake-metadata-output)
format. However, the `-f` option can be used to specify any supported
-[output format](super.md#output-formats).
+[output format](super#output-formats).
### Auth
```
super db auth login|logout|method|verify
```
Access to a lake can be secured with [Auth0 authentication](https://auth0.com/).
-A [guide](../integrations/zed-lake-auth.md) is available with example configurations.
+A [guide](../integrations/zed-lake-auth) is available with example configurations.
Please reach out to us on our [community Slack](https://www.brimdata.io/join-slack/)
if you have feedback on your experience or need additional help.
@@ -403,7 +403,7 @@ The `-orderby` option indicates the [pool key](#pool-key) that is used to sort
the data in lake, which may be in ascending or descending order.
If a pool key is not specified, then it defaults to
-the [special value `this`](../language/pipeline-model.md#the-special-value-this).
+the [special value `this`](../language/pipeline-model#the-special-value-this).
A newly created pool is initialized with a branch called `main`.
@@ -468,12 +468,12 @@ a "table" as all super-structured data is _self describing_ and can be queried i
schema-agnostic fashion. Data of any _shape_ can be stored in any pool
and arbitrary data _shapes_ can coexist side by side.
-As with [`super`](super.md),
-the [input arguments](super.md#usage) can be in
-any [supported format](super.md#input-formats) and
+As with [`super`](super),
+the [input arguments](super#usage) can be in
+any [supported format](super#input-formats) and
the input format is auto-detected if `-i` is not provided. Likewise,
the inputs may be URLs, in which case, the `load` command streams
-the data from a Web server or [S3](../integrations/amazon-s3.md) and into the lake.
+the data from a Web server or [S3](../integrations/amazon-s3) and into the lake.
When data is loaded, it is broken up into objects of a target size determined
by the pool's `threshold` parameter (which defaults to 500MiB but can be configured
@@ -538,7 +538,7 @@ The `date` field here is used by the lake system to do [time travel](#time-trave
through the branch and pool history, allowing you to see the state of
branches at any time in their commit history.
-Arbitrary metadata expressed as any [Super JSON value](../formats/jsup.md)
+Arbitrary metadata expressed as any [Super JSON value](../formats/jsup)
may be attached to a commit via the `-meta` flag. This allows an application
or user to transactionally commit metadata alongside committed data for any
purpose. This approach allows external applications to implement arbitrary
@@ -547,7 +547,7 @@ commit history.
Since commit objects are stored as super-structured data, the metadata can easily be
queried by running the `log -f bsup` to retrieve the log in Super Binary format,
-for example, and using [`super`](super.md) to pull the metadata out
+for example, and using [`super`](super) to pull the metadata out
as in:
```
super db log -f bsup | super -c 'has(meta) | yield {id,meta}' -
@@ -580,7 +580,7 @@ A commit object includes
an optional author and message, along with a required timestamp,
that is stored in the commit journal for reference. These values may
be specified as options to the [`load`](#load) command, and are also available in the
-[lake API](../lake/api.md) for automation.
+[lake API](../lake/api) for automation.
:::tip note
The branchlog meta-query source is not yet implemented.
@@ -612,7 +612,7 @@ If the `-monitor` option is specified and the lake is [located](#locating-the-la
via network connection, `super db manage` will run continuously and perform updates
as needed. By default a check is performed once per minute to determine if
updates are necessary. The `-interval` option may be used to specify an
-alternate check frequency in [duration format](../formats/jsup.md#23-primitive-values).
+alternate check frequency in [duration format](../formats/jsup#23-primitive-values).
If `-monitor` is not specified, a single maintenance pass is performed on the
lake.
@@ -657,13 +657,13 @@ according to configured policies and logic.
```
super db query [options]
```
-The `query` command runs a [SuperSQL](../language/_index.md) query with data from a lake as input.
-A query typically begins with a [`from` operator](../language/operators/from.md)
+The `query` command runs a [SuperSQL](../language) query with data from a lake as input.
+A query typically begins with a [`from` operator](../language/operators/from)
indicating the pool and branch to use as input.
The pool/branch names are specified with `from` in the query.
-As with [`super`](super.md), the default output format is Super JSON for
+As with [`super`](super), the default output format is Super JSON for
terminals and Super Binary otherwise, though this can be overridden with
`-f` to specify one of the various supported output formats.
@@ -685,7 +685,7 @@ Filters on pool keys are efficiently implemented as the data is laid out
according to the pool key and seek indexes keyed by the pool key
are computed for each data object.
-When querying data to the [Super Binary](../formats/bsup.md) output format,
+When querying data to the [Super Binary](../formats/bsup) output format,
output from a pool can be easily piped to other commands like `super`, e.g.,
```
super db query -f bsup 'from logs' | super -f table -c 'count() by field' -
@@ -699,7 +699,7 @@ By default, the `query` command scans pool data in pool-key order though
the query optimizer may, in general, reorder the scan to optimize searches,
aggregations, and joins.
An order hint can be supplied to the `query` command to indicate to
-the optimizer the desired processing order, but in general, [`sort` operators](../language/operators/sort.md)
+the optimizer the desired processing order, but in general, [`sort` operators](../language/operators/sort)
should be used to guarantee any particular sort order.
Arbitrarily complex queries can be executed over the lake in this fashion
@@ -773,7 +773,7 @@ super db serve [options]
```
The `serve` command implements the [server personality](#command-personalities) to service requests
from instances of the client personality.
-It listens for [lake API](../lake/api.md) requests on the interface and port
+It listens for [lake API](../lake/api) requests on the interface and port
specified by the `-l` option, executes the requests, and returns results.
The `-log.level` option controls log verbosity. Available levels, ordered
diff --git a/docs/commands/super.md b/docs/commands/super.md
index 2feb835b8c..99eb9a46de 100644
--- a/docs/commands/super.md
+++ b/docs/commands/super.md
@@ -3,10 +3,10 @@ weight: 1
title: super
---
-> **TL;DR** `super` is a command-line tool that uses [SuperSQL](../language/_index.md)
-> to query a variety of data formats in files, over HTTP, or in [S3](../integrations/amazon-s3.md)
+> **TL;DR** `super` is a command-line tool that uses [SuperSQL](../language)
+> to query a variety of data formats in files, over HTTP, or in [S3](../integrations/amazon-s3)
> storage. Best performance is achieved when operating on data in binary formats such as
-> [Super Binary](../formats/bsup.md), [Super Columnar](../formats/csup.md),
+> [Super Binary](../formats/bsup), [Super Columnar](../formats/csup),
> [Parquet](https://github.com/apache/parquet-format), or
> [Arrow](https://arrow.apache.org/docs/format/Columnar.html#ipc-streaming-format).
@@ -18,7 +18,7 @@ super [ options ] [ -c query ] input [ input ... ]
`super` is a command-line tool for processing data in diverse input
formats, providing data wrangling, search, analytics, and extensive transformations
-using the [SuperSQL](../language/_index.md) dialect of SQL. Any SQL query expression
+using the [SuperSQL](../language) dialect of SQL. Any SQL query expression
may be extended with [pipe syntax](https://research.google/pubs/sql-has-problems-we-can-fix-them-pipe-syntax-in-sql/)
to filter, transform, and/or analyze input data.
Super's SQL pipes dialect is extensive, so much so that it can resemble
@@ -26,12 +26,12 @@ a log-search experience despite its SQL foundation.
The `super` command works with data from ephemeral sources like files and URLs.
If you want to persist your data into a data lake for persistent storage,
-check out the [`super db`](super-db.md) set of commands.
+check out the [`super db`](super-db) set of commands.
-By invoking the `-c` option, a query expressed in the [SuperSQL language](../language/_index.md)
+By invoking the `-c` option, a query expressed in the [SuperSQL language](../language)
may be specified and applied to the input stream.
-The [super data model](../formats/zed.md) is based on [super-structured data](../formats/_index.md#2-a-super-structured-pattern), meaning that all data
+The [super data model](../formats/zed) is based on [super-structured data](../formats#2-a-super-structured-pattern), meaning that all data
is both strongly _and_ dynamically typed and need not conform to a homogeneous
schema. The type structure is self-describing so it's easy to daisy-chain
queries and inspect data at any point in a complex query or data pipeline.
@@ -96,7 +96,7 @@ is equivalent to
SELECT VALUE 1+1
```
To learn more about shortcuts, refer to the SuperSQL
-[documentation on shortcuts](../language/pipeline-model.md#implied-operators).
+[documentation on shortcuts](../language/pipeline-model#implied-operators).
For built-in command help and a listing of all available options,
simply run `super` with no arguments.
@@ -104,9 +104,9 @@ simply run `super` with no arguments.
## Data Formats
`super` supports a number of [input](#input-formats) and [output](#output-formats) formats, but the super formats
-([Super Binary](../formats/bsup.md),
-[Super Columnar](../formats/csup.md),
-and [Super JSON](../formats/jsup.md)) tend to be the most versatile and
+([Super Binary](../formats/bsup),
+[Super Columnar](../formats/csup),
+and [Super JSON](../formats/jsup)) tend to be the most versatile and
easy to work with.
`super` typically operates on binary-encoded data and when you want to inspect
@@ -126,12 +126,12 @@ in the order appearing on the command line forming the input stream.
| Option | Auto | Specification |
|-----------|------|------------------------------------------|
| `arrows` | yes | [Arrow IPC Stream Format](https://arrow.apache.org/docs/format/Columnar.html#ipc-streaming-format) |
-| `bsup` | yes | [Super Binary](../formats/bsup.md) |
-| `csup` | yes | [Super Columnar](../formats/csup.md) |
+| `bsup` | yes | [Super Binary](../formats/bsup) |
+| `csup` | yes | [Super Columnar](../formats/csup) |
| `csv` | yes | [Comma-Separated Values (RFC 4180)](https://www.rfc-editor.org/rfc/rfc4180.html) |
| `json` | yes | [JSON (RFC 8259)](https://www.rfc-editor.org/rfc/rfc8259.html) |
-| `jsup` | yes | [Super JSON](../formats/jsup.md) |
-| `zjson` | yes | [Super JSON over JSON](../formats/zjson.md) |
+| `jsup` | yes | [Super JSON](../formats/jsup) |
+| `zjson` | yes | [Super JSON over JSON](../formats/zjson) |
| `line` | no | One string value per input line |
| `parquet` | yes | [Apache Parquet](https://github.com/apache/parquet-format) |
| `tsv` | yes | [Tab-Separated Values](https://en.wikipedia.org/wiki/Tab-separated_values) |
@@ -177,7 +177,7 @@ would produce this output in the default Super JSON format
#### JSON Auto-detection: Super vs. Plain
-Since [Super JSON](../formats/jsup.md) is a superset of plain JSON, `super` must be careful how it distinguishes the two cases when performing auto-inference.
+Since [Super JSON](../formats/jsup) is a superset of plain JSON, `super` must be careful how it distinguishes the two cases when performing auto-inference.
While you can always clarify your intent
via `-i jsup` or `-i json`, `super` attempts to "just do the right thing"
when you run it with Super JSON vs. plain JSON.
@@ -188,8 +188,8 @@ not desirable because (1) the Super JSON parser is not particularly performant a
JSON any number that appears without a decimal point as an integer type.
:::tip note
-The reason `super` is not particularly performant for Super JSON is that the [Super Binary](../formats/bsup.md) or
-[Super Columnar](../formats/csup.md) formats are semantically equivalent to Super JSON but much more efficient and
+The reason `super` is not particularly performant for Super JSON is that the [Super Binary](../formats/bsup) or
+[Super Columnar](../formats/csup) formats are semantically equivalent to Super JSON but much more efficient and
the design intent is that these efficient binary formats should be used in
use cases where performance matters. Super JSON is typically used only when
data needs to be human-readable in interactive settings or in automated tests.
@@ -210,12 +210,12 @@ typically omit quotes around field names.
| Option | Specification |
|-----------|------------------------------------------|
| `arrows` | [Arrow IPC Stream Format](https://arrow.apache.org/docs/format/Columnar.html#ipc-streaming-format) |
-| `bsup` | [Super Binary](../formats/bsup.md) |
-| `csup` | [Super Columnar](../formats/csup.md) |
+| `bsup` | [Super Binary](../formats/bsup) |
+| `csup` | [Super Columnar](../formats/csup) |
| `csv` | [Comma-Separated Values (RFC 4180)](https://www.rfc-editor.org/rfc/rfc4180.html) |
| `json` | [JSON (RFC 8259)](https://www.rfc-editor.org/rfc/rfc8259.html) |
-| `jsup` | [Super JSON](../formats/jsup.md) |
-| `zjson` | [Super JSON over JSON](../formats/zjson.md) |
+| `jsup` | [Super JSON](../formats/jsup) |
+| `zjson` | [Super JSON over JSON](../formats/zjson) |
| `lake` | [SuperDB Data Lake Metadata Output](#superdb-data-lake-metadata-output) |
| `parquet` | [Apache Parquet](https://github.com/apache/parquet-format) |
| `table` | (described [below](#simplified-text-outputs)) |
@@ -355,7 +355,7 @@ parquetio: encountered multiple types (consider 'fuse'): {x:int64} and {s:string
##### Fusing Schemas
-As suggested by the error above, the [`fuse` operator](../language/operators/fuse.md) can merge different record
+As suggested by the error above, the [`fuse` operator](../language/operators/fuse) can merge different record
types into a blended type, e.g., here we create the file and read it back:
```mdtest-command
echo '{x:1}{s:"hello"}' | super -o out.parquet -f parquet -c fuse -
@@ -404,8 +404,8 @@ input formats. They may be a good fit for use with other text-based shell
tools, but due to their limitations should be used with care.
In `text` output, minimal formatting is applied, e.g., strings are shown
-without quotes and brackets are dropped from [arrays](../formats/zed.md#22-array)
-and [sets](../formats/zed.md#23-set). [Records](../formats/zed.md#21-record)
+without quotes and brackets are dropped from [arrays](../formats/zed#22-array)
+and [sets](../formats/zed#23-set). [Records](../formats/zed#21-record)
are printed as tab-separated field values without their corresponding field
names. For example:
@@ -448,7 +448,7 @@ word style
hello greeting
```
-If this is undesirable, the [`fuse` operator](../language/operators/fuse.md)
+If this is undesirable, the [`fuse` operator](../language/operators/fuse)
may prove useful to unify the input stream under a single record type that can
be described with a single header line. Doing this to our last example, we find
@@ -466,12 +466,12 @@ hello - greeting
#### SuperDB Data Lake Metadata Output
The `lake` format is used to pretty-print lake metadata, such as in
-[`super db` sub-command](super-db.md) outputs. Because it's `super db`'s default output format,
+[`super db` sub-command](super-db) outputs. Because it's `super db`'s default output format,
it's rare to request it explicitly via `-f`. However, since it's possible for
-`super db` to [generate output in any supported format](super-db.md#super-db-commands),
+`super db` to [generate output in any supported format](super-db#super-db-commands),
the `lake` format is useful to reverse this.
-For example, imagine you'd executed a [meta-query](super-db.md#meta-queries) via
+For example, imagine you'd executed a [meta-query](super-db#meta-queries) via
`super db query -Z "from :pools"` and saved the output in this file `pools.jsup`.
```mdtest-input pools.jsup
@@ -509,13 +509,13 @@ If you are ever stumped about how the `super` compiler is parsing your query,
you can always run `super -C` to compile and display your query in canonical form
without running it.
This can be especially handy when you are learning the language and
-[its shortcuts](../language/pipeline-model.md#implied-operators).
+[its shortcuts](../language/pipeline-model#implied-operators).
For example, this query
```mdtest-command
super -C -c 'has(foo)'
```
-is an implied [`where` operator](../language/operators/where.md), which matches values
+is an implied [`where` operator](../language/operators/where), which matches values
that have a field `foo`, i.e.,
```mdtest-output
where has(foo)
@@ -524,7 +524,7 @@ while this query
```mdtest-command
super -C -c 'a:=x+1'
```
-is an implied [`put` operator](../language/operators/put.md), which creates a new field `a`
+is an implied [`put` operator](../language/operators/put), which creates a new field `a`
with the value `x+1`, i.e.,
```mdtest-output
put a:=x+1
@@ -538,10 +538,10 @@ as soon as they happen and cause the `super` process to exit.
On the other hand,
runtime errors resulting from the query itself
do not halt execution. Instead, these error conditions produce
-[first-class errors](../language/data-types.md#first-class-errors)
+[first-class errors](../language/data-types#first-class-errors)
in the data output stream interleaved with any valid results.
Such errors are easily queried with the
-[`is_error` function](../language/functions/is_error.md).
+[`is_error` function](../language/functions/is_error).
This approach provides a robust technique for debugging complex queries,
where errors can be wrapped in one another providing stack-trace-like debugging
@@ -571,15 +571,15 @@ error("divide by zero")
## Examples
-As you may have noticed, many examples of the [SuperSQL language](../language/_index.md)
+As you may have noticed, many examples of the [SuperSQL language](../language)
are illustrated using this pattern
```
echo | super -c -
```
-which is used throughout the [language documentation](../language/_index.md)
-and [operator reference](../language/operators/_index.md).
+which is used throughout the [language documentation](../language)
+and [operator reference](../language/operators).
-The language documentation and [tutorials directory](../tutorials/_index.md)
+The language documentation and [tutorials directory](../tutorials)
have many examples, but here are a few more simple `super` use cases.
_Hello, world_
@@ -591,7 +591,7 @@ produces this Super JSON output
"hello, world"
```
-_Some values of available [data types](../language/data-types.md)_
+_Some values of available [data types](../language/data-types)_
```mdtest-command
echo '1 1.5 [1,"foo"] |["apple","banana"]|' | super -z -
```
@@ -613,7 +613,7 @@ produces
<[(int64,string)]>
<|[string]|>
```
-_A simple [aggregation](../language/aggregates/_index.md)_
+_A simple [aggregation](../language/aggregates)_
```mdtest-command
echo '{key:"foo",val:1}{key:"bar",val:2}{key:"foo",val:3}' |
super -z -c 'sum(val) by key | sort key' -
@@ -623,7 +623,7 @@ produces
{key:"bar",sum:2}
{key:"foo",sum:4}
```
-_Read CSV input and [cast](../language/functions/cast.md) a to an integer from default float_
+_Read CSV input and [cast](../language/functions/cast) a to an integer from default float_
```mdtest-command
printf "a,b\n1,foo\n2,bar\n" | super -z -c 'a:=int64(a)' -
```
@@ -669,7 +669,7 @@ measurements among SuperDB,
We'll use the Parquet format to compare apples to apples
and also report results for the custom columnar database format of DuckDB,
the [new beta JSON type](https://clickhouse.com/blog/a-new-powerful-json-data-type-for-clickhouse) of ClickHouse,
-and the [Super Binary](../formats/bsup.md) format used by `super`.
+and the [Super Binary](../formats/bsup) format used by `super`.
The detailed steps shown [below](#appendix-2-running-the-tests) can be reproduced via
[automated scripts](https://github.com/brimdata/super/blob/main/scripts/super-cmd-perf).
@@ -725,7 +725,7 @@ clickhouse-client --query "
INSERT INTO gha SELECT * FROM file('gharchive_gz/*.json.gz', JSONAsObject);"
```
To create a super-structed file for the `super` command, there is no need to
-[`fuse`](../language/operators/fuse.md) the data into a single schema (though `super` can still work with the fused
+[`fuse`](../language/operators/fuse) the data into a single schema (though `super` can still work with the fused
schema in the Parquet file), and we simply ran this command to create a Super Binary
file:
```
@@ -781,7 +781,7 @@ FROM 'gha'
WHERE v.payload.pull_request.body LIKE '%in case you have any feedback 😊%'
```
SuperSQL supports `LIKE` and could run the plain SQL query, but it also has a
-similar function called [`grep`](../language/functions/grep.md) that can operate over specified fields or
+similar function called [`grep`](../language/functions/grep) that can operate over specified fields or
default to all the string fields in any value. The SuperSQL query that uses
`grep` is
```sql
@@ -949,7 +949,7 @@ Dynamic: In scope SELECT tupleElement(arrayJoin(v.payload.pull_request.assignees
SuperSQL's data model does not require these kinds of gymnastics as
everything does not have to be jammed into a table. Instead, we can use the
-`UNNEST` pipe operator combined with the [spread operator](../language/expressions.md#array-expressions) applied to the array of
+`UNNEST` pipe operator combined with the [spread operator](../language/expressions#array-expressions) applied to the array of
string fields to easily produce a stream of string values representing the
assignees. Then we simply aggregate the assignee stream:
```sql
@@ -1092,7 +1092,7 @@ WHERE v.payload.pull_request.body LIKE '%in case you have any feedback 😊%'
Benchmark 1: clickhouse-client --queries-file /mnt/tmpdir/tmp.oymd2K7311
2
Time (abs ≡): 0.904 s [User: 0.038 s, System: 0.030 s]
-
+
About to execute
================
clickhouse --queries-file /mnt/tmpdir/tmp.K3EjBntwdo
@@ -1107,7 +1107,7 @@ WHERE payload.pull_request.body LIKE '%in case you have any feedback 😊%'
Benchmark 1: clickhouse --queries-file /mnt/tmpdir/tmp.K3EjBntwdo
2
Time (abs ≡): 70.647 s [User: 70.320 s, System: 3.447 s]
-
+
About to execute
================
datafusion-cli --file /mnt/tmpdir/tmp.zSkYYYeSG6
@@ -1126,11 +1126,11 @@ DataFusion CLI v43.0.0
+---------+
| 2 |
+---------+
-1 row(s) fetched.
+1 row(s) fetched.
Elapsed 10.764 seconds.
Time (abs ≡): 10.990 s [User: 66.344 s, System: 10.974 s]
-
+
About to execute
================
duckdb /mnt/gha.db < /mnt/tmpdir/tmp.31z1ThfK6B
@@ -1150,7 +1150,7 @@ Benchmark 1: duckdb /mnt/gha.db < /mnt/tmpdir/tmp.31z1ThfK6B
│ 2 │
└──────────────┘
Time (abs ≡): 12.985 s [User: 78.328 s, System: 9.270 s]
-
+
About to execute
================
duckdb < /mnt/tmpdir/tmp.x2HfLY0RBU
@@ -1170,7 +1170,7 @@ Benchmark 1: duckdb < /mnt/tmpdir/tmp.x2HfLY0RBU
│ 2 │
└──────────────┘
Time (abs ≡): 13.356 s [User: 89.551 s, System: 6.785 s]
-
+
About to execute
================
super -z -I /mnt/tmpdir/tmp.KmM8c3l1gb
@@ -1208,7 +1208,7 @@ WHERE
Benchmark 1: clickhouse-client --queries-file /mnt/tmpdir/tmp.tgIZkIc6XA
3
Time (abs ≡): 13.244 s [User: 0.058 s, System: 0.022 s]
-
+
About to execute
================
clickhouse --queries-file /mnt/tmpdir/tmp.0ENj1f6lI8
@@ -1227,7 +1227,7 @@ WHERE
Benchmark 1: clickhouse --queries-file /mnt/tmpdir/tmp.0ENj1f6lI8
3
Time (abs ≡): 870.218 s [User: 950.089 s, System: 18.760 s]
-
+
About to execute
================
datafusion-cli --file /mnt/tmpdir/tmp.veTUjcdQto
@@ -1250,11 +1250,11 @@ DataFusion CLI v43.0.0
+---------+
| 3 |
+---------+
-1 row(s) fetched.
+1 row(s) fetched.
Elapsed 21.422 seconds.
Time (abs ≡): 21.661 s [User: 129.457 s, System: 19.646 s]
-
+
About to execute
================
duckdb /mnt/gha.db < /mnt/tmpdir/tmp.CcmsLBMCmv
@@ -1278,7 +1278,7 @@ Benchmark 1: duckdb /mnt/gha.db < /mnt/tmpdir/tmp.CcmsLBMCmv
│ 3 │
└──────────────┘
Time (abs ≡): 20.043 s [User: 137.850 s, System: 10.587 s]
-
+
About to execute
================
duckdb < /mnt/tmpdir/tmp.BI1AC3TnV2
@@ -1302,7 +1302,7 @@ Benchmark 1: duckdb < /mnt/tmpdir/tmp.BI1AC3TnV2
│ 3 │
└──────────────┘
Time (abs ≡): 21.352 s [User: 144.078 s, System: 9.044 s]
-
+
About to execute
================
super -z -I /mnt/tmpdir/tmp.v0WfEuBi8J
@@ -1336,7 +1336,7 @@ WHERE v.actor.login='johnbieren'
Benchmark 1: clickhouse-client --queries-file /mnt/tmpdir/tmp.CFT0wwiAbD
879
Time (abs ≡): 0.080 s [User: 0.025 s, System: 0.018 s]
-
+
About to execute
================
clickhouse --queries-file /mnt/tmpdir/tmp.XFTW0X911r
@@ -1351,7 +1351,7 @@ WHERE actor.login='johnbieren'
Benchmark 1: clickhouse --queries-file /mnt/tmpdir/tmp.XFTW0X911r
879
Time (abs ≡): 0.954 s [User: 0.809 s, System: 0.164 s]
-
+
About to execute
================
datafusion-cli --file /mnt/tmpdir/tmp.QLU5fBDx7L
@@ -1370,11 +1370,11 @@ DataFusion CLI v43.0.0
+---------+
| 879 |
+---------+
-1 row(s) fetched.
+1 row(s) fetched.
Elapsed 0.340 seconds.
Time (abs ≡): 0.388 s [User: 1.601 s, System: 0.417 s]
-
+
About to execute
================
duckdb /mnt/gha.db < /mnt/tmpdir/tmp.WVteXNRqfp
@@ -1394,7 +1394,7 @@ Benchmark 1: duckdb /mnt/gha.db < /mnt/tmpdir/tmp.WVteXNRqfp
│ 879 │
└──────────────┘
Time (abs ≡): 0.177 s [User: 1.011 s, System: 0.137 s]
-
+
About to execute
================
duckdb < /mnt/tmpdir/tmp.b5T64pDmwq
@@ -1414,7 +1414,7 @@ Benchmark 1: duckdb < /mnt/tmpdir/tmp.b5T64pDmwq
│ 879 │
└──────────────┘
Time (abs ≡): 0.416 s [User: 2.235 s, System: 0.187 s]
-
+
About to execute
================
super -z -I /mnt/tmpdir/tmp.s5e3Ueg2zU
@@ -1429,7 +1429,7 @@ WHERE actor.login='johnbieren'
Benchmark 1: super -z -I /mnt/tmpdir/tmp.s5e3Ueg2zU
{count:879(uint64)}
Time (abs ≡): 5.830 s [User: 17.284 s, System: 1.737 s]
-
+
About to execute
================
SUPER_VAM=1 super -z -I /mnt/tmpdir/tmp.2f1t2J9pWR
@@ -1472,7 +1472,7 @@ Benchmark 1: clickhouse-client --queries-file /mnt/tmpdir/tmp.hFAMHegng8
30 IssueCommentEvent
35 PullRequestEvent
Time (abs ≡): 0.132 s [User: 0.034 s, System: 0.018 s]
-
+
About to execute
================
clickhouse --queries-file /mnt/tmpdir/tmp.MiXEgFCu5o
@@ -1495,7 +1495,7 @@ Benchmark 1: clickhouse --queries-file /mnt/tmpdir/tmp.MiXEgFCu5o
3 ForkEvent
35 PullRequestEvent
Time (abs ≡): 0.864 s [User: 0.747 s, System: 0.180 s]
-
+
About to execute
================
datafusion-cli --file /mnt/tmpdir/tmp.uI0r2dLw8f
@@ -1522,11 +1522,11 @@ DataFusion CLI v43.0.0
| 9 | IssuesEvent |
| 29 | WatchEvent |
+---------+-------------------------------+
-8 row(s) fetched.
+8 row(s) fetched.
Elapsed 0.315 seconds.
Time (abs ≡): 0.358 s [User: 1.385 s, System: 0.404 s]
-
+
About to execute
================
duckdb /mnt/gha.db < /mnt/tmpdir/tmp.Nqj23A926J
@@ -1554,7 +1554,7 @@ Benchmark 1: duckdb /mnt/gha.db < /mnt/tmpdir/tmp.Nqj23A926J
│ 35 │ PullRequestEvent │
└──────────────┴───────────────────────────────┘
Time (abs ≡): 0.143 s [User: 0.722 s, System: 0.162 s]
-
+
About to execute
================
duckdb < /mnt/tmpdir/tmp.LepFhAA9Y3
@@ -1582,7 +1582,7 @@ Benchmark 1: duckdb < /mnt/tmpdir/tmp.LepFhAA9Y3
│ 29 │ WatchEvent │
└──────────────┴───────────────────────────────┘
Time (abs ≡): 0.318 s [User: 1.547 s, System: 0.159 s]
-
+
About to execute
================
super -z -I /mnt/tmpdir/tmp.oWK2c4UwIp
@@ -1605,7 +1605,7 @@ Benchmark 1: super -z -I /mnt/tmpdir/tmp.oWK2c4UwIp
{type:"PullRequestEvent",count:35(uint64)}
{type:"PushEvent",count:15(uint64)}
Time (abs ≡): 5.692 s [User: 15.531 s, System: 1.644 s]
-
+
About to execute
================
SUPER_VAM=1 super -z -I /mnt/tmpdir/tmp.S1AYE55Oyi
@@ -1661,7 +1661,7 @@ tmtmtmtm 356
AMatutat 260
danwinship 208
Time (abs ≡): 72.059 s [User: 142.588 s, System: 6.638 s]
-
+
About to execute
================
datafusion-cli --file /mnt/tmpdir/tmp.bWB9scRPum
@@ -1696,11 +1696,11 @@ DataFusion CLI v43.0.0
| AMatutat | 260 |
| danwinship | 208 |
+-----------------+-------+
-5 row(s) fetched.
+5 row(s) fetched.
Elapsed 24.234 seconds.
Time (abs ≡): 24.575 s [User: 163.931 s, System: 24.758 s]
-
+
About to execute
================
duckdb /mnt/gha.db < /mnt/tmpdir/tmp.3724dO4AgT
@@ -1734,7 +1734,7 @@ Benchmark 1: duckdb /mnt/gha.db < /mnt/tmpdir/tmp.3724dO4AgT
│ danwinship │ 208 │
└─────────────────┴───────┘
Time (abs ≡): 520.980 s [User: 4062.107 s, System: 15.406 s]
-
+
About to execute
================
duckdb < /mnt/tmpdir/tmp.WcA1AOl9UB
@@ -1768,7 +1768,7 @@ Benchmark 1: duckdb < /mnt/tmpdir/tmp.WcA1AOl9UB
│ danwinship │ 208 │
└─────────────────┴───────┘
Time (abs ≡): 503.567 s [User: 3747.792 s, System: 10.013 s]
-
+
About to execute
================
super -z -I /mnt/tmpdir/tmp.iTtaFeoj74
diff --git a/docs/formats/_index.md b/docs/formats/_index.md
index e7fa09c7bf..c7c999dea3 100644
--- a/docs/formats/_index.md
+++ b/docs/formats/_index.md
@@ -6,12 +6,12 @@ weight: 5
> **TL;DR** The super data model defines a new and easy way to manage, store,
> and process data utilizing an emerging concept called
[super-structured data](#2-a-super-structured-pattern).
-> The [data model specification](zed.md) defines the high-level model that is realized
+> The [data model specification](zed) defines the high-level model that is realized
> in a [family of interoperable serialization formats](#3-the-data-model-and-formats),
> providing a unified approach to row, columnar, and human-readable formats. Together these
> represent a superset of both the dataframe/table model of relational systems and the
> semi-structured model that is used ubiquitously in development as JSON and by NoSQL
-> data stores. The Super JSON spec has [a few examples](jsup.md#3-examples).
+> data stores. The Super JSON spec has [a few examples](jsup#3-examples).
## 1. Background
@@ -123,7 +123,7 @@ then such a collection of records looks precisely like a relational table.
Here, the record type
of such a collection corresponds to a well-defined schema consisting
of field names (i.e, column names) where each field has a specific type.
-[Named types](../language/data-types.md#named-types) are also available, so by simply naming a particular record type
+[Named types](../language/data-types#named-types) are also available, so by simply naming a particular record type
(i.e., a schema), a relational table can be projected from a pool of data
with a simple query for that named type.
@@ -224,7 +224,7 @@ object is just as performant as a traditional schema-based columnar format like
### 2.4 First-class Types
-With [first-class types](../language/data-types.md#first-class-types), any type can also be a value, which means that in
+With [first-class types](../language/data-types#first-class-types), any type can also be a value, which means that in
a properly designed query and analytics system based on the super data model, a type can appear
anywhere that a value can appear. In particular, types can be aggregation keys.
@@ -256,7 +256,7 @@ In SQL based systems, errors typically
result in cryptic messages or null values offering little insight as to the
actual cause of the error.
-By comparison, SuperDB includes [first-class errors](../language/data-types.md#first-class-errors). When combined with the super
+By comparison, SuperDB includes [first-class errors](../language/data-types#first-class-errors). When combined with the super
data model, error values may appear anywhere in the output and operators
can propagate or easily wrap errors so complicated analytics pipelines
can be debugged by observing the location of errors in the output results.
@@ -264,24 +264,24 @@ can be debugged by observing the location of errors in the output results.
## 3. The Data Model and Formats
The concept of super-structured data and first-class types and errors
-is solidified in the [data model specification](zed.md),
+is solidified in the [data model specification](zed),
which defines the model but not the serialization formats.
A set of companion documents define a family of tightly integrated
serialization formats that all adhere to the same super data model,
providing a unified approach to row, columnar, and human-readable formats:
-* [Super JSON](jsup.md) is a human-readable format for super-structured data. All JSON
+* [Super JSON](jsup) is a human-readable format for super-structured data. All JSON
documents are Super JSON values as the Super JSON format is a strict superset of the JSON syntax.
-* [Super Binary](bsup.md) is a row-based, binary representation somewhat like
+* [Super Binary](bsup) is a row-based, binary representation somewhat like
Avro but leveraging the super data model to represent a sequence of arbitrarily-typed
values.
-* [Super Columnar](csup.md) is columnar like Parquet or ORC but also
+* [Super Columnar](csup) is columnar like Parquet or ORC but also
embodies the super data model for heterogeneous and self-describing schemas.
-* [Super JSON over JSON](zjson.md) defines a format for encapsulating Super JSON
+* [Super JSON over JSON](zjson) defines a format for encapsulating Super JSON
inside plain JSON for easy decoding by JSON-based clients, e.g.,
the [JavaScript library used by SuperDB Desktop](https://github.com/brimdata/zui/tree/main/packages/zed-js)
-and the [SuperDB Python library](../libraries/python.md).
+and the [SuperDB Python library](../libraries/python).
Because all of the formats conform to the same super data model, conversions between
a human-readable form, a row-based binary form, and a row-based columnar form can
diff --git a/docs/formats/bsup.md b/docs/formats/bsup.md
index 333f245d24..5f68790385 100644
--- a/docs/formats/bsup.md
+++ b/docs/formats/bsup.md
@@ -7,7 +7,7 @@ heading: Super Binary Specification
## 1. Introduction
Super Binary is an efficient, sequence-oriented serialization format for any data
-conforming to the [super data model](zed.md).
+conforming to the [super data model](zed).
Super Binary is "row oriented" and
analogous to [Apache Avro](https://avro.apache.org) but does not
@@ -128,7 +128,7 @@ but is useful to an implementation to deterministically
size decompression buffers in advance of decoding.
Values for the `format` byte are defined in the
-[Super Binary compression format specification](./compression.md).
+[Super Binary compression format specification](./compression).
:::tip note
This arrangement of frames separating types and values allows
@@ -212,7 +212,7 @@ of the length of the string followed by that many bytes of UTF-8 encoded
string data.
:::tip note
-As defined by [Super JSON](jsup.md), a field name can be any valid UTF-8 string much like JSON
+As defined by [Super JSON](jsup), a field name can be any valid UTF-8 string much like JSON
objects can be indexed with arbitrary string keys (via index operator)
even if the field names available to the dot operator are restricted
by language syntax for identifiers.
@@ -309,7 +309,7 @@ existing type ID ``. `` is encoded as a `uvarint` and `
is encoded as a `uvarint` representing the length of the name in bytes,
followed by that many bytes of UTF-8 string.
-As indicated in the [data model](zed.md),
+As indicated in the [data model](zed),
it is an error to define a type name that has the same name as a primitive type,
and it is permissible to redefine a previously defined type name with a
type that differs from the previous definition.
diff --git a/docs/formats/compression.md b/docs/formats/compression.md
index 4b3ed3e40a..b9cecabf39 100644
--- a/docs/formats/compression.md
+++ b/docs/formats/compression.md
@@ -5,7 +5,7 @@ heading: ZNG Compression Types
---
This document specifies values for the `` byte of a
-[Super Binary compressed value message block](bsup.md#2-the-super-binary-format)
+[Super Binary compressed value message block](bsup#2-the-super-binary-format)
and the corresponding algorithms for the `` byte sequence.
As new compression algorithms are specified, they will be documented
diff --git a/docs/formats/csup.md b/docs/formats/csup.md
index 133a6e7322..7c3bd28ed2 100644
--- a/docs/formats/csup.md
+++ b/docs/formats/csup.md
@@ -5,9 +5,9 @@ heading: Super Columnar Specification
---
Super Columnar is a file format based on
-the [super data model](zed.md) where data is stacked to form columns.
+the [super data model](zed) where data is stacked to form columns.
Its purpose is to provide for efficient analytics and search over
-bounded-length sequences of [super-structured data](./_index.md#2-a-super-structured-pattern) that is stored in columnar form.
+bounded-length sequences of [super-structured data](.#2-a-super-structured-pattern) that is stored in columnar form.
Like [Parquet](https://github.com/apache/parquet-format),
Super Columnar provides an efficient representation for semi-structured data,
@@ -76,9 +76,9 @@ merging them together (or even leaving the Super Columnar entity as separate fil
The data section contains raw data values organized into _segments_,
where a segment is a seek offset and byte length relative to the
data section. Each segment contains a sequence of
-[primitive-type values](zed.md#1-primitive-types),
+[primitive-type values](zed#1-primitive-types),
encoded as counted-length byte sequences where the counted-length is
-variable-length encoded as in the [Super Binary specification](bsup.md).
+variable-length encoded as in the [Super Binary specification](bsup).
Segments may be compressed.
There is no information in the data section for how segments relate
@@ -388,7 +388,7 @@ using the same tag within the union value.
### Hello, world
-Start with this [Super JSON](jsup.md) file `hello.jsup`:
+Start with this [Super JSON](jsup) file `hello.jsup`:
```
{a:"hello",b:"world"}
{a:"goodnight",b:"gracie"}
diff --git a/docs/formats/jsup.md b/docs/formats/jsup.md
index 44d24e8257..f1f1816dfc 100644
--- a/docs/formats/jsup.md
+++ b/docs/formats/jsup.md
@@ -7,7 +7,7 @@ heading: Super JSON Specification
## 1. Introduction
Super JSON is the human-readable, text-based serialization format of
-the [super data model](zed.md).
+the [super data model](zed).
Super JSON builds upon the elegant simplicity of JSON with "type decorators".
Where the type of a value is not implied by its syntax, a parenthesized
@@ -90,7 +90,7 @@ same name, from the case that an existing named type is merely decorating the va
### 2.3 Primitive Values
The type names and format for
-[primitive values](zed.md#1-primitive-types) is as follows:
+[primitive values](zed#1-primitive-types) is as follows:
| Type | Value Format |
|------------|---------------------------------------------------------------|
@@ -225,13 +225,13 @@ record types as well as enum symbols.
Complex values are built from primitive values and/or other complex values
and conform to the super data model's complex types:
-[record](zed.md#21-record),
-[array](zed.md#22-array),
-[set](zed.md#23-set),
-[map](zed.md#24-map),
-[union](zed.md#25-union),
-[enum](zed.md#26-enum), and
-[error](zed.md#27-error).
+[record](zed#21-record),
+[array](zed#22-array),
+[set](zed#23-set),
+[map](zed#24-map),
+[union](zed#25-union),
+[enum](zed#26-enum), and
+[error](zed#27-error).
Complex values have an implied type when their constituent values all have
implied types.
diff --git a/docs/formats/zjson.md b/docs/formats/zjson.md
index f4e8d506fa..3e9ebd0cb1 100644
--- a/docs/formats/zjson.md
+++ b/docs/formats/zjson.md
@@ -6,14 +6,14 @@ heading: ZJSON Specification
## 1. Introduction
-The [super data model](zed.md)
+The [super data model](zed)
is based on richly typed records with a deterministic field order,
-as is implemented by the [Super JSON](jsup.md), [Super Binary](bsup.md), and [Super Columnar](csup.md) formats.
+as is implemented by the [Super JSON](jsup), [Super Binary](bsup), and [Super Columnar](csup) formats.
Given the ubiquity of JSON, it is desirable to also be able to serialize
super data into the JSON format. However, encoding super data values
directly as JSON values would not work without loss of information.
-For example, consider this [Super JSON](jsup.md) data:
+For example, consider this [Super JSON](jsup) data:
```
{
ts: 2018-03-24T17:15:21.926018012Z,
@@ -60,7 +60,7 @@ Also, it is at the whim of a JSON implementation whether
or not the order of object keys is preserved.
While JSON is well suited for data exchange of generic information, it is not
-sufficient for the [super-structured data model](./_index.md#2-a-super-structured-pattern).
+sufficient for the [super-structured data model](.#2-a-super-structured-pattern).
That said, JSON can be used as an encoding format for super data with another layer
of encoding on top of a JSON-based protocol. This allows clients like web apps or
Electron apps to receive and understand Super JSON and, with the help of client
@@ -92,7 +92,7 @@ The type and value fields are encoded as defined below.
### 2.1 Type Encoding
-The type encoding for a primitive type is simply its [type name](zed.md#1-primitive-types)
+The type encoding for a primitive type is simply its [type name](zed#1-primitive-types)
e.g., "int32" or "string".
Complex types are encoded with small-integer identifiers.
@@ -256,7 +256,7 @@ as described recursively herein,
* a type value is encoded [as above](#21-type-encoding),
* each primitive that is not a type value
is encoded as a string conforming to its Super JSON representation, as described in the
-[corresponding section of the Super JSON specification](jsup.md#23-primitive-values).
+[corresponding section of the Super JSON specification](jsup#23-primitive-values).
For example, a record with three fields --- a string, an array of integers,
and an array of union of string, and float64 --- might have a value that looks like this:
@@ -268,7 +268,7 @@ and an array of union of string, and float64 --- might have a value that looks l
A ZJSON file is composed of ZJSON objects formatted as
[newline delimited JSON (NDJSON)](https://en.wikipedia.org/wiki/JSON_streaming#NDJSON).
-e.g., the [super](../commands/super.md) CLI command
+e.g., the [super](../commands/super) CLI command
writes its ZJSON output as lines of NDJSON.
## 4. Example
diff --git a/docs/install.md b/docs/install.md
index fe1e8db596..afed1efd0e 100644
--- a/docs/install.md
+++ b/docs/install.md
@@ -9,7 +9,7 @@ Several options for installing `super` are available:
* [Build from source](#building-from-source).
To install the SuperDB Python client, see the
-[Python library documentation](libraries/python.md).
+[Python library documentation](libraries/python).
## Homebrew
diff --git a/docs/integrations/fluentd.md b/docs/integrations/fluentd.md
index 9688930bfe..9a916d7bba 100644
--- a/docs/integrations/fluentd.md
+++ b/docs/integrations/fluentd.md
@@ -4,7 +4,7 @@ title: Fluentd
---
The [Fluentd](https://www.fluentd.org/) open source data collector can be used
-to push log data to a [SuperDB data lake](../commands/super-db.md) in a continuous manner.
+to push log data to a [SuperDB data lake](../commands/super-db) in a continuous manner.
This allows for querying near-"live" event data to enable use cases such as
dashboarding and alerting in addition to creating a long-running historical
record for archiving and analytics.
@@ -12,7 +12,7 @@ record for archiving and analytics.
This guide walks through two simple configurations of Fluentd with a Zed lake
that can be used as reference for starting your own production configuration.
As it's a data source important to many in the Zed community, log data from
-[Zeek](./zeek/_index.md) is used in this guide. The approach shown can be
+[Zeek](./zeek) is used in this guide. The approach shown can be
easily adapted to any log data source.
## Software
@@ -59,7 +59,7 @@ After making these changes, Zeek was started by running
A binary [release package](https://github.com/brimdata/super/releases) of Zed
executables compatible with our instance was downloaded and unpacked to a
-directory in our `$PATH`, then the [lake service](../commands/super-db.md#serve)
+directory in our `$PATH`, then the [lake service](../commands/super-db#serve)
was started with a specified storage path.
```
@@ -77,7 +77,7 @@ zed create zeek
```
The default settings when running `zed create` set the
-[pool key](../commands/super-db.md#pool-key) to the `ts`
+[pool key](../commands/super-db#pool-key) to the `ts`
field and sort the stored data in descending order by that key. This
configuration is ideal for Zeek log data.
@@ -86,7 +86,7 @@ The [Zui](https://zui.brimdata.io/) desktop application automatically starts a
Zed lake service when it launches. Therefore if you are using Zui you can
skip the first set of commands shown above. The pool can be created from Zui
by clicking **+**, selecting **New Pool**, then entering `ts` for the
-[pool key](../commands/super-db.md#pool-key).
+[pool key](../commands/super-db#pool-key).
:::
### Fluentd
@@ -105,7 +105,7 @@ sudo gem install fluentd --no-doc
The following simple `fluentd.conf` was used to watch the streamed Zeek logs
for newly added lines and load each set of them to the pool in the Zed lake as
-a separate [commit](../commands/super-db.md#commit-objects).
+a separate [commit](../commands/super-db#commit-objects).
```