JSON-LD is the new XML

It's been a pastime of mine to compare XML and JSON, as a mature, expressive and self-descriptive format against one that is ambiguous and unextensible. As many of you should realize by now, this comparison is actually quite meaningless ‒ these two formats have a vastly different focus and primary area of use ‒ XML is focused on documents (apparent for example in situations where formatting may be relevant), while JSON is focused on representing commonly-used structures in programming languages (well, only those in JavaScript) and nothing more and nothing less. There are however usage areas where these two formats overlap, and that is when describing entities or objects of various kinds, linked together using properties. In other words, linked data.

Converting between XML and JSON

There are hundreds of things I could be doing now, so... let's think of a way to convert from JSON to XML and vice-versa!

Why? Because why not? JSON seems to be becoming quite a prevalent format for storing and transmitting data, despite its lack of mature tooling, visualization, comments or extension mechanisms, so it might be advantageous to work with XML which, despite being constructed from JSON, would be reasonably "natural". Let's get started!

Mapping .NET exceptions to XPath Errors

Because why not?

The namespace http://www.w3.org/2005/xqt-errors# (shortened to err:, also described here and here) hosts a number of error codes relevant in the context of XPath functions, XSLT or XQuery. While these errors are usually useful only to XML processors, there is really no reason not to use them when describing errors in general. Imagine you are trying to use RDF to describe the result of a process, or perhaps monitoring a single programming function. The function may fail, end in an exception or otherwise not produce a desired effect, in which case it is useful to be able to use a standardized identification for the cause of the error. Of course the original exception would be more useful to people actually fixing the error, but this should be "language-agnostic", potentially translatable to any different language which uses similar concept of exceptions or errors.

I decided to browse the error codes listed in the namespace, and tried to match them with exception types in .NET. There are not that many of them that align, but the useful ones are still representable. Coupled with properties like err:code, err:description, err:value and err:line-number, these may be useful when describing arbitrary program errors in RDF.

Thought on the Future of Computers

I am going to make a prediction about the future of computing, not in a distant future but more likely what might be in a few decades. It's also not a particularly creative prediction, because the process that might eventually lead to it has already started. Yet it's interesting to imagine, so here it is:

RDF-star and prototypes

Updating the RDF specification to create a new version is not an easy task. While getting new features added in is (relatively) not that hard, the cloud of related specifications, such as SPARQL, SHACL or OWL, is pretty large, and the whole ecosystem of applications and databases made to work with it is even larger. As such, getting new features actually out in the field is definitely not trivial, and some of the issues that may arise as part of that are still apparent today ‒ RDF 1.1 came out in 2014, while the latest version of SPARQL is still from 2013, and as a result, plain literals in SPARQL are still not quite exactly the same as string literals, even though RDF 1.1 doesn't make the distinction anymore.

A different approach is to develop a new version sideways, i.e. create a variant of RDF just with your own favourite new feature. This is similar to how XML is defined, as a set of specifications whereby the core XML specification, to the surprise of many, doesn't actually define anything related to namespaces, xml:lang or datatypes. The folks at RDF did a similar thing and created RDF-star, which is why this flew under my radar for so long.

The Glory of Semi-Structured Data

A not-so-recent trend in information storage has been an increase of use of an interesting blend of structured and unstructured data. Such a style of expressing information is convenient for users, and with the advent of neural networks and prompt-based programming, also manageable for automatic processing.

Delphi form data (TPF0) binary format

Delphi uses a Pascal-like syntax for .dfm files which are meant to store data about forms and various controls, but also other resources and miscellaneous data. These files are compiled to a special binary format and then used to construct and initialize the forms when the application starts.

I wanted to parse these files to retrieve some of the more useful data therefrom, but I wasn't able to find any documentation about the format, so I analyzed it myself and that means you don't have to. What follows is therefore a description of the format and the data model is stores. Some basic knowledge of principles of data storage is expected.