Bindery et documents sans code de collage
Le fichier n'était pas le problème
La première erreur consiste à penser que le document est le fichier. Il arrive sous forme de fichier, certes. Il a un nom, généralement avec une extension qui semble rassurante. Le tableur d'approvisionnement indique .xlsx, le rapport indique .docx, l'extraction d'archive indique .pdf, et tout le monde fait comme si le monde était devenu simple parce que les quatre derniers caractères semblent familiers. Charmant. Puis l'extension ment, le classeur contient des feuilles masquées, le diaporama renferme des objets incorporés, le PDF est surtout du texte mais pas tout à fait, et l'ancien fichier Word sent encore un peu 2003.
La plupart des équipes ne construisent pas un pipeline de documents. Elles construisent un petit musée des exceptions de format. Une bibliothèque pour Word, une autre pour Excel, encore autre chose pour les PDF, un script shell héroïque pour le dossier d'archives, un paquet Python mis à jour pour la dernière fois quand tout le monde trouvait encore les codes QR passionnants, et quelques expressions régulières qui mériteraient d'être emmenées dehors et mises à la retraite en toute discrétion. Six mois plus tard, la couche de colle est plus volumineuse que le produit. Ce n'est pas un mode de défaillance rare. C'est la forme normale du travail documentaire quand chaque format a son propre royaume.
Bindery existe parce que la couche documentaire ne devrait pas devenir le projet principal. Au niveau de l'implémentation, c'est une crate Rust nommée dweve-bindery. La page publique décrit une crate avec 17 formats, DocQL, des liaisons Python et un moteur commun. L'essentiel est que les API de haut niveau comme Document, Presentation et Workbook reposent sur des modules spécifiques aux formats pour OLE2, OOXML, ODF, iWork, RTF, PDF, Markdown, EPUB, LaTeX, images, formules et DocQL. Cette liste n'est pas là pour impressionner qui que ce soit. Elle est là parce que les corpus réels sont grossiers.
L'affirmation utile est simple : ouvrir le document via un seul moteur, normaliser ce qui peut l'être et maintenir la douleur spécifique au format sous une surface partagée. Cela ne rend pas chaque format identique. Cela rend les différences suffisamment explicites pour qu'un pipeline puisse y survivre.
La détection n'est pas une décoration
La détection de format ressemble à un petit utilitaire jusqu'à ce qu'elle échoue. Elle devient alors tout l'incident. Les extensions sont des métadonnées fournies par la personne, l'outil, la passerelle de messagerie, le travail d'exportation, le script de migration ou le stagiaire fatigué qui a touché le fichier en dernier. Parfois, elles sont correctes. Parfois, ce sont de simples suggestions polies. Un moteur documentaire sérieux doit inspecter les octets magiques, la structure du conteneur, les parties du paquet, les flux et les indices internes avant de décider quel lecteur possède le fichier.
Bindery traite cela comme la porte d'entrée. Le README et la page décrivent tous deux la détection automatique de format. La documentation de la bibliothèque présente Document::open et Presentation::open comme le chemin normal, et non comme une cérémonie de choix de l'analyseur. Cela compte parce que les utilisateurs ne veulent pas suivre un cours d'archéologie documentaire avant de pouvoir extraire un tableau. Ils veulent que le moteur choisisse le chemin, puis leur offre une API stable.
Il y a ici une petite leçon sèche. Moins un composant a de glamour, plus il peut faire de dégâts quand on l'écarte d'un revers de main. La détection n'est pas glamour. La conversion d'encodage, la gestion de ZIP, le parcours des répertoires OLE, la résolution des relations, la décompression Snappy ou la gestion des espaces de noms XML ne le sont pas non plus. Très bien. C'est précisément ce travail ennuyeux qui rend les pipelines de production fiables ou qui les transforme en collection de porte-bonheur.
Un modèle ne signifie pas un seul mensonge
Une API unifiée peut devenir dangereuse lorsqu'elle prétend que les différences ont disparu. Bindery ne devrait pas affirmer qu'un PDF, un tableur, une archive iWork et un package OOXML sont le même animal sous des habits différents. Ils ne le sont pas. L'architecture utile ne consiste pas à aplatir la vérité en bouillie. Elle consiste à exposer les opérations communes là où elles sont communes et à maintenir visibles les frontières de capacités là où elles ne le sont pas.
La structure des sources montre cette séparation. Il existe une API unifiée pour les documents Word, une API unifiée pour les présentations, des traits pour les tableurs, l'évaluation de formules derrière des fonctionnalités, des connecteurs DocQL et des modules de plus bas niveau pour les formats eux-mêmes. La matrice publique des formats indique que OOXML et ODF sont des surfaces de lecture, d'écriture et d'interrogation de première classe. PDF et RTF sont davantage orientés lecture et plus prudents à l'écriture. EPUB, LaTeX et Markdown sont des formats de sortie. Les formats Office hérités et iWork ont leur propre mécanique interne. C'est la bonne posture. Un moteur, oui. Une fantaisie, non.
Cette distinction compte dans les audits et les produits de données. Si un flux de conformité extrait des clauses de contrats, il doit savoir si une valeur provient d'un paragraphe, d'une cellule de tableau, d'une note de diapositive, d'une formule ou d'une séquence de texte PDF. Si un travail d'ingestion alimente de la recherche, il doit savoir si les images, les commentaires, les métadonnées et les relations ont été préservés, ignorés ou marqués comme non pris en charge. La réponse ne peut pas être enfouie dans une note de bas de page spécifique à un analyseur, car cette note ne remontera pas quand quelqu'un demandera pourquoi le résultat a changé.
Les documents sont des données structurées qui ont oublié de l'admettre
La pire chose qu'un pipeline de documents puisse faire est de tout réduire en texte trop tôt. Le texte est utile. Le texte n'est pas le document entier. Un tableur contient des formules, des références, des feuilles, des lignes, des cellules, des formats de nombres, des commentaires et une structure de classeur. Une présentation contient des diapositives, des formes, des images, des notes, un ordre et parfois un modèle d'entreprise qui a survécu à trois fusions et un changement de marque par pure malice. Un document Word contient des paragraphes, des séquences, des tableaux, des en-têtes, des pieds de page, des styles, des relations et des objets incorporés. Un PDF contient des flux et des décisions de mise en page qui peuvent ou non correspondre à l'ordre de lecture. Tout transformer en une seule chaîne plate est rapide, rassurant et souvent faux.
Les API de haut niveau de Bindery sont utiles car elles maintiennent la forme du document vivante assez longtemps pour poser de meilleures questions. L'API document expose les paragraphes, les séquences, les tableaux, les lignes et les cellules. Le module tableur expose les traits de classeur et de feuille de calcul. Le moteur de formules couvre une vaste surface de fonctions compatible Excel. DocQL ajoute un langage d'interrogation de type SQL sur le modèle de document, avec analyseur lexical, analyseur syntaxique, validateur, planificateur, exécuteur, connecteurs, valeurs et fonctions dans l'arborescence des sources. C'est plus qu'un simple wrapper de commodité. C'est une façon d'arrêter de réécrire la même logique d'extraction pour chaque format.
Imaginez poser une seule question sur un corpus : quelles cellules référencent cette hypothèse, quels tableaux contiennent une catégorie de risque, quelles diapositives mentionnent une politique, quels documents ont une propriété personnalisée et quelles formules dépendent d'une entrée donnée. Dans le royaume par format, cela devient quatre scripts et un tableur d'excuses. Dans un modèle partagé, cela devient une surface d'interrogation. Du travail, évidemment. Les logiciels vous offrent rarement des vacances. Mais c'est le bon travail.
Pourquoi Rust est un choix sensé pour ce chantier
Les formats de documents sont une combinaison merveilleuse de structures binaires, de paquets compressés, de XML, d'encodages hérités, de charges utiles d'images, de systèmes de dates, de sémantique de formules et de préoccupations de sécurité. Autrement dit, le genre de travail où une gestion floue de la mémoire est un choix de vie assorti de factures. Rust est une base sensée parce que Bindery doit faire de l'analyse minutieuse, gérer des tampons, signaler les erreurs avec vigueur et exposer des API qui n'obligent pas le reste de la pile à deviner ce qui a mal tourné.
Les fonctionnalités de la crate racontent la même histoire. Les fonctionnalités par défaut incluent OLE, OOXML, le chiffrement OOXML et le moteur d'évaluation. Le support complet active iWork, ODF, RTF, les formules, la conversion d'images, les polices et plus encore. DocQL est une fonctionnalité avec son propre binaire. Les dépendances optionnelles s'alignent sur les formats et surfaces qu'elles prennent en charge : gestion de ZIP, analyse XML rapide, conversion d'encodage, Snappy, protobuf, décodage d'images, statistiques et nombres complexes pour le travail sur les formules, et ainsi de suite. Ce n'est pas un bloc géant qui prétend que chaque dépendance va partout. Les indicateurs de fonctionnalités gardent la forme du moteur documentaire visible.
Cela compte pour l'intégration. Un système de connaissances peut vouloir toute la surface bureautique et de requête. Un petit service peut vouloir seulement OOXML et l'extraction de texte. Un flux de travail Python peut vouloir des liaisons sur le même moteur. Un chemin d'inspection en ligne de commande peut être utile pour des requêtes ponctuelles et des tests. La page parle de Rust, de PyO3 et d'une surface CLI ; la source montre un binaire DocQL et un paquet PyO3. Le choix de conception important est que ces points d'entrée reposent sur un seul moteur. Sinon, chaque intégration devient sa propre vérité légèrement différente, et les rapports de bogues commencent à porter des chapeaux différents.
L'histoire de la maintenance est l'histoire du produit
Bindery est facile à décrire comme un analyseur, mais l'histoire de la maintenance est la véritable histoire du produit. Chaque nouvelle bibliothèque de formats ajoutée à un pipeline a son propre rythme de publication, son vocabulaire de bogues, ses types d'erreurs, ses particularités, son risque de dépendance, ses fixtures de test et ses modes de défaillance. À petite échelle, cela semble gérable. À l'échelle d'un corpus, cela devient un classeur opérationnel qui mord.
Un moteur partagé ne supprime pas la complexité des formats. Cela serait suspect. Il déplace la complexité dans un endroit où les tests, les étiquettes de capacités, les fonctionnalités et les API peuvent être gérés ensemble. Le README contient des tests de bout en bout pour les formats document, présentation, tableur, iWork et autres. L'arborescence source a des modules qui rendent les frontières de formats évidentes. Cette structure est ce qui permet à une équipe d'améliorer la couche d'analyse sans demander à chaque équipe produit de réapprendre la différence entre une partie de relation et un flux de fichier composé.
Voici pourquoi Bindery s’intègre naturellement au reste de la pile Dweve. Reed se concentre sur l’analyse avec reçus. BitWeave se concentre sur la récupération déterministe. Fabric et Spindle se concentrent sur la gouvernance des connaissances et l’utilisation opérationnelle. Bindery se place avant ces couches. Il transforme les documents bureautiques en matériel structuré que le reste de la pile peut analyser. Si la couche d’entrée est de la colle et de l’espoir, le système en aval hérite de la colle et de l’espoir. Très efficace, si votre objectif stratégique est la souffrance future.
Ce qu’il faut demander avant de l’adopter
La première question n’est pas de savoir si Bindery prend en charge votre extension préférée. C’est une question de liste de contrôle, et les listes de contrôle sont utiles, mais cela ne suffit pas. La meilleure question est de savoir quelles promesses documentaires vous avez besoin. Avez-vous besoin d’extraction en lecture seule, de prise en charge de l’écriture, de préservation aller-retour, d’évaluation de formules, d’interrogation multi-formats, de métadonnées, d’images intégrées, d’OOXML chiffré, d’Office hérité, d’iWork, d’ODF, ou de sortie vers EPUB, LaTeX et Markdown ? Ce sont des tâches différentes. Prétendre qu’elles n’en font qu’une, c’est ainsi que les feuilles de route deviennent de la bouillie.
La deuxième question est de savoir comment les échecs sont révélés. Si un analyseur ne peut pas préserver une structure, le dit-il ? Si un rédacteur est au mieux de ses capacités, est-ce visible ? Si une formule ne peut pas être évaluée, l’appelant peut-il décider de bloquer, d’avertir ou de continuer ? Un moteur documentaire n’est pas fiable parce qu’il ne dit jamais non. Il est fiable parce que son non est typé, spécifique et proche du problème.
La troisième question est de savoir comment vous testez votre propre corpus. Les exemples publics sont utiles, mais votre archive est probablement plus étrange que le dossier d’exemples. Elle contient des exports cassés, des modèles anciens, des formats de nombres étranges, des feuilles masquées, des tableaux copiés-collés, des PDF malformés et des fichiers nommés final_final_really_final. Bindery fournit un moteur partagé et des surfaces testables. Vous avez toujours besoin de tests de corpus. Malheureusement, les documents ne deviendront pas adultes tout seuls.
La leçon
La leçon de Bindery est que le traitement documentaire n’est pas une extraction de texte avec des étapes supplémentaires. C’est la détection de format, l’analyse structurelle, les limites de capacités, les surfaces d’interrogation, les chemins d’écriture et la discipline de maintenance. L’utilisateur voit un fichier. Le système voit un conteneur, des flux, des relations, des enregistrements, des styles, des formules, des métadonnées, des encodages et des promesses de sortie. Un bon moteur garde cette complexité sous la surface du produit sans prétendre qu’elle n’existe pas.
Le travail de Bindery est de rendre la couche documentaire ennuyeuse dans le bon sens. Un seul moteur Rust. Des API de haut niveau pour les documents, les présentations et les feuilles de calcul. Des modules de format pour les parties complexes. DocQL pour les questions partagées. Intégration Python et pile là où c’est utile. Des étiquettes de capacités au lieu d’une mythologie des formats.
Le fichier n’a jamais été le problème. La colle l’était. Bindery est la tentative d’arrêter de payer un loyer pour cette couche de colle.