Reflections about iiRDS
The well renowned German «professional association for technical communication and information», Tekom, released in April 2017 the first public working draft of it's upcoming iiRDS-Specification.
«iiRDS» is an abbreviation of
intelligent information Request and Delivery Standard.
The document starts in it's non-normative introduction with this promise:
«iiRDS (intelligent information Request and Delivery Standard) enables applications to exchange technical documentation across suppliers and devices.»
As I am engaged in the electronic publishing and documentation domain for more than 20 years and as I am now engaged implementing promising new technologies like radio based IoT-systems and blockchains this caught my interest.
That said I dedicated available spare time in the last weeks to dig deeper into this standard. What I was found was a comprehensive and partly bewildered mixture of formalizing concepts.
From my point of view this collection of standardization approaches does not only miss a coherent utilization, in addition if applied with it's full options it even threads some serious aspects of good practice within technical communication which have been established for long.
That said iiRDDS fails to fulfil its promise and makes simple things more complicated than needed.
Anyhow, I decided to share my insights here and I look forward to further discussion and further exploration!
Please note that you find here some German and some English documents mixed.
My findings and assessment
iiRDS enables you to create ZIP-files with files including DITA-Topics, XML, HTML or PDF and to add both metadata as well as additional navigational aids.
iiRDS also offers a specific HTML5 profile to capture content in a way that it can be rendered easily on different devices.
What does iiRDS offer to me, when I already use DITA?
In case you use DITA in conjuntion with HTML and/or PDF output and assuming you have a viable DITA-based metadata concept at stake, this iiRDS approach is not capable of offering additional value at all.
You can add metadata needed using DITA-metadata, HTML-metadata or to PDF-files (using the XMP-standard). You can exchange standardized DITA-content with regard to both maps and topics with ease, too.
iiRDS does not add more options or advantages to add metadata. For example: iiRDS supports the core DITA-topictypes directly. It seems as if has been modeled around DITA-topictypes at this point.
However, assuming that some content management or content deploy systems might offer (?) iiRDS export and import options in the future, you are on the safe side, because it will be possible to export valid DITA-content into the iiRDS-packaging format automatically and with ease.
That said: If you already use DITA you can ignore iiRDS for the time being and ask for system import/export functionality later when needed.
What does iiRDS offer to me, when I do not use DITA (yet)?
In case you do not use DITA, well, you might probably want to use DITA - or stay with your proprietary content and switch to iiRDS.
From that perspective iiRDS enables topic-oriented technical documentation without DITA.
What iiRDS proposes is the option to add metadata to your XML, HTML or PDF-files in a coherent manner. This is in it's core a good idea, however we will see some constraints later.
What is not so understandable: iiRDS even enables you to add navigational aids like Tables of Content or other kind of linking for reuse options in the metadata.
Be aware that the disadvantages of doing so are weighty, because you use a metadata format de facto as authoring standard. This means that you add important information which has to be available at the beginning of the lifecycle at the end of the lifecylce in an additional step.
Eg. you will have to find a way of authoring to generate linked lists directly in a pretty annoying metadata format called RDF to create simple tables of content.
No question that sticking with or switching to DITA is ways easier and more convenient.
Why does iiRDS as metadata format add mechanisms for TOC-creation?
We are told that topic oriented publishing needs metadata and iiRDS to provide the context and allow a user in a certain situation to retrieve the topics she needs:
If we replace the document manual with single-topic delivery, we need metadata that helps create this context and also lets users/applications find, in a large amount of topics, the right topic for a particular usage scenario or user.
What is overlooked by stating this is that serious technical writing, including topic oriented writing, since its inception offered concepts and tools to provide context.
Structured writing, later branded as information mapping, offers since 1998 (when the book mapping hypertext by Robert E. Horn was published) so called
information maps. The idea is to collect and arrange all topics needed for a certain user in a certain situation. The achieve this hierarchy and sort order of typed topics are offered. Information mapping was explicitly designed
Subsequently so called Functional Design aims to prepare and arrange exactly that set of information which is crucial to fulfill a task at hand. It favors the concept of an information product to make sure the appropriate information is provided.
In particular DITA took up the concept of Mr. Horn and provides topics and maps.
If we state now, as the iiRDS standard does:
For retrieving information units dynamically according to the usage scenario and context, we can no longer deliver document-based documentation; we have to deliver a bulk of single topics.
... we ignore and overlook both established concepts of technical documentation and best practice authoring.
From my perspective this is simply wrong. And again, I see no benefit for doing so. Exchangeability and context awareness can both be provided using DITA with elegance.
As footnote it's worth to note that this kind of toc-support is explicitly NOT based on RDS. So this standards use somehow proprietary tools and xxx pretends
Is iiRDS safe?
Anyhow, if we stick with this, we get as technical communicators aware that we lack an important tool, which helps us to provide the information needed and make sure we have all information provided as needed.
By accepting this, we see that beside some trouble at least one important, I am tempted to say, one "damn" duty: We have to make sure that that user in that situation gets every piece of information she needs and/or is aware what is there and what is missing. If we fail to do so, missing information can cause harm and damage. If we fail to do so, we fail as technical communicators.
So, we have to ask: Is there an option in iiRDS to identify an information package, to make sure it's integer, to learn whether it's actual, if it exists in my language? Can I use iiRDS to locate accompanying relevant information packages? Is there an option to test an information package for completeness? Do I have an option to map my individual metadata entry to a predefined standardized value, so that I get forwarded in case I use a deviant notion? Is there an option to create bundles of information packages and to inform clients about related information?
Astonishingly the answer to all these questions is simply: No.
Does iiRDS offer an option to verify the completeness of the metadata-sets?
So iiRDS drops the concept of information maps and information products without providing an alternate mechanism to make sure the appropriate information context can be shaped upfront in a top down manner.
Instead it proposes metadata which shall be searched against a given information need. This bottom up approach will work, if it can be guaranteed, that the fitting and complete metadata set is available and the user and/or end device knows how to search against it.
Whereas iiRDS provides a basic set of metadata it reasonable argues, that sector and company specific metadata sets cannot be harmonized at once. Therefore iiRDS "follows the principle of “describing what there is”" [4.2]. In addition all relations are optional and not enforced by the RDF schema. [4.3.4]
Which standardization body proposes iiRDS and who is on board?
iiRDS is developed by a working group of tekom, the German Association for Technical Communication. The working group started in 2016. Its members are university professors for technical communication as well specialists from CMS vendors, industrial and software companies, and consulting companies.
Does iiRDS use a temporary, agile and lightweight notation?
No. It uses RDF as XML based chatty notation which his hardly accessable for humans.
How about a sample?
To model this modest table of contents:
Table of contents Topic 1 Topic 2
You need this amount of tags:
<iirds:DirectoryNode rdf:about="content/manual.html"> <rdfs:label>Table of Contents</rdfs:label> <iirds:has-first-child> <iirds:DirectoryNode> <iirds:references-information-unit rdf:about="content/topic_1.html"/> <rdfs:label>Topic 1</rdfs:label> <iirds:has-next-sibling> <iirds:DirectoryNode> <iirds:references-information-unit rdf:about="content/topic_2.html"/> </iirds:DirectoryNode> </iirds:has-next-sibling> <iirds:has-next-sibling rdf:resource="http://iirds.tekom.de/iirds#nil"/> </iirds:has-next-sibling> </iirds:DirectoryNode> </iirds:has-first-child>
Whom is this good for?
Technical writers who want to define metadata?
Manufacturers of content management and delivery systems
How aims iiRDS to make content device independent?
no forms, no vector graphics
Why does iiRDS refit already existing solutions?
As we have seen iiRDS adds complicated navigation structures in the metadata context which you can use to create table of contents, an ordinary feature which is available in DITA with DITA maps. It also states to make topic oriented publishing possible, which is already possible using DITA.
It seems as if the inventors of iiRDS do not know or actively ignore DITA.
Unfortunately this impression might even be true. There is a obvious reported aversion of DITA in the German CMS industry.
There may be a valid use case for German non-DITA CMS systems, but vendors are shooting themselves in the foot with factually inaccurate information about DITA as a starting point for their arguments.
Given the facts I found here, iiRDS can even be regarded as a formalized version of this German DITA rejection.
The tekom makes no good role in this context. The resulting iiRDS-concept is not as powerful as it could and should be. The tekom is good advices to drop this hot potato as soon as possible.
What is the main constraint of iiRDS?
The main constraint of iiRDS is it's open- and unlimitedness with regard to metadata in combination with missing mechanisms to narrow down and verify the necessary set.
In addition it adds proprietary constructs (linking, toc-creation) on top of content, instead of providing options
high effort without possibility to check against and to automatize
easier exchange without rds
But for what reason? Sadly this is a simple guess
A. Brief assessment (EN)
display-order als toc problematisch