An API that you can't implement is useless, so from the beginning of the ZOOM initiative, we have worked with concrete bindings of the abstract API to specific languages. This has enabled us to test the utility of the interface by creating real applications
In general, a language-binding of an API is a non-trivial specification in itself, and is well worth a document of its own. Our goal is to find people to take responsibility for each individual binding. If you feel able to contribute to one or more bindings - either those already being worked on, or brand new bindings - please contact us at <email@example.com>
Of course, even bindings are useless if they're not implemented. In an ideal world, every binding would have multiple implementations, and they would compete for market share based on factors such as price, reliability, efficiency and availability of support, just as, for example, the various web servers - all of which implement standard HTTP - compete for market share,
We would very much like to see more implementations of the ZOOM client model. This will test the robustness of the model and the clarity of the specification as well as providing application programmers with a broader pallette of tools from which to choose. In particular, many of the existing reference implementations are written on top of the YAZ Toolkit from Index Data. We specially welcome implementations written on top of other low-level toolkits such as Crossnet's ZedKit and OCLC's tools.
Here, we offer overviews of the existing ZOOM binding specifications, together with their implementations. Different bindings are at very different levels of maturity, but these nine each have at least one freely available working implementation:
The following languages and environments have been the subject of at least some speculation concerning ZOOM bindings. Some of them are much further advanced than others - for example, the Ada binding is fully specified, and work has begun on an implementations.
We hope that additional bindings will be specified for appropriate languages. There are not many obvious candidates left, but we would particularly welcome a bindings and implementation in your favourite language!
To give a flavour of the existing bindings, there is a ``Hello World'' Zoo containing a simple ZOOM program expressed in a variety of languages.
In an attempt to keep some sense of unity to this sprawling development effort, I'm trying to impose quite a strict version numbering scheme. Here it is.
For example, the first few version of the C++ binding that captures version 1.0 of the abstract API are versions 1.0a, 1.0b, 1.0c, etc.
For example, the first few version of any given implementation of C++ binding version 1.0e are 1.0e1, 1.0e2, 1.0e3, etc. (Yes, this reads like a series of real number. So?)
We hope, of course, that there will be multiple implementations of any given binding. It's perfectly OK for (say) the Manchester University implementation of the C++ binding to be at version 1.0e5 while (say) the Index Data implementation is only at 1.0e3.
This means that every version of every implementation of every binding has a version number packed with juicy information. If it's called (say) 2.7g3, then we know it's:
I hope that's (A) clear, (B) helpful, and (C) not too oppressive.
Note (16th May 2003). Pretty much without exception, every binding specification and implementation seems to have ignored this convention. Oh well - worse things happen at sea.