The idea of a simple mechanism for overcoming the proliferation of bespoke imports and exports between different survey packages came from Peter Wills of Mercator in a paper at the SGCSA conference at Bristol in 1992. The triple-s standard was developed in response to this need and has steadily become more successful since it was first published nearly 10 years ago. There are now more than 25 software suppliers who support the standard and have provided facilities that allow the user to import or export triple-s files.
But success has its problems: -
The expectation of what survey information should be made available has increased.
The uses of survey data have expanded.
XML arrived as the definition language of choice.
These have lead to development of the standard, producing a number of different versions. It has been difficult to expect all software suppliers to continually keep up with these changes. This has produced the situation where it is no longer necessary to just ask if the package supports triple-s, but now the user needs to know what version. We are in danger of asking the suppliers to replace their proliferation of bespoke data transfer modules with an increasing number of triple-s import/export facilities. As a partial solution we have provided a simple converter that takes a 'classic' triple-s definition and produces the XML format.
A second consequence of the increased use of triple-s is that those suppliers who have not implemented the standard become more of a problem. The pressure of users can be a significant influence in getting suppliers to provide what is in reality a relatively straightforward piece of development. But in some cases the package is no longer being developed, or the supplier provides their own 'open' access to the survey data. In these cases we have welcomed the involvement of a few third-party companies and the support of the ASC in providing triple-s import/export capabilities without requiring any development from the original developers.
But we need to move the triple-s standard on again, in particular the description of hierarchical survey data needs to be addressed. This will inevitably produce yet another version of the standard, and raise the barrier for those who have not implemented triple-s support. As a consequence we feel that the triple-s Group in the future must do more than just produce the triple-s XML definition. At the minimum we can enhance our conversion utility, and will provide test definitions and validation programs to assist developers.
However we see the most important way in which we can reduce the 'versions' problem and make it easier for developers to implement triple-s support is to work on producing an API (Application Program Interface) for triple-s. The objective must be to remove developers from the details of the triple-s XML definition and isolate them from future changes in the standard. We see this as an important step in ensuring the continued success of triple-s, and intend to draw heavily on the experiences of the existing implementers in producing such an API.
| Back to: Top | Programme | Page last updated on 31 August, 2003 |