The idea of a Reference Implementation (RI)

9 posts / 0 new
Last post

In software technology circles, coming from the days when companies like Sun and Microsoft dominated the world of software systems and enterprise computing, there was a Practice that was taken for granted and it was the expectation that when a new 'technology specification' is introduced such as a JSR (Java Specification Request) or the SVG for example, it was expected that a Reference Implementation would be achieved before anyone took the specification seriously.

When the Servlets specification came out, there was the Tomcat application server which was the Proof of Concept or Reference Implementation for the technology (supplied by Apache). It gave server vendors the green light that the technology is in fact FEASIBLE and they could invest in it by setting up a product development team and giving it a budget. They were confident after using the RI that they weren't chasing shadows and that they could really compete with the technology.

When I first encountered Readium, I presumed it to be the reference implementation for an 'EPUB 3 Reading System' but as I dig deeper and deeper into the literature I find that it isn't quite an EPUB 3 RI. It's more of a hack at WebKit to get EPUB to work in browsers. I have asked on this forum for the interfaces (or "controllers" in the MVC context) that I can probe to ensure that the Readium SDK really is a satisfactory implementation of EPUB 3, but I have received no answer.

Can someone please enlighten me. Is Readium an EPUB 3 RI? Is that concept a reality at IDPF and is it taken seriously? that unless we can point to one implementation which truly implements EPUB 3, it can't be said that EPUB 3 is actually feasible (and therefore a good business investment) in spite of its promise. Reading Systems vendors don't want to waste their time figuring if EPUB 3 is possible. They want to know that it's possible (i.e. by using Readium, the RI presumably) and then compete for market share by outperforming competitors with their own bespoke implementations.

"Reference implementation

In the software development process, a reference implementation (or, less frequently, sample implementation or model implementation) is the standard from which all other implementations and corresponding customizations are derived. An improvement to a reference implementation reflects an unchanging specification. Conversely, a failed attempt at an implementation may prove that the specification is not suitable and needs improvement itself. Testing the implementation-vs.-specification relationship further enhances the production's inter-process efficiencies:

...
Characteristics of a Reference Implementation:

Developed concurrently with the specification and test suite;
Verifies that specification is implementable;
Enables the test suite to be tested;
Serves as a Gold Standard against which other implementations can be measured;
Helps to clarify the intent of the specification in situations where conformance tests are inadequate"

Source: https://en.m.wikipedia.org/wiki/Reference_implementation

There are no complete implementations for (X)HTML, SVG, CSS etc, such programs simply do not exist.
These are formats from W3C - today they become a recommendation due to results from test suits, typically created by the companies contributing to the recommendations as well - therefore recommendations, tests and implementations are not indeoendent and the tests are designed or contributed in a specific way, they test, whether a specifc feature is implementable, there have to at least two correct implementations for each feature, not for each complete format - and lots of issues are missing in the test-suites.
Older recommendations have less tests than newer - and are too optimistic concerning the intentions to implement the format completely.

Because EPUB is based on such formats, one cannot assume, that a correct and complete implementation exists, because it does not exist even for a single format used by EPUB.
This is still a core quality problem of digital formats - no independent test and standards/recommendations, no complete implementations, too often new versions, partly indicating, that earlier versions were not well thought through.
Even worse, parts of EPUB 3 rely on W3C working drafts, not even on recommendations.

Because the core formats, EPUB ist based on, are quite complex, one cannot expect independent implementations. Fortunately EPUB at least requires XHTML (simple XML) and no complex HTML tag soup, therefore there is some chance for new implementors not to rely on the usuals suspects with tag soup interpretation capabilities. SVG is XML as well, but to get the graphical representation right is much more difficult as to get the text presentation right.

O.H. but a reference implementation doesn't have to be perfect, it simply has to be functionally "complete".

Well, but if it is not implemented as recommended - what should be the purpose of such a reference implementation, if the behaviour is not reliable?
And I think for SVG, HTML4, XHTML1.x, HTML5, CSS there are no complete implementations, if we do not consider different behaviour or no activity for a feature as functionally complete ;o)
If wrong or right does not matter, finally no display is some complete interpretation as well ...

As you've correctly suggsted, completeness can be subject to interpretation. The purpose of the RI is to prove feasibility and where showstoppers are found, to remove the error from the specification.

For this, the W3C drafts have these feature tests to check implementations - maybe incomplete and not applicable for older recommendations like SVG 1.1, but now it is required, that some programs have to interpret each test before a draft becomes a recommendation - this seems to be not the case for EPUB.
But we can see problems with this W3C approach as well, there are several CSS3 drafts already in practical use by authors, before they become recommendations, because it can take years until all tests have sufficient implementations. Even EPUB 3 references a few of such drafts ;-) EPUB 3 recommended usage of HTML5 already before it became a W3C recommendation - still now not obvious, what to use in EPUB, because several things have been changed for HTML5 after the first EPUB 3 recommendation - all this does not really fit for formats for information of cultural long term relevance.

The open question: How to specify formats in a reliable way and how to provide reference implementations to ensure that digital information can really survive for a long time, hundreds or even thousands of years as we know it from printed books and even older sources of written text ...

Regarding your question: one way would be to not complicate the process of making a RI with more process (i.e. EPUB in W3C context). The EPUB3 specs are quite clear and stable and the changes to the formats like HTML5 are miniscule and can be handled within the timeframe of an evolving RI.

One simply needs to check that the EPUB3 reference renderer and reader (Readium) supports all the "required" features in EPUB3 (HTML5, SVG, CSS and the metadata documents that make EPUB pages different from ordinary web pages). If at any given time we have about 2% of the features changing, that is acceptable as long as we can say the stable 98% of the features have been found to be "feasible" in the RI.

Well I have some amount of test for EPUB 2.
Best results I got for Lucifox and EPUBreader, both are extensions for Mozilla/Gecko, not for WebKit/Blink as Readium uses.
But anyway, all tested viewers had fatal errors, freezing or crashing.
And this tests mainly EPUB specific features and some basic features of XHTML, SVG and CSS.
Well, maybe newer versions of Readium are already better.
For my own books (EPUB3) I would not use Readium, EPUBreader still works better - and it is not intended for EPUB3 at all, only for EPUB 2.

Secondary menu