# bitmark and XML

bitmark does not compete with XML. Publishers and standards bodies produce in
XML, and that stays; bitmark carries the same content to apps, AI and agents,
and the converter brings it over with its IDs intact.

## Does bitmark replace XML?

No. Editing, typesetting and archiving run on XML formats such as JATS, NISO
STS, DITA or DocBook, and the tools around them work well. bitmark represents
the same content once more, as bits, for everything that comes after
production.

## What is each one for?

| | XML | bitmark |
| --- | --- | --- |
| Main job | Producing, typesetting and archiving documents | Delivering knowledge to apps, retrieval systems and agents |
| Unit | The document, a tree of elements | The bit: a typed, addressable piece |
| Written by | Editorial systems | People and systems alike; the markup is readable |
| What each piece carries | What the schema allows | Its type, its ID, the customer's ID and its place in the source |
| Delivery | Whole files | JSONL, one bit per line |

## How do they stay in step?

The parser imports NISO STS XML and keeps the IDs, anchors and links of the
original on the customer side of each bit. A new edition is matched bit by
bit through those IDs; see [The Rosetta Map](https://docs.bitmark-association.org/concepts/rosetta-map.md).
Writing a complete NISO STS document back from the bits is planned.

## Why not cut chunks straight from the XML?

Chunks cut from an XML tree either lose their context or need custom code for
every schema and every publisher. A bit is self-contained: it carries its
type, its IDs and its place in the source, in the same shape whatever the
source format was.

## And linked data, such as JSON-LD or RDF?

Linked data is good at describing things and how they relate: a standard,
its terms, its editions. bitmark carries the content itself. The two meet in
[the bit passport](https://docs.bitmark-association.org/concepts/bit-passport.md), the delivery header proposed as
JSON-LD.