nodekindby Elk Solutions

For authors who know the content and don't know XML

Any XML schema.
One editor.

nodekind reads your schema and offers exactly what is allowed here, and nothing else. Nothing to configure per element. No XML on screen. Switch documents on the right and watch what changes.

Try it with your own schema See pricing

In the browser, or inside your own application. One price per organisation, never per seat. DITA, DocBook, JATS, TEI or your own XSD. Apache-2.0 core.

Why a schema is not enough, and still everything

An XSD says what is allowed: which elements, in which order, how often. It does not say what anything is called for the person who works with it. One 123-element schema we use daily carries seven lines of documentation in total.

nodekind keeps two things apart. Behaviour comes from the content model: what fits here, what does not, and why. Words come from a dictionary per vocabulary. Where a word is missing you see the schema name, never something invented.

The roles, what counts as a paragraph, a heading, a number, something you can move, the editor derives from the shape of the schema. That is why the same core edits four standards without a line of code per element, and why a new schema version breaks nothing.

STOP 1.3.0 and 1.4.1
94%
OEP, an XSD converted from a DTD
92%
FHIR narrative
100%

Of the roles, derived from the schema. The rest is named by hand and stays visible on screen. Measure your own XSD in your browser.

Three things to do in the demo

See what the schema knows, and what it does not

If you compare versions: one move is one change

Many schemas give identity to structural elements only. The paragraph, where the text lives, has none. Move it and a comparison of two versions sees a deletion plus an insertion.

nodekind assigns every node an identity when it is created and carries it along, in its own namespace next to the attributes of your standard. The same move then counts as one change instead of four. That saves work in every diff, every review and every publication.

1⁄4changes a comparison sees: with identity, and without. Replay it in the demo; ⌘D opens the comparison view.

Who changed what, and when

Switch it on and every change carries the author's name and the time: moving, inserting, splitting, typing, renumbering. The way Word tracks it, but in the XML itself and on the paragraph.

<p nk:wId="nk-31" nk:auteur="N. de Vries" nk:tijdstip="2026-09-07T14:02:00Z">
  The distance is not …
</p>

In nodekind's own namespace, so outside your standard. Your pipeline does not see it; your editorial team does: in the margin, and behind every row of the comparison view. The name comes from your application; nodekind has no user accounts.

Off by default. Not there yet: accept or reject per change. We build that as soon as an editorial team asks for it.

For the person who integrates it

One message in, one message out. That is the whole integration.

const editor = document.getElementById('editor');
let seq = 0;

function send(kind, extra = {}) {
  const request = { nodekind: 1, id: ++seq, soort: kind, ...extra };
  editor.contentWindow.postMessage(request, location.origin);
}

window.addEventListener('message', (e) => {
  if (e.source !== editor.contentWindow) return;
  const { soort, stand, xml } = e.data;
  if (soort === 'gereed') {
    send('instellen', { instellingen:
      { taal: 'en', auteur: user.name, auteurspoor: true } });
    send('schemaversie', { versie: schema.id });
    send('laad', { xml: document.xml });
  }
  if (soort === 'gewijzigd') showSave(stand);
  if (soort === 'xml')       store(xml);
});
Your application asks
laad · haalXml · valideer · schemaversie · stand · instellen · structuurBij · ganaar · opmerkingen
The editor reports
gereed · xml · gewijzigd · bevindingen · stand · volg · selectie · opmerking · fout
Your application sets
woorden · toonIdentiteit · toonNietAangeboden · auteur · auteurspoor · taal
Same messages in
an iframe (window.parent) and a WebView2 control (window.chrome.webview)
A new schema
XSD files in a folder, one line in vocabulaires.json, optionally a dictionary. No build.
Runtime dependencies
@xmldom/xmldom, xpath. Nothing else. Apache-2.0.
We embed it ourselvesin three of our own products: two editorial consoles for Dutch legislation and one for electronic package leaflets. What works there works for you.
Your storage stays your storagenodekind is not a CMS. It receives XML, returns XML, and leaves versions, permissions and workflow to your system.
Your standard stays your standardwhat nodekind records for itself lives in its own namespace. Your schema stays valid; your pipeline stays in charge.

Pricing

The core is open. You pay per organisation, never per seat.

Free

€ 0self-hosted, Apache-2.0
  • the full editor, on your own server
  • all built-in schemas and dictionaries
  • iframe and WebView2 integration
  • community support
Get the source

Team

€ 99per month, hosted by us
  • unlimited authors
  • upload your own XSD
  • email support
  • card, cancel monthly
Start with Team

Embed

€ 499per month, inside your own application or on your own server
  • we finish the profile and dictionary for your schema, and keep it working across schema versions
  • business rules (Schematron) configured
  • response within one business day
  • 8 hours of help per month
  • invoice, yearly
Talk about Embed

Migration

€ 1,500one-off, from XMLmind
  • DITA or DocBook
  • your files measured: what the editor derives, what is missing
  • your schema, dictionary and rules set up
  • done before 3 April 2027
Plan the migration

Oxygen Web Author: about € 670 / month for 5 concurrent users. Fonto, Xeditor: quote only. XMLmind ends all products on 3 April 2027.

No seats. nodekind has no user accounts; your application says who the author is. The price does not grow with the number of authors.

Rule of thumb. Your own schema or your own application: Embed. A standard schema in our interface: Team.

What stops when you stop paying

Team: your account goes off.

Embed: your signed profile pack (dictionary, business rules) expires; 30 days of grace with a notice in the margin. The open core keeps working, with schema names only.

No phone-home, no licence check in the core.

Contact

One email, and you know whether it works on your schema.

Attach an XSD and a document. We measure what the editor derives and send you the numbers.

Email Siebe Jongebloed Elk Solutions, the company behind nodekind