change_instructions_navigator

<ul> <li style="text-align:justify;">Change tracking on the character level, which leads to full undo/redo/playback, historical diff instead of heuristical guessing, amazing branching and merging of variants and servers that only accept modifications to a text as a series of change operations, that might be submitted in full, cleaned up or only the effective, optimized changes.</li> <li style="text-align:justify;">EDL-based text format convention. No need to decide on a particular format in advance as all formats can be easily combined ad-hoc. Text doesn’t end up burried in a particular format that doesn’t support features needed at some later point or can’t be extended except by violating the spec. It also allows overlapping, non-hierarchical structure. Similar to EDLs, xFiles, ZigZag, NOSQL.</li> <li style="text-align:justify;">Abstracting retrieval mechanism powered by connectors. Doesn’t matter if a resource is local or remote, by which technique it needs to be retrieved, great for linking and could get rid of 404s entirely.</li> <li style="text-align:justify;">Reading aids. Track what has been read and organize the consumption for both the incoming suggestions as well as the sharable progress. It’ll also prevent the user from reading the same text twice, help to split reading duties among members of a group, to categorize and indicate updates.</li> <li style="text-align:justify;">Technical bootstrapping on the information encoding level. Instead of heuristical file type guessing, metadata explicitly declares the encoding and format, so if a corresponding application/tool is registered for the type, it can be invoked automatically, as well as automatic conversions between encountered source format and required target format.</li> <li style="text-align:justify;">ViewSpecs. Markup specifies a general meaning/semantic/type, so ViewSpecs to be applied onto it. The user is in control of the ViewSpecs that can be adjusted, shared or come with a package pre-defined. Same goes for EditSpecs.</li> <li style="text-align:justify;">Distributed federation of material. Fork content by others, change it for yourself or publish your branch for others to fork it further or merge. This doesn’t require the original source to cooperate with any of it, but it’s certainly an invitation to do so. Intended to work on every level of granularity, from large raw data blobs to the smallest bits of insertion, deletion or annotation, up to every property of configuration or metadata declaration, each of which might contribute to the composition of a rendering/view.</li> <li style="text-align:justify;">More to come…</li> </ul> Those capabilities work together and thus form a hypertext environment. It almost certainly requires a capability infrastructure/architecture that standardizes the particular functions and formats, so (different) implementations can be registered to be invoked manually or data-driven. It might be slow, it might be ugly, but I’m convinced that it’ll open entirely new ways for the knowledge worker to interact with text, realizing the full potential of what text on the computer can do and be. This text is licensed under the <a href="https://www.gnu.org/licenses/agpl-3.0.html">GNU Affero General Public License 3 + any later version</a> and/or under the <a href="https://creativecommons.org/licenses/by-sa/4.0/legalcode">Creative Commons Attribution-ShareAlike 4.0 International</a>. See also the <a href="https://skreutzer.de/htx/de_skreutzer_20180719T232906Z_incomplete_list_of_desired_hypertext_system_capabilities.xml">revisions</a> (<a href="https://skreutzer.de/htx/de_skreutzer_20180719T232906Z_incomplete_list_of_desired_hypertext_system_capabilities.xhtml">rendered</a>) of this text.