Bindery a dokumenty bez lepiaceho kódu
Súbor nebol problém
Prvou chybou je myslieť si, že dokument je súbor. Dorazí ako súbor, áno. Má názov, zvyčajne s príponou, ktorá vyzerá upokojujúco. Nákupná tabuľka hovorí .xlsx, správa hovorí .docx, archívny výpis hovorí .pdf a každý predstiera, že svet sa zjednodušil, pretože posledné štyri znaky vyzerajú povedome. Krásne. Potom prípona klame, zošit má skryté hárky, prezentácia obsahuje vložené objekty, PDF je väčšinou text, ale nie celkom, a starý Word súbor stále cítiť rokom 2003.
Väčšina tímov nebuduje dokumentový pipeline. Budujú malé múzeum výnimiek formátov. Jedna knižnica pre Word, ďalšia pre Excel, niečo iné pre PDF, hrdinský shell skript pre archívny priečinok, Python balík, ktorý bol naposledy aktualizovaný, keď si každý ešte myslel, že QR kódy sú vzrušujúce, a pár regulárnych výrazov, ktoré by mali byť odvedené von a dostali by tichý dôchodok. O šesť mesiacov neskôr je lepiaca vrstva väčšia ako produkt. Toto nie je zriedkavý spôsob zlyhania. Toto je normálny tvar dokumentovej práce, keď každý formát dostane svoje vlastné kráľovstvo.
Bindery existuje, pretože dokumentová vrstva by sa nemala stať hlavným projektom. Na úrovni implementácie je to Rust crate s názvom dweve-bindery. Verejná stránka opisuje jeden crate so 17 formátmi, DocQL, Python bindings a spoločným engine. Dôležité je, že vysokotrovňové API ako Document, Presentation a Workbook sedia nad modulmi špecifickými pre formáty OLE2, OOXML, ODF, iWork, RTF, PDF, Markdown, EPUB, LaTeX, obrázky, vzorce a DocQL. Tento zoznam tam nie je, aby niekoho ohromil. Je tam, pretože skutočné korpusy sú drzé.
Užitočné tvrdenie je jednoduché: otvorte dokument cez jeden engine, normalizujte, čo sa normalizovať dá, a držte bolesť špecifickú pre formát pod spoločným povrchom. To nerobí každý formát identickým. Robí rozdiely dostatočne explicitnými, aby ich pipeline dokázal prežiť.
Detekcia nie je dekorácia
Detekcia formátu znie ako malý nástroj, kým nezlyhá. Potom sa stane celým incidentom. Prípony sú metadáta dodané osobou, nástrojom, mailovou bránou, exportnou úlohou, migračným skriptom alebo unaveným stážistom, ktorý sa naposledy dotkol súboru. Niekedy sú správne. Niekedy sú zdvorilým návrhom. Seriózny dokumentový engine by mal preskúmať magic bytes, štruktúru kontajnera, časti balíka, streamy a interné signály predtým, než sa rozhodne, ktorý čítač vlastní súbor.
Bindery to považuje za predné dvere. README aj stránka opisujú automatickú detekciu formátu. Dokumentácia knižnice ukazuje Document::open a Presentation::open ako normálnu cestu, nie ceremóniu vyberania parsera. To je dôležité, pretože používatelia nechcú kurz dokumentovej archeológie, kým môžu extrahovať tabuľku. Chcú, aby engine vybral cestu a potom im dal stabilné API.
Je tu suché malé ponaučenie. Čím menej glamour komponent má, tým viac škody môže napáchať, keď ho ľudia mávnutím ruky odignorujú. Detekcia nie je glamour. Ani konverzia kódovania, ZIP handling, prechádzanie OLE adresárov, riešenie vzťahov, Snappy dekompresia alebo spracovanie XML namespace. Dobre. Nudná práca je presne tam, kde sa produkčné pipeline buď stanú spoľahlivými, alebo začnú zbierať šťastné talizmany.
Jeden model neznamená jednu lož
Jednotné API sa môže stať nebezpečným, keď predstiera, že rozdiely zmizli. Bindery by nemal tvrdiť, že PDF, tabuľkový dokument, archív iWork a balík OOXML sú to isté zviera v rôznych kabátoch. Nie sú. Užitočná architektúra nespočíva v tom, že pravdu sploštíme na kašu. Spočíva v tom, že sprístupníme spoločné operácie tam, kde sú spoločné, a zachováme viditeľné hranice schopností tam, kde nie sú.
Rozloženie zdrojového kódu túto hranicu ukazuje. Existuje jednotné API pre Word dokumenty, jednotné API pre prezentácie, vlastnosti tabuľkových dokumentov, vyhodnocovanie vzorcov za funkciami, konektory DocQL a moduly nižšej úrovne pre samotné formáty. Verejná matica formátov hovorí, že OOXML a ODF sú prvotriedne povrchy na čítanie, zápis a dopytovanie. PDF a RTF sú zamerané skôr na čítanie a pri zápise sú opatrnejšie. EPUB, LaTeX a Markdown sú výstupné formáty. Legacy Office a iWork majú vlastný interný mechanizmus. Toto je správny postoj. Jeden engine, áno. Jedna fantázia, nie.
Tento rozdiel je dôležitý pri auditoch a dátových produktoch. Ak pracovný postup pre compliance extrahuje klauzuly zo zmlúv, musí vedieť, či hodnota pochádza z odseku, bunky tabuľky, poznámky na snímke, vzorca alebo textového riadku PDF. Ak úloha na ingestiu napája retrieval, musí vedieť, či boli obrázky, komentáre, metadáta a vzťahy zachované, ignorované alebo označené ako nepodporované. Odpoveď nemôže byť pochovaná v poznámke pod čiarou špecifickej pre parser, pretože táto poznámka sa neukáže, keď sa niekto spýta, prečo sa výsledok zmenil.
Dokumenty sú štruktúrované dáta, ktoré zabudli, že nimi sú
To najhoršie, čo môže dokumentový pipeline urobiť, je zredukovať všetko na text príliš skoro. Text je užitočný. Text nie je celý dokument. Tabuľkový dokument má vzorce, odkazy, hárky, riadky, bunky, formáty čísel, komentáre a štruktúru zošita. Prezentácia má snímky, tvary, obrázky, poznámky, poradie a niekedy firemnú šablónu, ktorá prežila tri fúzie a jeden rebranding čírou zlomyseľnosťou. Word dokument má odseky, behy, tabuľky, hlavičky, pätičky, štýly, vzťahy a vložené objekty. PDF má toky a rozhodnutia o rozložení, ktoré môžu, ale nemusia zodpovedať poradiu čítania. Premeniť všetko na jeden plochý reťazec je rýchle, upokojujúce a často nesprávne.
Vysokoúrovňové API Bindery sú užitočné, pretože udržiavajú tvar dokumentu nažive dostatočne dlho na to, aby sme mohli klásť lepšie otázky. API dokumentov sprístupňuje odseky, behy, tabuľky, riadky a bunky. Modul tabuľkových dokumentov sprístupňuje vlastnosti zošita a hárka. Engine vzorcov pokrýva veľký povrch funkcií kompatibilných s Excelom. DocQL pridáva dopytovací jazyk podobný SQL nad modelom dokumentov, pričom v zdrojovom strome sú lexer, parser, validátor, plánovač, exekútor, konektory, hodnoty a funkcie. To je viac než len pohodlný obal. Je to spôsob, ako prestať prepisovať rovnakú extrakčnú logiku pre každý formát.
Predstavte si, že položíte jednu otázku nad korpusom: ktoré bunky odkazujú na tento predpoklad, ktoré tabuľky obsahujú rizikovú kategóriu, ktoré snímky spomínajú politiku, ktoré dokumenty majú vlastnú vlastnosť a ktoré vzorce závisia od daného vstupu. V kráľovstve jednotlivých formátov sa to zmení na štyri skripty a tabuľku ospravedlnení. V zdieľanom modeli sa to zmení na dopytovací povrch. Stále je to práca, samozrejme. Softvér vám málokedy daruje dovolenku. Ale je to tá správna práca.
Prečo je Rust rozumným základom pre tento chaos
Dokumentové formáty sú nádhernou kombináciou binárnych štruktúr, komprimovaných balíkov, XML, starších kódovaní, obrazových dát, dátumových systémov, sémantiky vzorcov a bezpečnostných rizík. Inými slovami, práca, kde je vágne vlastníctvo pamäte životným štýlom s priloženými fakturami. Rust je rozumným základom, pretože Bindery musí robiť starostlivé parsovanie, spravovať vyrovnávacie pamäte, nahlas hlásiť chyby a ponúkať API, ktoré nenechávajú zvyšok zásobníka hádať, čo sa pokazilo.
Funkcie crate hovoria rovnaký príbeh. Predvolené funkcie zahŕňajú OLE, OOXML, šifrovanie OOXML a eval engine. Plná podpora zapína iWork, ODF, RTF, vzorce, konverziu obrázkov, fonty a ďalšie. DocQL je funkcia s vlastným binárnym súborom. Voliteľné závislosti zodpovedajú formátom a povrchom, ktoré podporujú: spracovanie ZIP, rýchle parsovanie XML, konverziu kódovania, Snappy, protobuf, dekódovanie obrázkov, štatistiku a komplexné čísla pre prácu so vzorcami a tak ďalej. Toto nie je jeden obrovský blok, ktorý predstiera, že každá závislosť patrí všade. Príznaky funkcií udržiavajú tvar dokumentového enginu viditeľný.
To je dôležité pre vkladanie. Znalostný systém môže chcieť plný kancelársky a dotazovací povrch. Malá služba môže chcieť iba OOXML a extrakciu textu. Python pracovný postup môže chcieť väzby na rovnaký engine. Príkazový riadok môže byť užitočný pre jednorazové dotazy a testy. Stránka hovorí o Ruste, PyO3 a CLI povrchu; zdroj ukazuje DocQL binárny súbor a PyO3 balík. Dôležitým dizajnovým rozhodnutím je, že tieto vstupné body sedia na jednom engine. Inak sa každá integrácia stane svojou vlastnou mierne odlišnou pravdou a potom hlásenia o chybách začnú nosiť rôzne klobúky.
Príbeh údržby je príbehom produktu
Bindery sa dá ľahko opísať ako parser, ale príbeh údržby je skutočným príbehom produktu. Každá nová knižnica formátov pridaná do pipeline má svoje vlastné tempo vydávania, slovník chýb, typy chýb, zvláštnosti, riziko závislostí, testovacie prípady a režimy zlyhania. V malom rozsahu to vyzerá zvládnuteľne. V rozsahu korpusu sa to stáva operačným kartotékovým systémom, ktorý hryzie.
Zdieľaný engine neodstraňuje zložitosť formátov. To by bolo podozrivé. Presúva zložitosť na miesto, kde sa dajú testy, štítky schopností, funkcie a API spravovať spoločne. README má end-to-end testy pre dokument, prezentáciu, tabuľku, iWork a ďalšie formáty. Zdrojový strom má moduly, ktoré robia hranice formátov zrejmými. Táto štruktúra umožňuje tímu vylepšovať vrstvu parsera bez toho, aby musel každý produktový tím znovu učiť rozdiel medzi vzťahovou časťou a zloženým súborovým prúdom.
Preto Bindery zapadá do zvyšku stacku Dweve. Reed sa stará o parsovanie s potvrdenkami. BitWeave sa stará o deterministické vyhľadávanie. Fabric a Spindle sa starajú o riadené znalosti a operačné použitie. Bindery stojí pred týmito vrstvami. Premieňa kancelárske dokumenty na štruktúrovaný materiál, o ktorom môže zvyšok stacku uvažovať. Ak je vstupná vrstva lepidlo a nádej, downstream systém zdedí lepidlo a nádej. Veľmi efektívne, ak je vaším strategickým cieľom budúce utrpenie.
Čo si položiť za otázku pred jeho prijatím
Prvá otázka nie je, či Bindery podporuje vašu obľúbenú príponu. To je otázka z kontrolného zoznamu a kontrolné zoznamy sú dobré, ale nestačí to. Lepšia otázka je, ktoré sľuby týkajúce sa dokumentov potrebujete. Potrebujete extrakciu iba na čítanie, podporu zápisu, zachovanie round-trip, vyhodnocovanie vzorcov, dopytovanie naprieč formátmi, metadáta, vložené obrázky, šifrovaný OOXML, starší Office, iWork, ODF alebo výstup do EPUB, LaTeX a Markdown? To sú rôzne úlohy. Predstierať, že sú jednou úlohou, je spôsob, ako sa z roadmapy stane guláš.
Druhá otázka je, ako sa zlyhania zviditeľňujú. Ak parser nedokáže zachovať štruktúru, povie to? Ak je zapisovač best-effort, je to viditeľné? Ak sa vzorec nedá vyhodnotiť, môže volajúci rozhodnúť, či má blokovať, varovať alebo pokračovať? Dokumentový engine nie je spoľahlivý preto, že nikdy nepovie nie. Je spoľahlivý preto, že jeho nie je typované, konkrétne a blízko problému.
Tretia otázka je, ako testujete vlastný korpus. Verejné príklady sú užitočné, ale váš archív je pravdepodobne čudnejší ako priečinok s príkladmi. Má rozbité exporty, staré šablóny, zvláštne formáty čísel, skryté hárky, skopírované tabuľky, poškodené PDF a súbory s názvom final_final_really_final. Bindery poskytuje zdieľaný engine a testovateľné povrchy. Stále potrebujete testy korpusu. Žiaľ, dokumenty samé od seba nedospejú.
Ponaučenie
Ponaučenie z Bindery je, že spracovanie dokumentov nie je extrakcia textu s ďalšími krokmi. Je to detekcia formátu, štrukturálne parsovanie, hranice schopností, dopytovacie povrchy, cesty zápisu a disciplína údržby. Používateľ vidí súbor. Systém vidí kontajner, prúdy, vzťahy, záznamy, štýly, vzorce, metadáta, kódovania a výstupné sľuby. Dobrý engine udržiava túto zložitosť pod povrchom produktu bez toho, aby predstieral, že neexistuje.
Úlohou Bindery je urobiť dokumentovú vrstvu nudnou v dobrom zmysle. Jeden Rust engine. Vysokoúrovňové API pre dokumenty, prezentácie a tabuľky. Moduly formátov pre chaotické časti. DocQL pre zdieľané otázky. Python a integrácia do stacku tam, kde je to užitočné. Štítky schopností namiesto mytológie formátov.
Súbor nikdy nebol problém. Problém bolo lepidlo. Bindery je pokus prestať platiť nájomné za túto vrstvu lepidla.