# DocLang is a markup format that keeps document geometry for language models

> DocLang is an Apache licensed specification and reference toolkit for an AI-native markup format that carries structure, semantics, layout and geometry for documents and images, with a CLI that validates and packs .dclg files against XSD and Schematron rules. It suits a team building document pipelines for LLMs and VLMs, and its value depends on other tools adopting the same format.

**doclang-project/doclang** — DocLang spec and reference toolkit

- Repository: https://github.com/doclang-project/doclang
- Website: https://doclang.ai
- Stars: 588 · Forks: 56
- Language: Python
- License: Apache-2.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/doclang-project-doclang

## A format proposal with a reference implementation attached

DocLang is described as the AI-native markup format for unstructured content, including documents, images and more. The claim is that it maps cleanly to LLM tokens while preserving structure, semantics, layout and geometry in a single, unambiguous representation.

The repository is the home of the normative specification and the reference toolkit. The framing in the README is worth quoting in spirit: if you build with LLMs and VLMs on real-world content, this is where the standard lives.

That is a standards project, not a library, and the two are separated in the tree. There is a spec.md at the root, an exports/ directory for exports to different formats, a reference/ directory, a doclang/ directory for the toolkit package, an examples/ directory, tests/, utils/ and resources/.

The specification is available as spec.md, and the project states one rule about authority: in case of discrepancies, the authoritative version of the specification is the original Markdown document. The exports are therefore derived artefacts, and a divergence between an export and the Markdown means the Markdown wins.

There is also a MOTIVATION.md for background, which is where a reader should go to understand why the format exists before reading the specification itself.

## Install, validate, pack: three commands to learn the format

The toolkit is a Python package on PyPI, and the commands in the README are the basic scenarios.

```bash
pip install "doclang[schematron-saxon]"
```

Then you validate a document.

```bash
doclang validate -n my_document.dclg
```

And you package one.

```bash
doclang pack my_document.dclg
```

The .dclg extension is the file format, and the -n flag on validate is worth noting because the command line is otherwise sparse.

The install line pulls the schematron-saxon extra, which is not incidental. The project metadata marks schematron-saxon as an optional dependency with saxonche at 12.9.0 or newer, while the core install depends only on lxml and typer. The README notes that advanced installation and usage options, including a minimal install, platform notes, custom Schematron backends and the Python API, are described in the toolkit README inside the doclang/ directory.

So the base tool is deliberately small. lxml does the XML work, typer provides the command line, and the heavyweight Saxon engine is opt-in for the validation rules that need it.

## XSD and Schematron: two kinds of rule in one schema set

The package data configuration is where the validation model shows.

```toml
[tool.setuptools.package-data]
doclang = ["*.xsd", "*.sch", "schemas/*/*.xsd", "schemas/*/*.sch"]
```

Both file types are shipped inside the package: .xsd for XML Schema definitions and .sch for Schematron rules, at the top level and in per-schema directories. The pyproject keywords list them alongside xml, validation, xsd, schematron, documents and llm.

The division of labour is the standard one. XSD handles structure, what elements may appear and in what order with what types. Schematron handles the constraints XSD cannot express, the cross-document and contextual rules that a validator expresses as assertions against a pattern.

And here is where the Saxon extra earns its name. Schematron rules need an engine that can evaluate XPath, and the project ships Saxon as the backend, with the toolkit README documenting custom Schematron backends for anyone who needs a different one. If you install without the extra, you get a toolkit that can still validate against the XSD schemas and cannot run the Schematron layer.

The choice of a real XPath engine rather than a simplified one is a decision about fidelity. Schematron written for a limited engine and Schematron written for a full one are not the same language, and a project that wants the specification to be implementable by others chose the stricter target.

## The examples directory shows the hard cases

The example directories are named for the situations that make document structure hard, and reading the list is the fastest way to understand what the format is for.

There are examples/abbyy/, examples/archive-demo/, examples/cross_column/, examples/cross_page/, examples/form/, examples/refs/ and examples/split_tables/.

Each name points at a specific structural problem. cross_column and cross_page are the two that a document parser most often gets wrong: a table that continues across a column break, or a page whose content flows around an image. split_tables is about a table whose cells need to be treated as separate units. refs is about references and citations, and form is about form fields, which have values rather than just text.

The archive-demo example suggests the format is also aimed at archival and preservation workflows, where you have to keep the evidence of a document's structure and not just its text.

For an engineer evaluating the format, these directories are the specification in miniature, because they show the format doing the thing it exists to do rather than describing it. A document that has been flattened to a stream of tokens cannot represent that a heading belongs to a section that continues on the next page, and a document that keeps geometry can.

The examples are also the reason the format's value is not yet obvious. The other half of the argument is that a consumer of that structure, a model or a renderer, has to understand the same conventions, and that only happens if the format gets adopted.

## A project with institutional backing and IBM contributors

The acknowledgements table is unusual for a format specification and tells you something about who is behind this.

Nine contributors are listed with IBM: Peter Staar, Panos Vagenas, Maksym Lysak, Nikolaos Livathinos, Christoph Auer, Michele Dolfi, Said Gürbüz, Santosh Borse and Yousaf Shah. Then three from ABBYY, Marlene Wolfgruber, Maxime Vermeir and Morgan Logue, then two from RedHat, Jehlum Vitasta Pandit and Ali Maredia, then Micaela Kaplan from HumanSignal, Ryan Chesler from NVIDIA and Riccardo Maggioni from Forgis.

ABBYY is a document AI company and IBM does a lot of document processing research, so the contributor list is a fair proxy for who is likely to implement this format. That is a meaningful signal for a specification whose value depends on adoption.

The project is developed in the open and supported by the LF AI and Data Foundation, and the README links both the foundation project page and the doclang-project organisation on GitHub.

The licence is Apache 2.0, with a LICENSE file and a license-files entry in the project metadata. The homepage is doclang.ai.

The release cadence is steady: v0.8.0 on 2026-10-15, v0.7.3 on 2026-07-15 and v0.7.2 on 2026-07-03, and the last push was on 2026-10-15. The version sits at 0.x, which is the honest signal that the format is still changing.

## What a specification project does not give you

It is worth being clear about what this repository is not, because a spec plus a reference toolkit can be mistaken for a product.

There is no model here. Nothing in the repository trains, hosts or serves a language model, and the toolkit does not call an LLM. The README's audience is people who build with LLMs and VLMs, and DocLang is the interchange format those systems would exchange, not the systems themselves.

There is also no guarantee of adoption. The README asks you to cite the specification if you use DocLang in academic or technical work, and provides a BibTeX entry, which is what a project does when it wants credit rather than users. A format that only one implementation reads has no value, and the repository offers no evidence in its README about who else has implemented it. The exports/ directory tells you what the reference toolkit can produce, not what other tools can consume.

Then there is the 0.x version. The specification is described as normative, but the version number says the document itself is expected to change, and the Changelog link in the project metadata points at a CHANGELOG.md in the repository root, so the history is at least tracked.

For an adopter, the honest framing is that you are betting on a format, and the value of the bet is proportional to how many other tools read it. The reference toolkit, the XSD and Schematron schemas, and the examples are what you can rely on today.

## Citing the format, and working on the toolkit

Two housekeeping parts of the project are documented, and the citation is the more interesting one.

If you use DocLang in academic or technical work, the README asks you to cite the specification, and gives the entry.

```bibtex
@misc{doclang_2026,
  title        = {DocLang: Universal AI Document Format},
  author       = {{DocLang Project}},
  year         = {2026},
  version      = {main},
  howpublished = {\url{https://github.com/doclang-project/doclang}},
}
```

Note the version field is main, not a release number, which is consistent with a specification that is expected to move.

For contributors, the README points at CONTRIBUTING.md for setup, tests, reference generation and releases, and the CHANGELOG.md at the root is the changelog. The repository also carries a .pre-commit-config.yaml, and the badges show Ruff for linting, mypy for type checking, pre-commit enabled, and a uv badge, with a uv.lock in the tree. The project metadata lists the CI dependency group with pre-commit, mypy, ruff, pytest, python-docx and saxonche, and a dev group that adds pydantic, pyyaml and openpyxl, the last two of which are what you would need to read or write office documents yourself.

The build backend is setuptools with the version held in pyproject.toml, and the console script is doclang = doclang.cli:app, with typer providing the command line.

## Conclusion

DocLang fits a team that already feeds real documents and images into language models and has hit the limits of handing a model a PDF or a pile of OCR text, because the format's whole purpose is to keep layout and geometry in the representation rather than flattening them. It does not fit a project that just needs text extraction, and it does not fit a team unwilling to depend on a format that only a small ecosystem currently implements. Before adopting it, read spec.md rather than the README, since the documentation states the authoritative version of the specification is the original Markdown document, check the exports/ directory to see which output formats already exist, and decide up front whether the Saxon extra is acceptable, because Schematron validation is not available without it.

## FAQ

### How do I install the DocLang toolkit and validate a document?

Install with pip install "doclang[schematron-saxon]" and then run doclang validate -n my_document.dclg. The package is on PyPI and requires Python 3.10 or newer.

### What is the authoritative version of the DocLang specification?

The original Markdown document, spec.md in the repository. The documentation states that in case of discrepancies the authoritative version is the original Markdown, and that the files in the exports directory are derived from it.

### Why does the DocLang install need the schematron-saxon extra?

Schematron rules need an XPath engine, and the project ships Saxon as the backend, with saxonche as an optional dependency. The core install depends only on lxml and typer, and the toolkit README documents custom Schematron backends for anyone needing a different engine.

### Is DocLang a model or a document processing service?

No. This repository is the normative specification and a reference toolkit with validate and pack commands, plus XSD and Schematron schemas and examples. Nothing in it trains, hosts or serves a language model.

## Sources

- [doclang-project/doclang on GitHub](https://github.com/doclang-project/doclang)
- [License: Apache-2.0](https://github.com/doclang-project/doclang/blob/main/LICENSE)
- [Project website](https://doclang.ai)
- [README](https://github.com/doclang-project/doclang/blob/main/README.md)
- [Releases](https://github.com/doclang-project/doclang/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/doclang-project-doclang