Bindery in dokumenti brez lepilne kode
Datoteka ni bila problem
Prva napaka je misliti, da je dokument datoteka. Pride kot datoteka, ja. Ima ime, navadno s končnico, ki deluje pomirjujoče. Nabavna preglednica pravi .xlsx, poročilo pravi .docx, arhivski izvoz pravi .pdf, in vsi se pretvarjajo, da je svet postal preprost, ker so zadnji štirje znaki videti znani. Lepo. Potem končnica laže, delovni zvezek ima skrite liste, predstavitev vsebuje vdelane objekte, PDF je večinoma besedilo, a ne povsem, in stara Wordova datoteka še vedno rahlo diši po letu 2003.
Večina ekip ne zgradi cevovoda za dokumente. Zgradijo majhen muzej izjem glede formatov. Ena knjižnica za Word, druga za Excel, nekaj za PDF-je, junaški lupinski skript za arhivsko mapo, paket Python, ki je bil nazadnje posodobljen, ko so bili vsi še navdušeni nad QR-kodami, in nekaj regularnih izrazov, ki bi jih bilo treba odpeljati ven in jim omogočiti miren pokoj. Čez šest mesecev je lepilna plast večja od izdelka. To ni redek način odpovedi. To je običajna oblika dela z dokumenti, ko vsak format dobi svoje kraljestvo.
Bindery obstaja, ker dokumentna plast ne bi smela postati glavni projekt. Na ravni implementacije je to Rustova zbirka dweve-bindery. Javna stran opisuje eno zbirko s 17 formati, DocQL, povezavami za Python in skupnim mehanizmom. Pomembno je, da visokonivojski API-ji, kot so Document, Presentation in Workbook, sedijo nad moduli, specifičnimi za formate, za OLE2, OOXML, ODF, iWork, RTF, PDF, Markdown, EPUB, LaTeX, slike, formule in DocQL. Ta seznam ni tam, da bi koga navdušil. Tam je, ker so resnični korpusi nesramni.
Uporabna trditev je preprosta: odprite dokument skozi en mehanizem, normalizirajte, kar je mogoče normalizirati, in zadržite bolečino, specifično za format, pod skupno površino. To ne naredi vsakega formata enakega. Razlike postane dovolj izrecne, da jih cevovod lahko preživi.
Zaznavanje ni okras
Zaznavanje formata zveni kot majhen pripomoček, dokler ne odpove. Potem postane celoten incident. Končnice so metapodatki, ki jih je zagotovila oseba, orodje, poštni prehod, izvozno opravilo, migracijski skript ali utrujeni pripravnik, ki se je nazadnje dotaknil datoteke. Včasih so pravilne. Včasih so vljuden predlog. Resen dokumentni mehanizem bi moral pregledati čarobne bajte, strukturo vsebnika, dele paketa, tokove in notranje namige, preden se odloči, kateri bralnik je lastnik datoteke.
Bindery to obravnava kot vhodna vrata. README in stran opisujeta samodejno zaznavanje formata. Dokumentacija knjižnice prikazuje Document::open in Presentation::open kot običajno pot, ne kot slovesnost izbire razčlenjevalnika. To je pomembno, ker uporabniki ne želijo tečaja iz dokumentne arheologije, preden lahko izvlečejo tabelo. Želijo, da mehanizem izbere pot in jim nato ponudi stabilen API.
Tu je suha mala lekcija. Manj glamurja kot ima komponenta, več škode lahko naredi, ko jo ljudje odmahnejo. Zaznavanje ni glamurozno. Prav tako niso pretvorba kodiranja, obravnava ZIP, sprehod po imeniku OLE, razreševanje relacij, dekompresija Snappy ali obravnava imenskih prostorov XML. V redu. Dolgočasno delo je ravno tam, kjer produkcijski cevovodi postanejo zanesljivi ali začnejo zbirati srečne amulete.
En model ne pomeni ene laži
Enotni API lahko postane nevaren, ko se pretvarja, da so razlike izginile. Bindery ne sme trditi, da so PDF, preglednica, arhiv iWork in paket OOXML ista stvar v različnih preoblekah. Niso. Uporabna arhitektura ni v tem, da resnico sploščimo v kašo. Je v tem, da izpostavimo skupne operacije tam, kjer so skupne, in ohranimo vidne meje zmogljivosti tam, kjer niso.
Razporeditev izvorne kode prikazuje to delitev. Obstaja enotni API za Wordove dokumente, enotni API za predstavitve, lastnosti preglednic, vrednotenje formul za funkcijami, povezovalniki DocQL ter moduli na nižji ravni za same formate. Javna matrika formatov pravi, da sta OOXML in ODF prvovrstni površini za branje, pisanje in poizvedovanje. PDF in RTF sta bolj usmerjena v branje in previdnejša pri pisanju. EPUB, LaTeX in Markdown so izhodni formati. Starejši Office in iWork imata lasten notranji mehanizem. To je prava drža. En motor, da. Ena fantazija, ne.
Ta razlika je pomembna pri revizijah in podatkovnih izdelkih. Če potek skladnosti izvaja klavzule iz pogodb, mora vedeti, ali vrednost izvira iz odstavka, celice tabele, opombe na prosojnici, formule ali besedilnega zaporedja v PDF-ju. Če naloga za vnos podatkov napaja poizvedovanje, mora vedeti, ali so bile slike, komentarji, metapodatki in povezave ohranjeni, prezrti ali označeni kot nepodprti. Odgovor ne sme biti zakopan v opombi, značilni za določen razčlenjevalnik, ker se ta opomba ne bo pojavila, ko bo nekdo vprašal, zakaj se je rezultat spremenil.
Dokumenti so strukturirani podatki, ki tega nočejo priznati
Najslabše, kar lahko cevovod za dokumente naredi, je, da vse prezgodaj zreducira na besedilo. Besedilo je uporabno. Besedilo ni celoten dokument. Preglednica ima formule, sklice, liste, vrstice, celice, oblike števil, komentarje in strukturo delovnega zvezka. Predstavitev ima prosojnice, oblike, slike, opombe, vrstni red in včasih korporativno predlogo, ki je preživela tri združitve in eno preimenovanje zgolj iz čiste zlobe. Wordov dokument ima odstavke, besedilna zaporedja, tabele, glave, noge, sloge, povezave in vdelane predmete. PDF ima tokove in odločitve o postavitvi, ki morda ustrezajo vrstnemu redu branja ali pa tudi ne. Vse to spremeniti v eno ravno besedilo je hitro, pomirjujoče in pogosto napačno.
API-ji na visoki ravni v Binderyju so uporabni, ker ohranjajo obliko dokumenta dovolj dolgo, da lahko postavljamo boljša vprašanja. API za dokumente izpostavlja odstavke, besedilna zaporedja, tabele, vrstice in celice. Modul za preglednice izpostavlja lastnosti delovnega zvezka in lista. Motor za formule pokriva veliko površino funkcij, združljivih z Excelom. DocQL dodaja poizvedovalni jezik v slogu SQL nad modelom dokumenta, z leksikalnim analizatorjem, razčlenjevalnikom, preverjevalnikom, načrtovalnikom, izvajalnikom, povezovalniki, vrednostmi in funkcijami v izvornem drevesu. To je več kot priročna lupina. To je način, kako prenehati pisati isto logiko za izločanje podatkov za vsak format posebej.
Predstavljajte si eno vprašanje nad celotnim korpusom: katere celice se sklicujejo na to predpostavko, katere tabele vsebujejo kategorijo tveganja, katere prosojnice omenjajo politiko, kateri dokumenti imajo lastno lastnost in katere formule so odvisne od danega vnosa. V kraljestvu posameznih formatov to postanejo štirje skripti in preglednica opravičil. V skupnem modelu to postane površina za poizvedovanje. Še vedno delo, seveda. Programska oprema ti le redko podari dopust. A to je pravo delo.
Zakaj je Rust smiseln za ta nered
Dokumentni formati so čudovita kombinacija binarnih struktur, stisnjenih paketov, XML, zapuščenih kodiranj, slikovnih vsebin, datumskih sistemov, semantike formul in varnostnih pomislekov. Z drugimi besedami, to je delo, kjer je nejasno lastništvo pomnilnika življenjski slog z računi. Rust je smiselna osnova, ker mora Bindery skrbno razčlenjevati, upravljati medpomnilnike, glasno obravnavati napake in izpostaviti API-je, ki preostalemu skladu ne pustijo ugibati, kaj je šlo narobe.
Značilnosti crate-a povedo isto zgodbo. Privzete značilnosti vključujejo OLE, OOXML, šifriranje OOXML in mehanizem eval. Polna podpora vklopi iWork, ODF, RTF, formule, pretvorbo slik, pisave in še več. DocQL je značilnost s svojo binarno datoteko. Izbirne odvisnosti se ujemajo s formati in površinami, ki jih podpirajo: obravnava ZIP, hitro razčlenjevanje XML, pretvorba kodiranj, Snappy, protobuf, dekodiranje slik, statistika in kompleksna števila za delo s formulami ter tako naprej. To ni en velik paket, ki se pretvarja, da vsaka odvisnost sodi povsod. Zastavice značilnosti ohranjajo obliko mehanizma dokumentov vidno.
To je pomembno za vgrajevanje. Sistem znanja bo morda želel polno pisarniško in poizvedovalno površino. Majhna storitev bo morda želela samo OOXML in izvleček besedila. Delovni tok v Pythonu bo morda želel vezave na istem mehanizmu. Pot ukazne vrstice za pregled je lahko uporabna za enkratne poizvedbe in teste. Stran govori o Rustu, PyO3 in vmesniku CLI; izvorna koda prikazuje binarno datoteko DocQL in paket PyO3. Pomembna oblikovna odločitev je, da te vstopne točke slonijo na enem mehanizmu. Sicer vsaka integracija postane svoja malce drugačna resnica, nato pa poročila o napakah začnejo nositi različne klobuke.
Zgodba o vzdrževanju je zgodba o izdelku
Bindery je enostavno opisati kot razčlenjevalnik, vendar je zgodba o vzdrževanju prava zgodba o izdelku. Vsaka nova knjižnica formatov, dodana v cevovod, ima svoj ritem izdaj, besednjak napak, vrste napak, posebnosti, tveganje odvisnosti, testne vložke in načine odpovedi. V majhnem obsegu je to videti obvladljivo. V obsegu korpusa postane operativna kartoteka, ki grize.
Skupni mehanizem ne odstrani zapletenosti formatov. To bi bilo sumljivo. Premakne zapletenost na mesto, kjer je mogoče teste, oznake zmogljivosti, značilnosti in API-je upravljati skupaj. README vsebuje testiranja od konca do konca za dokumente, predstavitve, preglednice, iWork in druge formate. Izvorno drevo ima module, ki jasno pokažejo meje formatov. Ta struktura ekipi omogoča izboljšanje plasti razčlenjevanja, ne da bi morala vsaka produktna ekipa znova spoznavati razliko med delom odnosa in tokom sestavljene datoteke.
To je razlog, zakaj se Bindery ujema s preostalim delom sklada Dweve. Reed skrbi za razčlenjevanje s potrdili. BitWeave skrbi za deterministično pridobivanje. Fabric in Spindle skrbita za urejeno znanje in operativno uporabo. Bindery stoji pred temi plastmi. Pisarniške dokumente pretvarja v strukturirano gradivo, o katerem lahko preostali del sklada razmišlja. Če je vhodna plast lepilo in upanje, podeduje celoten sistem navzdol lepilo in upanje. Zelo učinkovito, če je vaš strateški cilj prihodnje trpljenje.
Kaj se vprašati pred uvedbo
Prvo vprašanje ni, ali Bindery podpira vašo najljubšo končnico. To je vprašanje s kontrolnega seznama, kontrolni seznami pa so dobri, a to ni dovolj. Boljše vprašanje je, katere obljube glede dokumentov potrebujete. Ali potrebujete samo branje, podporo za pisanje, ohranjanje pri pretvorbi, vrednotenje formul, poizvedovanje po različnih formatih, metapodatke, vdelane slike, šifriran OOXML, starejši Office, iWork, ODF ali izhod v EPUB, LaTeX in Markdown? To so različna opravila. Pretvarjanje, da so eno opravilo, je pot, po kateri načrti postanejo juha.
Drugo vprašanje je, kako se razkrije napaka. Če razčlenjevalnik ne more ohraniti strukture, ali to pove? Če je pisec najboljši možen trud, ali je to vidno? Če formule ni mogoče vrednotiti, ali se lahko klicatelj odloči, ali bo blokiral, opozoril ali nadaljeval? Pogon za dokumente ni zanesljiv, ker nikoli ne reče ne. Zanesljiv je, ker je njegov ne tipiziran, natančen in blizu težavi.
Tretje vprašanje je, kako preizkusite svoj arhiv. Javni primeri so uporabni, vendar je vaš arhiv verjetno bolj nenavaden kot mapa s primeri. Vsebuje pokvarjene izvoze, starodavne predloge, nenavadne številske formate, skrite liste, kopirane tabele, nepravilne datoteke PDF in datoteke z imenom final_final_really_final. Bindery ponuja skupni pogon in preizkušljive površine. Še vedno potrebujete preizkuse arhiva. Žal se dokumenti ne bodo osamosvojili kar sami.
Nauček
Nauček Binderyja je, da obdelava dokumentov ni pridobivanje besedila z dodatnimi koraki. Gre za zaznavanje formata, strukturno razčlenjevanje, meje zmogljivosti, poizvedovalne površine, poti pisanja in vzdrževalno disciplino. Uporabnik vidi datoteko. Sistem vidi vsebnik, tokove, povezave, zapise, sloge, formule, metapodatke, kodiranja in obljube o izhodu. Dober pogon ohranja to zapletenost pod površino izdelka, ne da bi se pretvarjal, da ne obstaja.
Naloga Binderyja je, da plast dokumentov postane dolgočasna v dobrem pomenu besede. En pogon Rust. API-ji na visoki ravni za dokumente, predstavitve in preglednice. Moduli formatov za zapletene dele. DocQL za skupna vprašanja. Integracija s Pythonom in skladom, kjer je uporabna. Oznake zmogljivosti namesto mitologije formatov.
Datoteka nikoli ni bila težava. Težava je bilo lepilo. Bindery je poskus, da prenehamo plačevati najemnino za to plast lepila.