Dear All
An important achievement on the current development path for EpiData Software has been achieved. On the test page a new build of the EpiData Core test module has been placed for the Mac OSx. Within the next week or so a Mac with PowerPC processor should arrive finalising the current operating system support plans.
The conversion from windows/linux to Mac went very smooth and this is a final indication that the decision last year to rewrite core modules by using the open-source pascal compiler FreePascal - and the programming tool Lazarus (IDE) was a good choice.
Users are highly encouraged to test the following: a. How does the Core module perform on different operation systems (linux/linux64/windows variants/Mac). b. Import and Export any or all of the supported data formats. - guessing raw text and delimited files (csv, txt etc) - dbase III - Stata - from version 5-10 +11 - EpiData rec+chk files
In particular in relation to dates, string fields, real, integer problems. The test version is available from: http://www.epidata.dk/testing.php
Following the test work will now progress with implementation of translation principles and extension of more data formats . The plan is to add handling of spreadsheet formats - as expected the proprietary black box data formats of M$ used in excel sheets are not documented, but some indirect ways of including this is possible. More news on this later.
---------------------- Further notes on current development (technical):
The real challenge in the conversion obviously comes later when dataentry and analysis functions are implemented on top of the core module, but is reassuring to see that the core module can actually work on different systems. But I wish that all aspects of this are taken into account before continuing the current modules.
Work has been done to see whether a new EpiData format should be implemented. The problem is that when shifting from strict Ascii format of characters to UTF-8 and support of several Operating Systems some technical problems demands clarification.
Possible solutions are: 1. A new fixed format taking care of the varied length aspects of UTF-8 2. A completely new variable length EpiData data format 3. Application of an open xml based standard - e.g. the Data Archive format (DDI-3.0) see: http://www.icpsr.umich.edu/DDI/ 4. Use of another software format, e.g. Stata10 (but this would not solve the multi language character problem)
Experimentation has been done with SAS transport format, but this is not feasible since parts of this are insufficiently documented. A solution will come up and further information given to the list before doing so.
regards
Jens Lauritsen EpiData Association