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.

The Models of CONCURrent SGML

Nowadays, the old glory of SGML is almost forgotten as it got replaced by XML in all but a handful locations, but the language itself still has some very impressive capabilities that, I dare say, might yet make it a viable option for some very specific cases in the future. One of those features is "CONCUR", a.k.a. the original namespaces. This comparison is inaccurate of course, so I will first take a few paragraphs to describe what this feature is, and how it relates to the whole SGML ecosystem.

Identifiers for some file formats

I managed to find a gold mine when it comes to URIs and identifiers: the DocBook notations module. DocBook is an older SGML/XML-based standard developed by OASIS used for writing documentations, and with its DTD comes a module that “imports” several then-common notations for use with unparsed entities.

XML Lite (definitely not XML 2.0)

Years after the conception of XML, it had been customary for programmers to point out its perceived flaws and suggest fixes to the language. This trend has somewhat declined in recent years, as developers have either learnt to live with XML, or discovered that they can use something else.

I do not share these feelings towards XML. In many cases, I find it suitable for various purposes, and I think many cases of criticism stemmed from misunderstanding. Yet even I would like to add some features to the language, based on my experience. Let's take a look at them.

Dynamic Self-contained Infinite XML

Imagine a window showing some sort of a feed. There are multiple panels displaying various messages as they arrive, plus some boxes that show statuses of other things, or the time, for example. This is a complex system usually thought of as calls to different APIs, various types of messages, presentation layer etc. What if I told you however that such a feat could be done even with only standardized formats, no client-side scripting and a single XML document and HTTP request?

A completely meaningless comparison of XML and JSON

I have never had anything against XML. Despite its many quirks and burdens, I think it is even nowadays a perfectly reasonable format for providing or accepting structured data, and I think it is meaningless (albeit trendy) to compare it with JSON trying to determine whichever is better. It is obvious those two languages were designed for different purposes, and the real virtue in data engineering (or software engineering in general) is to know and use the proper tools for completing a task.

In that regard, no language should come out as the winner in this comparison, but it should give you an idea when to use one or the other.