LlamaIndex 發佈 Document Parsing Protocol（DPP）0.1 工作草案

Parsing a page into structured text or Markdown means making a run of judgment calls:

• Is this block of aligned text a table, or just layout?
• Does a header that spans two rows stay two rows, or get flattened into one?
• Is a table that continues onto the next page one table or two?
• Does a flowchart get described, converted to Mermaid, or skipped?

Different parsers make different calls. So two parsers can capture every word on a page and still hand you outputs that mean different things. An agent works only from what the parser hands it, so if the parser groups a header wrong, the agent’s answer is wrong too. But there’s no shared definition of what a correctly parsed page looks like.

The Document Parsing Protocol (DPP) is our proposed definition: an answer key for document parsing, with the reasoning behind each hard call. Today we're publishing working draft 0.1. Its 140 rules cover text, tables, forms, charts, diagrams, and more, and each comes with example pages and the output it expects. It grew out of the rules our annotators followed when labeling pages for ParseBench, our parsing benchmark.

The same table comes out three different ways

Here’s a sales page with two header rows. The years run across the top, each spanning its own columns, and the quarters sit underneath. 2023 also has a full-year column.

Three parsers might turn that table into Markdown like this, shown down to the first data row.

Now ask an agent for Q2 2024 systemwide same-shop sales. With A, the quarters sit in a data row and the column holding 4.1 % has a blank header. The agent has to infer the header grouping from position, and a Markdown table can’t say whether that blank header belongs to the 2024 to its left or is just empty. With C, "Q2" matches two columns, 3.8 % and 4.1 %. B makes the year and quarter explicit in the column label.

DPP marks B as non-conforming, even though it answers the question. The page never printed "2024 Q2". Parser B invented that label, and another parser might write "Q2 2024" or "2024-Q2". DPP's rule for multi-row headers says flattening "destroys the grouping that the page printed." Code that reads these headers now has to account for each parser's label format.

DPP keeps every printed tier as its own header row, with exact column spans. Its output is Markdown, but Markdown pipe tables can't express a span. Where Markdown has no syntax for something, DPP names the HTML element to use, so every table is an HTML <table>. Here’s DPP’s output for the same table, down to the Ticket row:

<table>
  <tr> <th></th> <th colspan="5">2023</th> <th colspan="3">2024</th> </tr>
  <tr>
    <th><em>Fiscal year ending December,</em></th>
    <th>Q1</th> <th>Q2</th> <th>Q3</th> <th>Q4</th> <th>FY</th>
    <th>Q1</th> <th>Q2</th> <th>Q3</th>
  </tr>
  <tr>
    <td data-level="0"><strong>Systemwide Same Shop Sales</strong></td>
    <td><strong>(2.0)%</strong></td> <td><strong>3.8 %</strong></td>
    <td><strong>4.0 %</strong></td> <td><strong>5.0 %</strong></td>
    <td><strong>2.8 %</strong></td> <td><strong>10.0 %</strong></td>
    <td><strong>4.1 %</strong></td> <td><strong>2.7 %</strong></td>
  </tr>
  <tr>
    <td data-level="1">Ticket</td>
    <td>6.3 %</td> <td>6.4 %</td> <td>9.5 %</td> <td>5.4 %</td>
    <td>7.2 %</td> <td>8.8 %</td> <td>6.1 %</td> <td>1.9 %</td>
  </tr>
<!-- … -->
</table>

The 4.1 % now sits under Q2 inside the 2024 span, so the agent’s answer comes from structure the page printed. The same output keeps the printed spacing in "(2.0)%" and "3.8 %", keeps the bold row bold, and uses data-level to mark Ticket as a sub-row of the bold row above it.

A shared answer key

Anyone who builds a benchmark, labels data, or reviews parser output has to decide what the correct output for a page is. The example above shows that this includes decisions about structure, even when every word and number is correct. Today each team makes those decisions privately, so two evaluations can accept different outputs for the same page. We’re publishing DPP so teams can annotate data and evaluate parser outputs against the same written expectations, and argue with them in the open.

DPP also spells out which differences are acceptable. Wrapping table rows in <thead> and <tbody> , for example, preserves the same information as leaving those wrappers out. Both forms conform, as long as a document uses one form throughout. A review should accept either.

The decisions go beyond tables

On a form, an empty field tells you that a question was asked and left unanswered. Dropping it makes that indistinguishable from a field the parser missed. We represent it as [blank] . Checked and unchecked boxes stay in the output as [x] and [ ] , so the options someone left unselected survive too.

For charts, we chose data tables: one row per category and one column per series. A chart with six years and four series holds 24 values, and the output should retain each one that can be read and located. Printed values are copied exactly. Where a value is only shown by a bar or point, we read it against that series’ own axis and limit the precision to what the chart supports.

For diagrams, the connections are part of the content. We use a diagram language such as Mermaid when it can preserve the labels, branches and arrow directions. A floor plan needs a representation that also preserves its geometry. When no suitable language can capture the figure faithfully, we use a structured description that keeps its visible text and relationships.

What counts is what a reader sees on the page. Text that sits in the PDF file but never shows on the page, like white-on-white text, stays out of the output. And visible but unreadable text is marked [illegible]. When you request bounding boxes, each element’s position is recorded alongside the Markdown, so any value can be checked against the page.

Try DPP on a page

DPP is live at parseprotocol.com, with each source page shown beside its expected output. The fastest way to see what it does is to run it on a page. Pick Claude or ChatGPT on the site. For Claude, download the skill and upload it under Customize → Skills (skills need code execution). For ChatGPT, add the reference file to a chat. Then attach a page image and paste the prompt from the site.

No page handy? Use the Apple sample page from the site. Check that the 6,485 printed in two cells survives in both, and that (565) keeps its parentheses. Then open the walkthrough of that page, which explains the eight parsing decisions on it.

DPP 0.1 is a working draft, and we want your input. If a rule breaks on one of your documents, or two rules point to different answers, show us. Open an issue or a pull request on GitHub with the page and the output you’d expect, and we’ll work through it with you.