Data Compatibility / Standardization #2
alensiljak
started this conversation in
Ideas
Replies: 2 comments 3 replies
-
BeancountGo through the Beancount documentation to identify reasons for incompatibility and highlight real and potential issue. Notes
|
Beta Was this translation helpful? Give feedback.
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
This is a topic of wider data compatibility between PTA applications and its repercussions for any new application.
Introduction
Even though the promise of Plain-Text Accounting was that "data belongs to you", it falls short of this goal by having every major application out there using its own version of the data.
My personal experience was quite unpleasant - requiring a couple of (calendar) months of shuffling data between GnuCash, Beancount, Ledger, and Hledger using various conversion tools.
Suggestion
Version Header
One concept, used by ABC music notation and Lilypond or a shebang, seems rather attractive. The data file uses a header which contains the syntax version, usually also the version of the application. This clearly identifies which syntax it is and which version.
This information can then be used by parsers and/or converters to know exactly what they are dealing with. The application can accept or reject the data based on compatibility, or migrate it automatically.
Semantic versioning of data files makes machine-handling significantly easier.
The line should be mandatory in order to establish certainty regarding parsing? Or accept the data as the current version?
Explicit value would be safer. The user could be notified if the format is incompatible.
Data/Syntax Standardization
The data standard might be maintained separately to implementations, similar to ABC music notation standard.
This would then be closely related to the #11, which would focus on specific versions of the syntax.
Examples
We could adopt
or
or, generic
Lilypond uses
abc uses
Migrations
Should any of the existing applications converge towards the syntax standardization, having version names/numbers in the header would help in migration.
The migration logic would be built from version to version (i.e. migrator from x1.1 to x1.2, then migrator from x1.2 to x2.0, etc.). Ran in a sequence, anybody could convert their book into the latest common format.
I know this is a big undertaking and a bit optimistic expectation, but why not.
Questions
Beta Was this translation helpful? Give feedback.
All reactions