Bindery και έγγραφα χωρίς glue code
Το πρόβλημα δεν ήταν το αρχείο
Το πρώτο λάθος είναι να νομίζεις ότι το έγγραφο είναι το αρχείο. Φτάνει ως αρχείο, ναι. Έχει όνομα, συνήθως με κατάληξη που φαίνεται καθησυχαστική. Το υπολογιστικό φύλλο προμηθειών λέει .xlsx, η αναφορά λέει .docx, το αρχείο αρχειοθέτησης λέει .pdf, και όλοι προσποιούνται ότι ο κόσμος έγινε απλός επειδή οι τέσσερις τελευταίοι χαρακτήρες φαίνονται γνωστοί. Ωραία. Μετά η κατάληξη ψεύδεται, το βιβλίο εργασίας έχει κρυφά φύλλα, η παρουσίαση περιέχει ενσωματωμένα αντικείμενα, το PDF είναι κυρίως κείμενο αλλά όχι εντελώς, και το παλιό αρχείο Word εξακολουθεί να μυρίζει ελαφρώς 2003.
Οι περισσότερες ομάδες δεν φτιάχνουν μια γραμμή επεξεργασίας εγγράφων. Φτιάχνουν ένα μικρό μουσείο εξαιρέσεων μορφών. Μία βιβλιοθήκη για το Word, άλλη για το Excel, κάτι άλλο για τα PDF, ένα ηρωικό σενάριο κελύφους για τον φάκελο αρχειοθέτησης, ένα πακέτο Python που ενημερώθηκε τελευταία φορά όταν όλοι θεωρούσαν ακόμα τα QR codes συναρπαστικά, και μερικές κανονικές εκφράσεις που θα έπρεπε να τις βγάλουν έξω και να τους δώσουν μια ήσυχη σύνταξη. Έξι μήνες αργότερα, το στρώμα συγκόλλησης είναι μεγαλύτερο από το προϊόν. Αυτό δεν είναι σπάνια αποτυχία. Αυτό είναι το φυσιολογικό σχήμα της εργασίας με έγγραφα όταν κάθε μορφή έχει το δικό της βασίλειο.
Το Bindery υπάρχει επειδή το στρώμα εγγράφων δεν πρέπει να γίνει το κύριο έργο. Σε επίπεδο υλοποίησης είναι μια crate της Rust με το όνομα dweve-bindery. Η δημόσια σελίδα περιγράφει μία crate με 17 μορφές, DocQL, δεσίματα Python και μια κοινή μηχανή. Το σημαντικό είναι ότι τα API υψηλού επιπέδου όπως Document, Presentation και Workbook βρίσκονται πάνω από ενότητες ειδικές για μορφές, όπως OLE2, OOXML, ODF, iWork, RTF, PDF, Markdown, EPUB, LaTeX, εικόνες, τύπους και DocQL. Αυτή η λίστα δεν υπάρχει για να εντυπωσιάσει κανέναν. Υπάρχει επειδή τα πραγματικά σώματα κειμένων είναι αγενή.
Ο χρήσιμος ισχυρισμός είναι απλός: άνοιξε το έγγραφο μέσω μιας μηχανής, ομαλοποίησε ό,τι μπορεί να ομαλοποιηθεί και κράτησε τον πόνο που σχετίζεται με τη μορφή κάτω από μια κοινή επιφάνεια. Αυτό δεν κάνει όλες τις μορφές πανομοιότυπες. Κάνει τις διαφορές αρκετά σαφείς ώστε μια γραμμή επεξεργασίας να μπορεί να τις αντέξει.
Η ανίχνευση δεν είναι διακόσμηση
Η ανίχνευση μορφής ακούγεται σαν ένα μικρό βοηθητικό εργαλείο μέχρι να αποτύχει. Τότε γίνεται ολόκληρο το περιστατικό. Οι καταλήξεις είναι μεταδεδομένα που παρέχονται από το άτομο, το εργαλείο, την πύλη αλληλογραφίας, την εργασία εξαγωγής, το σενάριο μετεγκατάστασης ή τον κουρασμένο ασκούμενο που άγγιξε τελευταίος το αρχείο. Μερικές φορές είναι σωστές. Μερικές φορές είναι μια ευγενική υπόδειξη. Μια σοβαρή μηχανή εγγράφων θα πρέπει να εξετάζει τα magic bytes, τη δομή του περιέκτη, τα μέρη του πακέτου, τα streams και τις εσωτερικές ενδείξεις προτού αποφασίσει ποιος αναγνώστης ανήκει στο αρχείο.
Το Bindery το αντιμετωπίζει αυτό ως την κύρια είσοδο. Το README και η σελίδα περιγράφουν και τα δύο την αυτόματη ανίχνευση μορφής. Η τεκμηρίωση της βιβλιοθήκης δείχνει τα Document::open και Presentation::open ως τον κανονικό δρόμο, όχι ως μια τελετή επιλογής αναλυτή. Αυτό έχει σημασία επειδή οι χρήστες δεν θέλουν ένα μάθημα εκπαίδευσης στην αρχαιολογία εγγράφων προτού μπορέσουν να εξαγάγουν έναν πίνακα. Θέλουν η μηχανή να επιλέξει τη διαδρομή και μετά να τους δώσει ένα σταθερό API.
Υπάρχει ένα ξερό μικρό μάθημα εδώ. Όσο λιγότερη γοητεία έχει ένα στοιχείο, τόσο μεγαλύτερη ζημιά μπορεί να κάνει όταν οι άνθρωποι το απορρίπτουν με μια κίνηση. Η ανίχνευση δεν είναι γοητευτική. Ούτε η μετατροπή κωδικοποίησης, ο χειρισμός ZIP, η περιήγηση σε καταλόγους OLE, η επίλυση σχέσεων, η αποσυμπίεση Snappy ή ο χειρισμός χώρων ονομάτων XML. Εντάξει. Η βαρετή δουλειά είναι ακριβώς εκεί που οι γραμμές επεξεργασίας παραγωγής είτε γίνονται αξιόπιστες είτε αρχίζουν να μαζεύουν γούρια.
Ένα μοντέλο δεν σημαίνει ένα ψέμα
Ένα ενοποιημένο API μπορεί να γίνει επικίνδυνο όταν προσποιείται ότι οι διαφορές έχουν εξαφανιστεί. Το Bindery δεν θα έπρεπε να ισχυρίζεται ότι ένα PDF, ένα υπολογιστικό φύλλο, ένα αρχείο iWork και ένα πακέτο OOXML είναι το ίδιο ζώο με διαφορετικά καπέλα. Δεν είναι. Η χρήσιμη αρχιτεκτονική δεν είναι να ισοπεδώνεις την αλήθεια σε χυλό. Είναι να εκθέτεις τις κοινές λειτουργίες εκεί που είναι κοινές και να κρατάς ορατά τα όρια δυνατοτήτων εκεί που δεν είναι.
Η διάταξη του πηγαίου κώδικα δείχνει αυτόν τον διαχωρισμό. Υπάρχει ένα ενοποιημένο API για έγγραφα Word, ένα ενοποιημένο API για παρουσιάσεις, χαρακτηριστικά υπολογιστικών φύλλων, αξιολόγηση τύπων πίσω από δυνατότητες, προσαρμογείς DocQL και χαμηλότερου επιπέδου ενότητες για τις ίδιες τις μορφές. Ο δημόσιος πίνακας μορφών λέει ότι τα OOXML και ODF είναι επιφάνειες πρώτης κατηγορίας για ανάγνωση, εγγραφή και ερωτήματα. Τα PDF και RTF είναι πιο βαριά στην ανάγνωση και πιο προσεκτικά στην εγγραφή. Τα EPUB, LaTeX και Markdown είναι μορφές εξόδου. Τα παλαιότερα Office και iWork έχουν τον δικό τους εσωτερικό μηχανισμό. Αυτή είναι η σωστή στάση. Ένας κινητήρας, ναι. Μία φαντασίωση, όχι.
Αυτή η διάκριση έχει σημασία σε ελέγχους και προϊόντα δεδομένων. Αν μια ροή εργασίας συμμόρφωσης εξάγει ρήτρες από συμβόλαια, πρέπει να γνωρίζει αν μια τιμή προήλθε από μια παράγραφο, ένα κελί πίνακα, μια σημείωση διαφάνειας, έναν τύπο ή ένα τμήμα κειμένου PDF. Αν μια εργασία εισαγωγής τροφοδοτεί την ανάκτηση, πρέπει να γνωρίζει αν οι εικόνες, τα σχόλια, τα μεταδεδομένα και οι σχέσεις διατηρήθηκαν, αγνοήθηκαν ή επισημάνθηκαν ως μη υποστηριζόμενα. Η απάντηση δεν μπορεί να είναι θαμμένη σε μια υποσημείωση ειδική για τον αναλυτή, γιατί αυτή η υποσημείωση δεν θα εμφανιστεί όταν κάποιος ρωτήσει γιατί άλλαξε το αποτέλεσμα.
Τα έγγραφα είναι δομημένα δεδομένα που ξέχασαν να το παραδεχτούν
Το χειρότερο πράγμα που μπορεί να κάνει ένας αγωγός εγγράφων είναι να μειώσει τα πάντα σε κείμενο πολύ νωρίς. Το κείμενο είναι χρήσιμο. Το κείμενο δεν είναι ολόκληρο το έγγραφο. Ένα υπολογιστικό φύλλο έχει τύπους, αναφορές, φύλλα, σειρές, κελιά, μορφές αριθμών, σχόλια και δομή βιβλίου εργασίας. Μια παρουσίαση έχει διαφάνειες, σχήματα, εικόνες, σημειώσεις, σειρά και μερικές φορές ένα εταιρικό πρότυπο που έχει επιβιώσει από τρεις συγχωνεύσεις και μία αλλαγή επωνυμίας από καθαρή κακία. Ένα έγγραφο Word έχει παραγράφους, τμήματα, πίνακες, κεφαλίδες, υποσέλιδα, στυλ, σχέσεις και ενσωματωμένα αντικείμενα. Ένα PDF έχει ροές και αποφάσεις διάταξης που μπορεί να αντιστοιχούν ή να μην αντιστοιχούν στη σειρά ανάγνωσης. Το να μετατρέψεις όλα αυτά σε μία επίπεδη συμβολοσειρά είναι γρήγορο, παρηγορητικό και συχνά λάθος.
Τα υψηλού επιπέδου API του Bindery είναι χρήσιμα επειδή κρατούν ζωντανό το σχήμα του εγγράφου αρκετά ώστε να κάνεις καλύτερες ερωτήσεις. Το API εγγράφων εκθέτει παραγράφους, τμήματα, πίνακες, σειρές και κελιά. Η ενότητα υπολογιστικών φύλλων εκθέτει χαρακτηριστικά βιβλίου εργασίας και φύλλου. Η μηχανή τύπων καλύπτει μια μεγάλη επιφάνεια συναρτήσεων συμβατή με το Excel. Το DocQL προσθέτει μια γλώσσα ερωτημάτων τύπου SQL πάνω στο μοντέλο εγγράφων, με λεξικό αναλυτή, συντακτικό αναλυτή, επικυρωτή, προγραμματιστή, εκτελεστή, προσαρμογείς, τιμές και συναρτήσεις στο δέντρο πηγαίου κώδικα. Αυτό είναι κάτι περισσότερο από ένα περιτύλιγμα ευκολίας. Είναι ένας τρόπος να σταματήσεις να ξαναγράφεις την ίδια λογική εξαγωγής για κάθε μορφή.
Φαντάσου να κάνεις μία ερώτηση στο σώμα εγγράφων: ποια κελιά αναφέρονται σε αυτή την υπόθεση, ποιοι πίνακες περιέχουν μια κατηγορία κινδύνου, ποιες διαφάνειες αναφέρουν μια πολιτική, ποια έγγραφα έχουν μια προσαρμοσμένη ιδιότητα και ποιοι τύποι εξαρτώνται από μια δεδομένη είσοδο. Στο βασίλειο της κάθε μορφής ξεχωριστά, αυτό γίνεται τέσσερα σενάρια και ένα υπολογιστικό φύλλο με απολογίες. Σε ένα κοινό μοντέλο, γίνεται μια επιφάνεια ερωτημάτων. Ακόμα δουλειά, προφανώς. Το λογισμικό σπάνια σου χαρίζει διακοπές. Αλλά είναι η σωστή δουλειά.
Γιατί η Rust είναι λογική επιλογή για αυτό το χάος
Οι μορφές εγγράφων είναι ένας υπέροχος συνδυασμός δυαδικών δομών, συμπιεσμένων πακέτων, XML, παλαιών κωδικοποιήσεων, φορτίων εικόνων, συστημάτων ημερομηνιών, σημασιολογίας τύπων και ζητημάτων ασφάλειας. Με άλλα λόγια, το είδος δουλειάς όπου η ασαφής ιδιοκτησία μνήμης είναι επιλογή τρόπου ζωής με τιμολόγια. Η Rust είναι λογική βάση επειδή η Bindery πρέπει να κάνει προσεκτική ανάλυση, να διαχειρίζεται buffer, να χειρίζεται σφάλματα με σαφήνεια και να εκθέτει API που δεν αναγκάζουν την υπόλοιπη στοίβα να μαντεύει τι πήγε στραβά.
Τα χαρακτηριστικά του crate λένε την ίδια ιστορία. Τα προεπιλεγμένα χαρακτηριστικά περιλαμβάνουν OLE, OOXML, κρυπτογράφηση OOXML και τον μηχανισμό eval. Η πλήρης υποστήριξη ενεργοποιεί iWork, ODF, RTF, τύπους, μετατροπή εικόνων, γραμματοσειρές και άλλα. Η DocQL είναι ένα χαρακτηριστικό με το δικό της δυαδικό αρχείο. Οι προαιρετικές εξαρτήσεις ευθυγραμμίζονται με τις μορφές και τις επιφάνειες που υποστηρίζουν: διαχείριση ZIP, γρήγορη ανάλυση XML, μετατροπή κωδικοποιήσεων, Snappy, protobuf, αποκωδικοποίηση εικόνων, στατιστικά και μιγαδικοί αριθμοί για εργασία με τύπους, και ούτω καθεξής. Αυτό δεν είναι ένα τεράστιο μπλοκ που προσποιείται ότι κάθε εξάρτηση ανήκει παντού. Τα χαρακτηριστικά διατηρούν ορατό το σχήμα του μηχανισμού εγγράφων.
Αυτό έχει σημασία για την ενσωμάτωση. Ένα σύστημα γνώσης μπορεί να θέλει την πλήρη επιφάνεια γραφείου και ερωτημάτων. Μια μικρή υπηρεσία μπορεί να θέλει μόνο OOXML και εξαγωγή κειμένου. Μια ροή εργασίας Python μπορεί να θέλει δεσμεύσεις πάνω στον ίδιο μηχανισμό. Μια διαδρομή επιθεώρησης γραμμής εντολών μπορεί να είναι χρήσιμη για ερωτήματα και δοκιμές μίας χρήσης. Η σελίδα μιλά για Rust, PyO3 και επιφάνεια CLI· ο πηγαίος κώδικας δείχνει ένα δυαδικό αρχείο DocQL και ένα πακέτο PyO3. Η σημαντική σχεδιαστική επιλογή είναι ότι αυτά τα σημεία εισόδου βασίζονται σε έναν μηχανισμό. Διαφορετικά, κάθε ενσωμάτωση γίνεται η δική της ελαφρώς διαφορετική αλήθεια, και τότε οι αναφορές σφαλμάτων αρχίζουν να φορούν διαφορετικά καπέλα.
Η ιστορία συντήρησης είναι η ιστορία του προϊόντος
Η Bindery περιγράφεται εύκολα ως αναλυτής, αλλά η ιστορία συντήρησης είναι η πραγματική ιστορία του προϊόντος. Κάθε νέα βιβλιοθήκη μορφής που προστίθεται σε μια γραμμή επεξεργασίας έχει τον δικό της ρυθμό κυκλοφορίας, λεξιλόγιο σφαλμάτων, τύπους σφαλμάτων, ιδιαιτερότητες, κίνδυνο εξαρτήσεων, δοκιμαστικά δεδομένα και τρόπους αποτυχίας. Σε μικρή κλίμακα αυτό φαίνεται διαχειρίσιμο. Σε κλίμακα σωμάτων κειμένων γίνεται ένα λειτουργικό αρχειοθήκη που δαγκώνει.
Ένας κοινός μηχανισμός δεν αφαιρεί την πολυπλοκότητα των μορφών. Αυτό θα ήταν ύποπτο. Μεταφέρει την πολυπλοκότητα σε ένα μέρος όπου οι δοκιμές, οι ετικέτες δυνατοτήτων, τα χαρακτηριστικά και τα API μπορούν να διαχειρίζονται μαζί. Το README έχει δοκιμές από άκρο σε άκρο για έγγραφα, παρουσιάσεις, υπολογιστικά φύλλα, iWork και άλλες μορφές. Το δέντρο πηγαίου κώδικα έχει ενότητες που καθιστούν προφανή τα όρια των μορφών. Αυτή η δομή επιτρέπει σε μια ομάδα να βελτιώνει το επίπεδο ανάλυσης χωρίς να ζητά από κάθε ομάδα προϊόντος να ξαναμάθει τη διαφορά μεταξύ ενός relationship part και ενός compound file stream.
Γι' αυτό το Bindery ταιριάζει με την υπόλοιπη στοίβα Dweve. Το Reed ασχολείται με την ανάλυση αποδείξεων. Το BitWeave ασχολείται με την ντετερμινιστική ανάκτηση. Το Fabric και το Spindle ασχολούνται με τη διαχείριση γνώσης και τη λειτουργική χρήση. Το Bindery βρίσκεται πριν από αυτά τα επίπεδα. Μετατρέπει έγγραφα γραφείου σε δομημένο υλικό που μπορεί να επεξεργαστεί η υπόλοιπη στοίβα. Αν το επίπεδο εισόδου είναι κόλλα και ελπίδα, το κατάντη σύστημα κληρονομεί κόλλα και ελπίδα. Πολύ αποδοτικό, αν ο στρατηγικός σας στόχος είναι η μελλοντική ταλαιπωρία.
Τι να ρωτήσετε πριν το υιοθετήσετε
Το πρώτο ερώτημα δεν είναι αν το Bindery υποστηρίζει την αγαπημένη σας επέκταση. Αυτή είναι μια ερώτηση λίστας ελέγχου, και οι λίστες ελέγχου είναι καλές, αλλά δεν αρκούν. Το καλύτερο ερώτημα είναι ποιες υποσχέσεις εγγράφων χρειάζεστε. Χρειάζεστε εξαγωγή μόνο για ανάγνωση, υποστήριξη εγγραφής, διατήρηση πιστότητας κατά τη μετατροπή, αξιολόγηση τύπων, αναζήτηση σε μορφές, μεταδεδομένα, ενσωματωμένες εικόνες, κρυπτογραφημένο OOXML, παλαιό Office, iWork, ODF ή εξαγωγή σε EPUB, LaTeX και Markdown; Αυτές είναι διαφορετικές δουλειές. Το να προσποιείστε ότι είναι μία δουλειά είναι ο τρόπος με τον οποίο οι οδικοί χάρτες γίνονται σούπα.
Το δεύτερο ερώτημα είναι πώς εμφανίζεται η αποτυχία. Αν ένας αναλυτής δεν μπορεί να διατηρήσει μια δομή, το λέει; Αν ένας συγγραφέας κάνει ό,τι καλύτερο μπορεί, είναι αυτό ορατό; Αν ένας τύπος δεν μπορεί να αξιολογηθεί, μπορεί ο καλών να αποφασίσει αν θα μπλοκάρει, θα προειδοποιήσει ή θα συνεχίσει; Μια μηχανή εγγράφων δεν είναι αξιόπιστη επειδή δεν λέει ποτέ όχι. Είναι αξιόπιστη επειδή το όχι της είναι τυποποιημένο, συγκεκριμένο και κοντά στο πρόβλημα.
Το τρίτο ερώτημα είναι πώς δοκιμάζετε το δικό σας αρχείο. Τα δημόσια παραδείγματα είναι χρήσιμα, αλλά το αρχείο σας είναι πιθανώς πιο περίεργο από τον φάκελο παραδειγμάτων. Έχει σπασμένες εξαγωγές, αρχαία πρότυπα, παράξενες μορφές αριθμών, κρυφά φύλλα, αντιγραμμένους πίνακες, κακοσχηματισμένα PDF και αρχεία με όνομα final_final_really_final. Το Bindery παρέχει μια κοινή μηχανή και επιφάνειες που μπορούν να δοκιμαστούν. Χρειάζεστε ακόμα δοκιμές αρχείου. Δυστυχώς, τα έγγραφα δεν θα ενηλικιωθούν από μόνα τους.
Το μάθημα
Το μάθημα του Bindery είναι ότι η επεξεργασία εγγράφων δεν είναι εξαγωγή κειμένου με επιπλέον βήματα. Είναι ανίχνευση μορφής, δομική ανάλυση, όρια δυνατοτήτων, επιφάνειες αναζήτησης, διαδρομές εγγραφής και πειθαρχία συντήρησης. Ο χρήστης βλέπει ένα αρχείο. Το σύστημα βλέπει ένα δοχείο, ροές, σχέσεις, εγγραφές, στυλ, τύπους, μεταδεδομένα, κωδικοποιήσεις και υποσχέσεις εξόδου. Μια καλή μηχανή διατηρεί αυτή την πολυπλοκότητα κάτω από την επιφάνεια του προϊόντος χωρίς να προσποιείται ότι δεν υπάρχει.
Η δουλειά του Bindery είναι να κάνει το επίπεδο εγγράφων βαρετό με την καλή έννοια. Μία μηχανή Rust. Υψηλού επιπέδου API για έγγραφα, παρουσιάσεις και υπολογιστικά φύλλα. Μονάδες μορφής για τα δύσκολα μέρη. Το DocQL για κοινές ερωτήσεις. Ενσωμάτωση Python και στοίβας όπου είναι χρήσιμη. Ετικέτες δυνατοτήτων αντί για μυθολογία μορφών.
Το αρχείο δεν ήταν ποτέ το πρόβλημα. Η κόλλα ήταν. Το Bindery είναι η προσπάθεια να σταματήσετε να πληρώνετε ενοίκιο για αυτό το επίπεδο κόλλας.