skreutzer’s Blog

I’m an implementer, tool builder, technologist; but that shall not preclude me from working on the human system side as well. Sometimes some of our tools will process data that happen to be human expressions. Today, whatever capability the tool might provide and if it is the most amazing ever imaginable, there can’t be any hope of meaningful improvement on the tool or human system side in such cases as copyright law can easily render it completely void. There’s much to write about the damage the print-era copyright law does to the digital world, but even the hypertext community seems to not care at all about the human system side in that respect. It’s no coincidence that we have no other choice than starting from scratch with our poor attempts to build another new hypertext system as most of the earlier work is unavailable, unusable or lost for legal reasons and I’m not aware of a single theoretical work that wasn’t published under the traditional publishing paradigm. Sure, the general availability of digital computers and networks are a fairly new development (we remember a time in our lives where there weren’t any), so the early computer/network pioneers didn’t have to deal with this issue as the technology itself built by them has no inherent recognition or support for copyright law that was designed to regulate the publishing industry. Even with our recent attempts, I have no legal permission to use anything published on jrnl.global except my own stuff. There’s absolutely no point in developing collaborative hypertext capabilities like a shared journal if we lack the most basic human system side policies that make it shared. There’s absolutely no point in curating work if it can disintegrate or disappear at any time. I don’t need the submissions to an institute to hold a monolog. What follows is a practical description of how copyright prevents collaboration.

For my Personal Hypertext Report #6, I made a screenshot that contains portions of Frode Hegland’s “jrnl launch meeting announcement (for Friday 24th of August 2018)” text. As the report primiarly covers actual issues of the existing posts on jrnl.global, it made sense to not only publish/distribute it via my own dedicated machine, but also to submit it to the FTI jrnl under Frode’s control. Sure, such practice is totally stupid because we don’t have a capability yet for both copies to share the same canonical identity, but what else do you do as long as nobody is working on such capabilities yet? So for the screenshot on the jrnl under Frode’s control, there is no legal problem because in the process of submitting, I gave permission to Frode to distribute my contribution to the screenshot, while Frode already has the permission to distribute his own contribution to the screenshot of course. Now, I also want to distribute the screenshot including Frodes contributions to it myself, be it via the dedicated machine(s) under my own control or in print, for which I need Frode’s permission, and that’s not only for me personally. Furthermore, I want to invite my visitors/readers/users to distribute my part of the work as well (for backup/posterity reasons), to create derived works, to distribute the derived works and to use all of that for whatever purpose (the four essential freedoms of libre-licensing). As the screenshot can’t be separated into Frode’s contribution and mine without disintegrating or destroying it, it’s up to Frode to consent or object to my plan of giving everybody blanket legal permission to do their own computing, reception, curation and publishing in freedom, sovereignty and independence as the technology easily enables them to – so I intend to remove the legal prevention and risk as well to realize the full potential of what digital can offer. Therefore, a non-transferable permit limited to me personally wouldn’t do.

I could argue that the screenshot is a new work/interpretation with its own new copyright, it could also be seen as derivative work. If so, I would license it under the GNU Affero General Public License 3 + any later version (without having really investigated what it means for works that aren’t software) and also the Creative Commons Attribution-ShareAlike 4.0 International (despite it doesn’t have a trusted path of upgradability). Why do I pick these two licenses? Simply by looking around which ones are most protective of users rights/freedoms, what features they offer in service to that. These licenses are not perfect, but the best we can do for now without violating the law, as we can’t change it nor afford to ignore it.

To be continued…

I think most of us can easily agree that any structure is better than no structure, and flexible structure(s) is better than just a single, fixed one (would love to explore contrary views on this, otherwise I would assume this as the working hypothesis). There are obviously costs associated with the application of structures on what otherwise is unstructured, context-less, meaningless chaos, but that’s also the only way we know how to gain benefits from what we have or are looking at.

I didn’t think about topics as a structuring tool/mechanism (in terms of a particularly useful structuring tool, which is the whole point of introducing such structure at all, except for natural structures that exist as a matter of fact, but might not be too useful to us as we don’t understand the nature and structure of many things), where categories, taxonomies and keywords/tags are useful structuring tools in my mind, instead, I regarded topics as broad, overarching, general “brackets” that include loosely what might be relevant for a question or problem and exclude everything that doesn’t seem to be related. As the topic tends to be broad and not very specific/formal, aspects and related fields can easily be added or removed from a topic, which makes it a not very useful structuring tool, because the topic is a single structure with a flexible, versatile meaning/interpretation. One day, other, unrelated knowledge/facts/aspects/topics can turn out to be closely related to the topic, and the next day it is found that it was wrong to see a connection between both, that they are in fact unrelated, but just seemed to be related, so those things get removed again. Thus, the topic is more of a snapshot tool for declaring what the human knowledge workers think at the given time of what’s related/included in a topic, to make the distinction to what is unrelated/excluded. It’s much more difficult to deny a piece the annotation/connection to a certain category, taxonomy or keyword/tag, to no small part because they’re used on small pieces/portions where topics cover large collections of pieces, categories, taxonomies, keywords/tags, even if the latter are in conflict with each other, they can still be included into the same generalized topic as different perspectives for looking at what’s relevant with-under the topic. Sure, we know that in reality, “everything is deeply intertwingled” and a problem of immense complexity, so the topic as a structuring tool doesn’t reflect reality, so it is indeed just a tool, so topics face resistance/opposition by people who think that separating disciplines, stereotypes, etc. are a bad thing precisely because they’re tools that don’t reflect reality, but it’s not that they can suggest a more useful alternative (cybernetics exist, but also don’t improve the usefulness that much), but demand that the limited usefulness a topic has needs to be furtherly destructed, maybe because it’s a bad thing and misleading and dangerous to think or look at things on a broad, generalized scope, that it is an illusion that you can.

That’s my current view of what topics are, it’s certainly a different question if/how we can improve topics or improve on topics or improve our or the structuring tools, as well as the question if our current tools/technology (properly or improperly understood and/or applied) are suitable (useful) enough for the increasingly complex problems at hand.

Just to note, before I forget: from computers we’ve learned that an answer to the latter question could be the network/“graph”, Ted Nelsons crusade against hierarchical structures, which topics are despite being flexible, because they’re “on the top” and other things “included/grouped below/within them”.

Addition: Everything is a structure, and if we care enough, we can also make it a topic. I’m not sure if we can reasonably describe something that has no structure, or if things without structure can or do exist, but I’m curious how we could approach such a notion. Consciousness might be something that’s not a structure, and we could discuss if consciousness requires host structure(s), but here we’re back again at the problem that we can’t properly talk about it because the lack of structure makes it hard to prove it’s existence. Not that things that potentially exist or don’t exist can’t exist if we don’t find their structure, but in absence of finding their structure or assigning a structure to them, one can easily claim that they do exist as well as claim that they don’t exist, which may or may not have influence over their real existence, but what’s certain is the fact that we can’t easily talk about it for that particular reason.

To avoid confusion about the “may or may not have influence over their real existence” statement: one can bring things into existence by simply claiming that they exist, or by introducing structure to something that was unstructured before (so it exists in or by or because of the structure), and we can debate if they really exist, but they’re not less or more existent than we are. If they have a consciousness is a different question, but even the possibility that they could have consciousness can’t be easily dismissed for the things we otherwise would be most sure that they don’t exist and aren’t real. A prime example could be a fictional character in a book or movie, is he/she more or less real/existent than, let’s say, “Shakespeare”, or you and me?

By the mere act of talking about consciousness, we certainly made it a topic and gave it (some) structure, but does consciousness itself have a structure, can we even know if it exists? Surely it exists, because of us assigning/identifying a structure of what consciousness is or might be and what it isn’t and probably might not be, so it has at least one structure (ours, as a topic or several topics, at least), so we’re back at wondering if things without structure can exist (again, not in terms of if they actually, really exist or actually/really because of us, or only virtually or any of that, but existence as something we can learn and talk about in opposition to things that may or may not exist, but about which we can’t talk or gain any knowledge about because of the lack of observable structure, including our own made-up structures to talk/think about things that didn’t exist for us before, so we can say that we don’t know about the existence of anything without structure, except unstructuredness itself potentially, if it actually or virtually exists, but that might be the only unstructured thing we can ever talk/learn about).

This text is licensed under the GNU Affero General Public License 3 + any later version and/or under the Creative Commons Attribution-ShareAlike 4.0 International.

Stephan Kreutzer doesn’t want to work on a WordPress enhancement: the current posts on the default installation broke XML processing by a non-browser client because of a named DTD entity and bugs in WordPress’ wpautop() function – both unnecessary problems caused by the general web context, too expensive to fix and difficult to work with.

There’s great consensus that the first project of the FTI, the jrnl, should be a WordPress enhancement project. I’m happy with that as a good practical compromise for bootstrapping ourselves: it’s readily available and many people know how to set it up and/or use it, it’s libre-freely licensed (not ideal though, GPLv2 makes no sense for software that is run over a network, the software should be licensed under the GNU Affero General Public License 3 + any later version, but they probably lack a way to update the license or can’t do that for social reasons), it tends to be an “open”, friendly actor of the open web and it has a usage share of the total of all websites that makes it likely that I encounter such legacy web content I want to work with, I wouldn’t want to lose those entirely. For our group, we need something to capture our discussions, otherwise we would lose some of our own history. Doug Engelbart, at the time he didn’t have the NLS yet, printed his proposals on paper, which is good enough to communicate the idea and get the project going, as these documents can be imported into the very system they describe, but it’s not that we need to wait for the perfect tool in order to allow ourselves to talk about the design of such perfect tool. The conversation about this topic is more important than the costs of doing it wrong. It’s part of bootstrapping really to improve on what’s already around, because if we would re-invent everything starting from digital electronics over networking infrastructure to software architecture and graphical rendering engines, we would never get anywhere in regard to our end goals, so the improvement process must happen from within – adjusting, enhancing, replacing piece by piece for an exponentially enabling overall progress.

What I personally plan to do however won’t contribute much to a WordPress enhancement because WordPress for all its benefits also comes with many problems as it happens to follow the web model. The web wasn’t designed as a hypertext capability infrastructure, but as a document accessing scheme that developed into a fully blown programming framework for online software. It has never been much concerned about the needs of text, which becomes all too apparent for the otherwise perfectly reasonable things it cannot do. Changing that within the web paradigm would be unbelievably expensive for socio-political reasons and the required money/time investment, so I just might play devil’s advocate for client components that aren’t browsers and don’t care much about what servers do for the web by building my own little system that solves the problems I still remain to have when it comes to reading, writing and publishing. That can either lead to wonderful interplay with WordPress enhancements or to great conflicts depending on the technical specifics of implementation and design. In any case, it’s a worthwile research endeavor that promises directly usable results in the larger context, no matter how all the other parts behave, being the independent, potentially non-cooperating entities on the network they are.

The first thing I tried as a simple test was to automatically download the existing posts on jrnl.global with my wordpress_retriever_1 workflow. I encountered two minor issues that were easily solvable by curation without having negative effects on what WordPress generates for the web: In the biography post about Teodora Petkova, there was a single, lone   on the last line, and that broke my XML processing of the post data as retrieved via the JSON API. XML does not come with a lot of DTD entities except those to escape its own special characters and therefore is unaware of HTML’s legacy DTD entity declarations. They’re usually not really needed because characters should just be encoded in the file with the encoding clearly stated in the XML declaration or processing instruction. I agree that it might be sometimes favorable to explicitly use escaping for special characters, especially the non-printable ones that can be hard to read and write in standard text editors, but then XML supports the encoding of Unicode characters in the form of   (hexadecimal). My parsers generally still lack the ability to translate these Unicode escape codes to the actual character (with the additional difficulty to never break encoding through the entire processing pipeline), but that needs to be added anyway eventually, with the XML tools probably already being fine. The old HTML entities for encoding special characters is really a legacy remnant of DTDs, and while DTD declarations at the beginning of HTML file might arguably help with identifying the HTML version (especially a huge problem with “versionless”, “living” and therefore bad HTML5), they also cause a lot of trouble for processing XHTML with a XML processor (which is just great, but was abandoned by the web and browser people for questionable reasons): DTDs can include other DTDs, each of which can theoretically contain entity declarations, so an generic, vocabulary-agnostic, XHTML-unaware XML processor needs to load/read all involved DTDs in order to find out how entities need to be replaced for text output, which entity names are defined and which aren’t (the latter will cause the processor to fail). Now, the DTDs define the HTML vocabulary or specialized format based on the generic XML format convention, which is published as a standard by the W3C and needs an unique identifier to be disambiguated from other standards and versions, otherwise the whole vocabulary would be ambiguous and of no help for processors to interpret its meaning correctly. So if the W3C needs an identifier, ideally globally unique (which implies a central name registry), what do you think they would use, especially back in the day? An URL of course! Act two: imagine you write a generic XML parser library and you encounter a DTD declaration, while your library is also going to parse DTDs and allow DTD validation (for proper, but separate HTML support) eventually, and lack the time or knowledge to do a particular good job with the first release of the implementation? It might even be legal constraints as the DTD files by the W3C have some almost non-free restrictions or the question why a generic XML parser library should come with W3C DTDs if some users will never parse any XHTML ever – what happens a lot of times, as the unique identifier looks like and is an URL and the referenced, needed DTDs are not locally available, these parsers send out HTTP GET requests for the initial DTD, which then references several other DTDs internally, and then sometimes the received results (if any) might not get saved (because why would you and how, for small, ad-hoc, generic XML parsers?). There are probably plenty of web crawlers and bots and client implementations that try to obtain a resource from the web and then read it in for further processing with a normal XML tool, and in a distributed network, this causes quite some excessive traffic for the W3C server. So what did the W3C do in response? They throttle so serve the response of course! So imagine yourself, being an unsuspecting user of such an XML library, trying to parse in some nice XHTML, just to observe that your program execution stalls. Is it a bug, an endless loop? You might enter a debugging session but can’t find out a lot. Lucky you if you go to get you a coffee eventually while leaving the parser running instead of giving up the plan entirely, to be surprised when coming back that miraculously the XHTML input somehow did get parsed. That’s likely because the artificial delay at the W3C server has expired – to then serve the requested DTD(s)! To treat the identifier as resolvable instead of an abstract one is the root cause of this problem, delivering the DTDs encourages such behavior, and additionally, the delay might lead to the impression that XHTML/XML parsing is very, very slow. But what else can you do? Not serving the DTDs would leave HTML entities unresolvable and the XML would fail to parse. If parsers/processors don’t have the DTDs and can’t get them, all of XHTML would be unreadable, which would be a grim option for the whole XML/XHTML/semantic effort. But can XHTML demand special handling from all generic XML parsers out there? Of course not, the whole point of XHTML is to make it universally available just as all the other XML vocabularies. Therefore, still having the DTD declaration and named entities in XHTML for backward compatibility with crappy HTML4 while not advancing to XHTML2 (HTML5 removed the DTD and with that, XHTML5 doesn’t have one either, but as rubbish HTML5/XHTML5 is the one without version as a “living standard” indistinguishable from a potentially upcoming HTML6/XHTML6 except for heuristic analysis, a HTML5 DTD would have been better than no version indication at all) is a historical tragedy that renders even the best, well-formed, valid portions of the web hard to use for some of our machinery, completely unnecessarily. For my tools, I install a catalog of the DTDs that I included in the download, so all DTD identifiers can be resolved to the local copy, but that’s not an option for my own primitive StAX parser in C++ or its sloppy JavaScript port (deliberate lack of XML tools in browsers is unbelievably ironic and a big loss of potential). XML parsers of the big programming frameworks usually also have a DTD parser on board and just need the W3C DTDs from somewhere, ideally delivered as a local resource with me resolving the ID to the local file in the catalog. These catalogs could be adjusted to not resolve to the actual W3C DTD for mere parsing (we’re not doing DTD validation here, do we?), but to a pseudo DTD that contains nothing than the named entity declarations and omit all references to any of the other DTDs. For the custom, small StAX parser, I think I’ll add a mechanism that instructs the parser to first read a XML file that lists named entity names and their intended textual replacement, so it can continue with the real input file and recognize all entities that were configured this way in advance. And all of this needs to happen in preparation to handle a single   that hasn’t have any effect to the visual appearance anyway. Pragmatically, I just removed it from the blog post for now, I think it won’t be missed.

Something else broke the parsing of the jrnl launch meeting announcement (for Friday 24th of August 2018) post: welcome to the wpautop() function of WordPress! “autop” stands for “auto paragraph” and replaces two consecutive line breaks with XHTML <p> tags. In the process, for XML/XHTML well-formedness as the very minimum of standard compliance, it has to find the beginning of the previous paragraph and the end of the paragraph that follows. It also must respect other encapsulating tags as tags are in hierarchical structure and aren’t allowed to overlap. For some reason, autop is notoriously error-prone. Have a look at the issue tracker: there’s #103, #488, #2259, #2691, #2813, #2833, #3007, #3362, #3621, #3669, #3833, #3935, #4857, #7511, #9744, #14674, #27350, #27733, #28763, #33466, #33834, #38656, #39377, #40135, #40603, #42748, #43387. The fact that regex is involved explains part of this mess. WordPress recognizes that plain text linebreaks are considered harmful when they’re typed to convey semantic meaning, and as the application is managing output for the web in (X)HTML, whitespace like linebreaks doesn’t encode meaning, it usually gets entirely ignored in the visual rendering and instead formats the source code for better readability. If the plain text editor of WordPress is used, autop should not be applied onto the text whatsoever because it can be expected that the user will directly input XHTML. The visual editor should create a a new <p>-pair with the cursor right within it – any subsequent enter key press in an empty paragraph should have no effect (but then people will start to enter spaces into the empty paragraphs to force their way to vertical spacing for layout/typesetting, so a whitespace check needs to be performed). An actual plain text editor variant should XML-escape all angle brackets as mixing different formats and encodings is always a bad idea. Here we’re already losing WordPress as a decent writing and publishing tool, that’s with the out-of-the-box default configuration and no plugins or themes installed yet to interfere with the content even more. The divs with the ApplePlainTextBody class seem to be of other origin, also being pretty useless as the CSS class doesn’t seem to exist and doesn’t help as a mechanism to derive semantic meaning. There’s even an empty one of those divs, so I just removed all of them and that also caused autop to not fail for what otherwise was perfectly valid XHTML.

“Enhancement” can mean different things, “WordPress enhancement” means using WordPress as the basis for the enhancement, but then “WordPress” can be looked at from different perspectives. The web perspective isn’t one I personally consider much because I precisely want to get rid of the limitations that are associated with it, plus it would be too expensive for me to invest into fixing all the problems that exist with the current implementations/paradigm against the resistance of those who are in actively favor of them or simply don’t care.

This text is licensed under the GNU Affero General Public License 3 + any later version and/or under the Creative Commons Attribution-ShareAlike 4.0 International.

Frode Hegland published a draft “A Theoretical Model for Knowledge Work & Symbol Manipulation (4 Aug)”. Here are some initial responses.

Text isn’t necessarily about knowledge, just think about prose for entertainment. Text can be written in an attempt to trigger emotions, which is hardly an expression of “knowledge”, except in the broadest possible sense which would make everything “knowledge” after all, so it might help to define the term “knowledge” that’s used to define the term “text”.

It’s not true that writing or authoring necessarily needs to result in linear text or the resulting text to be frozen. It only must be linear because the printed book is linear, but if the tools wouldn’t be crappy, one could as well write non-linear texts, with writing on/for the web or e-mails sometimes turning out to be something in between. The text is “frozen” if writing on it stops, but that doesn’t mean that it can’t start again at any time. The act of publication “freezes” the text in a sense, because traditionally, as soon as another individual obtains a copy, that copy tend to not get updated, therefore needs to be considered as frozen. But what happens if there is an update path? How do we think about a text being frozen by being published, but another version based on the text is published every day? Can we call it “frozen” if the so-called “reader” (the one who obtained a copy) starts to change his copy? So to really freeze a text, it needs to be printed onto paper or into a certain book edition (we freeze it by making it non-digital), or to put it in a version control system, or fix a publication with a timestamp at the Internet Archive, the latter two only making it canonical because people can still obtain copies, change them and publish the result as well.

There might be many “hypertext communities”, but claiming that “wider access addressability” is solely relying on web URLs or that the file name has anything to do with the format or encoding or that the “addressability” is only implemented by fragment identifiers and corresponding anchors in HTML web documents, is far from hypertexty systems and therefore don’t find consensus as a reasonable approach.

This text is licensed under the GNU Affero General Public License 3 + any later version and/or under the Creative Commons Attribution-ShareAlike 4.0 International.

The Future of Text Institute already lists a series of projects that happen to be of interest. I’ll try to align my activities towards these where it makes sense. I agree that the first step should focus on retrieval and reading, because we can fake authoring for quite some time and the WordPress editor is already available as a writing interface, but reading is reading, so there’s no way around consuming what we produce, otherwise it would simply remain unknown. If the Institute wouldn’t encourage decentralized blogging right from the start, a centralized Journal would make it much easier to bootstrap in the traditional way with authoring tools as the first step and a central place to learn about published material, but this isn’t a big issue, it can be done either way.

The Journal project proposal heavily relies on WordPress and RSS, which are both nice in some ways, but come with a bag of problems of their own. RSS exists to optimize the retrieval of the newest resources, which might not be very helpful for navigating interconnected text. WordPress is a pretty decent server package, but it’s primarily geared for browser consumption, which isn’t very helpful and can cause serious conflicts. I also want to point out that we already failed one earlier time to implement a HyperGlossary with WordPress (or did we succeed individually, just not collectively?), maybe due to social reasons and not technical ones. Have a look at Frode Hegland’s implementation (proposal, example, interaction) and mine (proposal, example, interaction). Now, in the context of the FTI, it’s obvious that we do not necessarily need to come up with a single approach on how to implement a glossary capability, but it demonstrates how WordPress and the web can get into the way of making it work.

There are more problems with the project proposals: using some commercial offers can be OK depending on the circumstances, owning the system and providing it as a commercial offer are not the same, who knows if propaganda and fake news are useful categories to think about, ViewSpecs not only need to be text operations but could also be specifications for graphical display/rendering, PDF should not even be mentioned for anything other than printing regardless of whatever attempts Adobe comes up with to make it “interactive” or “rich”, it’s not true that citing and high-resolution linking in e-publications isn’t possible because of commercial barriers (these are proprietary, restrictive barriers that can be present even at gratis or theoretically libre-licensed publications), the claim that there is a need to start an open addressing scheme for proprietary publications (they deliberately don’t want to be cited or linked, so just leave them alone and respect their wish to stay irrelevant!), the limited use of “open sourcing” an application that is trapped on a proprietary host ecosystem (algorithms, artwork, other parts might be useful to the libre-free software world, but then again, “open sourcing” something for the wrong reasons might lead to disappointment). Still, there’s no need to arrive at full agreement within the FTI on every point listed here, and it needs to be reiterated that many of those proposals are in their first draft, so we’ll probably discuss them in much more detail and certainly invite further comments as well.

The “Links in Images” capability is very easy to do as I tried to indicate in my brief HyperCard investigation, even in native programming I can’t imagine it being too hard. At the same time, it’s probably by far not the most important feature for bootstrapping systems that primarily deal with text.

The Journal project may or may not be influenced by the recent analysis of the ARC Journal files from SRI, or only by the earlier published material or account of Doug himself, in any case: it’s an open question to what extend the FTI should try to replicate the ARC Journal in modern technology, and where it should take liberty to expand, limit or adjust the example of this earlier system. I abandoned the idea as it became clear in the Doug@50 group that I would be alone in replicating the Journal capability, and while it is still very useful for a single individual to have it, there are significant differences in how to go about it if it is for personal use or to be used by a group. The latter would greatly benefit from bootstrapping, which you can’t do just on your own. So I went back to basic capabilities, but a Journal for the FTI would equally make sense as the first step. I already built a few components that could help with this task: a primitive StAX implementation for programming languages that don’t come with one (C++, JavaScript) for properly reading RSS, an EDL-based generic retrieval mechanism, a WordPress retriever and a WordPress uploader, all of which would require more work or re-work for this project, but what major obstacle would prevent us from just building a first prototype and then bootstrap from there? A few capabilities/components are still missing, for example local storage management, federation of sources and a dispatcher based on semantics to invoke a basic ViewSpec mechanism. Other approaches might even be more viable of course, this is just an early offer/suggestion.

For the FTI Journal, I plan to publish my “journal entries” in some form (be it a WordPress instance as it is now or raw resources) under my skreutzer.de domain to make it clear that those are personal opinions, not official statements by the FTI (if there can be such), and hypertext-systems.org might provide federation services beyond my own material, but also not necessarily identical to the official structuring of the FTI corpus, over which I don’t have any control nor need any in a decent federation.

This text is licensed under the GNU Affero General Public License 3 + any later version and/or under the Creative Commons Attribution-ShareAlike 4.0 International.

After several months, I finally reached the chapter in “Introducing JavaFX 8 Programming” by Herbert Schildt that addresses the TextArea of the JavaFX GUI library, keyboard and mouse input events already having been covered. With this, on a productive weekend, I guess I can come up with another prototype of the Change Tracking Text Editor, making it the third attempt. In parallel, I realized that it would be helpful for the previous other two failed attempts to make a graphical “Change Instructions Navigator”, so it becomes a whole lot easier to reconstruct the individual versions and hunt down the spots where the recording actually goes wrong. I doubt that this will be key to finding the solution, for example by revealing a programming error occurring in a rare constellation, if the problem is related to timing, but it might help to arrive a clearer understanding what the issue is, and the tool will be useful in general as the change instructions recordings need to be replayed and navigated in a granular, selective way, not only reconstructing the last version as the change_instructions_executor_1 does. It’s clear that the capability to reconstruct every single version (not only on instruction sequence level, but additionally for every individual character event) should be made available to headless workflows in terminal mode, be made programmable for automatization, but the navigator as a GUI component has the objective to hold state for the session and ensure that the version navigation is performed fast, so it might be too expensive to call a stateless workflow that has to reconstruct all versions from the beginning up to the desired one, so the navigator belongs already more along the lines of an integrated change tracking text editor environment.

During the last few updates of Trisquel 8.0, one of the 100% libre-free GNU/Linux distros and therefore my reference system, I must have obtained an update to the Nashorn engine (available via the jjs command if you have Java installed), which is pretty late in comparison to the rest of the world, but that’s the time it takes to legally clear and package it for the distro. Java and it’s GUI components contain browser controls of course, and such need to come equipped with JavaScript nowadays, so it makes sense to implement the JavaScript interpreter as a generic component to be shared and maintained only once instead of multiple times, and this interpreter eventually can be made available to all of Java without the need of having a browser control around. I had an earlier version present already, but with the update, ECMAScript 6 became available now where previously the attempt to use it resulted in an exception, so only ECMAScript 5 was available. Why I need ES6? Because it introduces the let keyword that allows me to evade the treacherous variable hoisting of JavaScript, which had cost me quite some debugging time while implementing the HyperGlossary prototype, so I never want to work with any JavaScript below ES6 again. Now, with the call jjs --language=es6, you’re set to go.

What this promises: a world in which JavaScript components can be written once and then be executed traditionally in the browser, on the server with node.js and on the client as a native app (not dependent on a server, not limited by the CORS nonsense etc.). To make this a reality, environment-specific calls need to be abstracted away behind a platform-independent interface standard, because JJS does not have the DOM or window object, node.js doesn’t have alert() and so on, and especially where the DOM is (ab)used to build a user interface, Java GUI libraries should be called analogously in JJS. For every execution target, the right implementation would be packaged, but the target-independent JavaScript components could run on all of them without change, so they only need to be maintained once, allowing for code reuse because the wheel doesn’t need to be reinvented for the three target execution environments. As one can assume that people will have Java installed on their computers (for LibreOffice), the need to install a separate bridge from JavaScript to the local operating system wouldn’t be needed any more, as it traditionally was the case all the years before.

The downsides of this concept are that the interface standard doesn’t exist yet, we would have to design it, which is less a problem for headless workflows in terminal mode, but could reveal unresolvable conflicts when it comes to GUI applications. Furthermore, it was announced that Nashorn will be replaced by something else, which shouldn’t matter that much as the interfaces should stay the same. More worrying is the indication that the OpenJDK team finds it hard to maintain Nashorn as JavaScript continues to change all the time (it’s a hell of a language), and asked the project to abandon it again. GraalVM might come to the rescue, but it can take ages until such developments become available on my end as reliable infrastructure that doesn’t go away soon and therefore can be built upon. The risk of discontinuation means that investing into JavaScript components might turn out to be a dead end, repeating the fate of the HyperScope project, just as browser people like to screw everybody else up and not do the right thing. For this reason, only small scale experimentation around this is on my agenda, not doing anything serious with the web/browser stack in the forseeable future, despite I really would like to. So I’ll have to stay with native development, not benefitting from the decent rendering capabilities of the browser, but what else are you gonna do, there aren’t other options really.

As I completed reading Matthew Kirschenbaum’s “Track Changes”, I need to add the key findings to the blog article as soon as time permits.

I also wonder if I should try to translate as much English articles into German as possible, so they can serve as an invitation to the topic of hypertext to a German speaking audience. Sure, we’re the land of printing, but I don’t see why this should limit the interest in hypertext, to the contrary.

Writing reports like this slows down technical work quite significantly, but I hope it helps to get discussions on the various topics going while offering a chance to align my activities with what’s generally needed (in terms of priorities and avoiding duplicate work), eventually piling up to a body of material on which the new capabilities and methodologies can be used on.

Some countries have restrictions on what one can call an institute. In Germany, there are no general limitations, but as institutes may be departments of a university or as independent entities join cooperations with universities, courts have ruled several times that other organizations that wanted to create the impression that they’re somehow associated with an university in order to appear scientific and neutral are not allowed to call themselves an institute. Does the FTI need to be “scientific” at all, be it to be allowed to keep “Institute” in the name or because of the kind of work it is planned to be engaged in? If the name needs to change later just to avoid legal trouble, I guess I would have to change my use of it in this articles. For some time however, we might need to follow the convention that published material can never change, so if we end up in this dilemma, we might be forced to do some heavy lifting to introduce upgradability.

This text is licensed under the GNU Affero General Public License 3 + any later version and/or under the Creative Commons Attribution-ShareAlike 4.0 International.

On the 2018-07-24, I saw an announcement by Frode Hegland that he had recently founded the “Future of Text Institute”, which I “joined” subsequently. Since I got more interested in hypertext, I was unable to find somebody else who wants to collaborate on text-oriented projects despite a lot of people claim to feel the need that something should be done for text, maybe because such demands seem to be fashionable these days. Of the few who are actually active in the field, most are busy following their own, largely incompatible approach as I do too. On the other hand, there’s no way I can figure it out all by myself and with only a few hours of spare time at my disposal, it wouldn’t be very wise to come up with a big, monolithic design.

The Future of Text Institute offers the chance to be developed into a loose federation of text enthusiasts, housing a collection of diverse tools, projects and resources that aim to cover each and every activity one potentially might want to perform with text. Parts of it could slowly converge on the level of compatibility towards a more coherent system or framework, so they don’t exist in isolation but can be used together in more powerful ways. Other efforts like the Doug@50 demo, the Federated Wiki by Ward Cunningham, the Text Engine by Francesc Hervada-Sala, not to mention the myriad of earlier system designs, are subject of study as well as candidates for cooperation. In this capacity, the Institute supports small and big initiatives that don’t fit into what’s already around.

This text is licensed under the GNU Affero General Public License 3 + any later version and/or under the Creative Commons Attribution-ShareAlike 4.0 International.