Found while reviewing ICIJ/datashare#2299, which makes Java a structure producer.
The two sides do not agree on where a paginated entry keeps its page count. StructureManifestEntry nests everything under pages (pages: {type, total, byteRanges}, pinned in tests/test_objects.py:108-113), while the storage convention and now Java put them in the entry itself:
"structure": {
"status": "complete",
"taskInput": {...},
"total": 3,
"pagination": {"type": "byteRanges", "ranges": [[0,1],[1,2],[2,3]]}
}
Neither side can read the other's page count today. Java no longer destroys the fields it does not model (it merges the manifest at tree level), so this is a read/compatibility gap rather than data loss, but a consumer cannot serve a docling-produced structure through the Java path until the shapes match.
Fix: move pages to the convention's entry-level total + pagination, where pagination carries type and, for the byteRanges scheme, ranges.
Found while reviewing ICIJ/datashare#2299, which makes Java a structure producer.
The two sides do not agree on where a paginated entry keeps its page count.
StructureManifestEntrynests everything underpages(pages: {type, total, byteRanges}, pinned intests/test_objects.py:108-113), while the storage convention and now Java put them in the entry itself:Neither side can read the other's page count today. Java no longer destroys the fields it does not model (it merges the manifest at tree level), so this is a read/compatibility gap rather than data loss, but a consumer cannot serve a docling-produced structure through the Java path until the shapes match.
Fix: move
pagesto the convention's entry-leveltotal+pagination, wherepaginationcarriestypeand, for the byteRanges scheme,ranges.