Design decision for epidata analysis - missing and restricted words
This mail is technical in nature, if you are not interested in technical aspects, just delete the mail.
The issue of how to read ,., in a comma separated file is now solved and can be tested in v 1.1, rel 7. build 68 - which is the latest on the web site.
One other issue which someone might want to comment on is the use of restricted words. We know that the use of the words e.g.: date year month weeknum and other common terms which can also be functions gives a problem.
It would be helpful if users will comment on strategies to handle this. The current implementation is NOT to worry about this. In some programmes there is a list of illegal terms.
Should we : a. Adopt a strategy, where users are warned when creating files where field names/variables are given the same names as a restricted word - a warning.
b. Maintain current where users will find out since either an error or occur or nothing happens when they create confusion in this way - a "non-friendly" way towards users.
c. A strategy where field names cannot have the same names as functions. - a restrictive strategy.
In future similar questions as this I will attempt to add "Design decision" .... in the subject line, such that users on the list not wishing to get this type of mail can add to a filter.
To check which version a particular build of EpiData Analysis has issue the command: . version Current version: 1.1 Release 7 (Build 68) If you are on internet the programme will also look up on the website the latest public release, e.g.: Latest public release 1.1 Release 1 (Build 62) Report problems and suggestions to <the EpiData list> Development versions are located on the <EpiData testing page>
Where the text in < ......> are hyperlinks, such that if you click on them your standard browser will open on those pages.
regards Jens Lauritsen
I vote for strategy a) to display a warning - this seems most user friendly and can reduce the problem well. Bests Max On 20 Mar 2006, at 7:34, epidata-list@lists.umanitoba.ca wrote:
This mail is technical in nature, if you are not interested in technical aspects, just delete the mail.
The issue of how to read ,., in a comma separated file is now solved and can be tested in v 1.1, rel 7. build 68 - which is the latest on the web site.
One other issue which someone might want to comment on is the use of restricted words. We know that the use of the words e.g.: date year month weeknum and other common terms which can also be functions gives a problem.
It would be helpful if users will comment on strategies to handle this. The current implementation is NOT to worry about this. In some programmes there is a list of illegal terms.
Should we : a. Adopt a strategy, where users are warned when creating files where field names/variables are given the same names as a restricted word - a warning.
b. Maintain current where users will find out since either an error or occur or nothing happens when they create confusion in this way - a "non-friendly" way towards users.
c. A strategy where field names cannot have the same names as functions. - a restrictive strategy.
In future similar questions as this I will attempt to add "Design decision" .... in the subject line, such that users on the list not wishing to get this type of mail can add to a filter.
To check which version a particular build of EpiData Analysis has issue the command: . version Current version: 1.1 Release 7 (Build 68) If you are on internet the programme will also look up on the website the latest public release, e.g.: Latest public release 1.1 Release 1 (Build 62) Report problems and suggestions to <the EpiData list> Development versions are located on the <EpiData testing page>
Where the text in < ......> are hyperlinks, such that if you click on them your standard browser will open on those pages.
regards Jens Lauritsen
EpiData-list mailing list EpiData-list@lists.umanitoba.ca http://lists.umanitoba.ca/mailman/listinfo/epidata-list
participants (1)
-
epidata-list＠lists.umanitoba.ca