There are some changes that are relevant only to the system, and some that are relevant only to OpenMath. However, there are still more for which a decision in one (usually OpenMath) necessitates a decision in the other.
A problem, which is more related to OpenMath’s implementation of units is the prefixing problem, which currently uses the IsSimple method in our OpenMathUnit class, but has several hard-coded cases to cover all possibilities.
It has been noted that both OpenMathSimpleType and OpenMathCompoundType are not really used, so could probably be removed.
As was noted, several aspects of the front-end did not pass the usability and accessibility requirements. These should be resolved.
9.6.1 Bug Fixes
There are several problems with the system which mean that it does not successfully convert every conceivable unit.
One is that we currently have no good answer for how to use an FMP which contains an interval, such as calendar year’s 365-366 days. This is explored in section 5.1 of H.
CHAPTER 9. CONCLUSIONS 84 Something that needs considering in OpenMath, but which has quite wide-ranging conse- quences for our system is whether it is correct for a unit name to appear in two different CDs, both to represent the same unit, as with second, or a different unit. This affects how the units are stored and looked up.
9.6.2 Non-essential Improvements
A major issue with the system as it stands is that of its runtime. This might be classed as an essential improvement if the system were to be used in the real world, particularly for multiple users. Because it looks on the Internet every time the converter is run, even though it usually does not download any files, the time taken for this is highly dependent on the internet connection available. This means that the system should be modified to go back to the original design plan, which was to download the files periodically with one program, and then use these local file exclusively in the system itself. This would involve a scheduler looking on the OpenMath website periodically, and the frequency of these checks would need to be decided. It is unclear how often the OpenMath website may be updated with files, as during the course of the project, the unit files were not updated because they were waiting for all the changes as a result of the system being implemented before being uploaded. Once they are there, it might be reasonable to check the website as infrequently as once a week, for example, but this might not be often enough, and therefore there should probably be a control on the user interface to instruct the update program to run immediately. As we have seen, this would only take a matter of seconds. The current problem with the speed means that the system as it stands, although web-based, is too slow to handle multiple users simultaneously. As a very small-scale and unrealistic test of this, we opened 10 copies of the front-end, and ran 10 different conversions simultaneously. Even though these were run on the same system as the back-end, and therefore most of the network activity which would normally be required was eliminated, it took between 5 and 10 seconds for all the results to be returned, which is really too long to be usable. If the system were to be used as a serious converter, it would need a significant redesign in some areas. As previously stated, if the user uploads a CD with a unit that shares the name of another, which unit then gets chosen is difficult to determine. This is exacerbated if multiple users are using the system, uploading CDs and attempting to interact with CDs that they are not even aware of. This leads to two considerations. One is that if a user uploads a file for temporary use, it should only be usable by them; if they want other users to have access to it, they can either provide it themselves for a small number of users, or submit it to the OpenMath community.
There are a whole range of minor improvements, which were not deemed important enough to fix in the time available. One problem we attempted several times to solve was trying to validate the CDs against the CD schema. The problem here seemed to be caused by a problem with the schema, but one or two members of the OpenMath community who were consulted about this did not know what the cause was, and the problem was relegated to the list of further work, because it did not seem sufficiently important to justify spending
CHAPTER 9. CONCLUSIONS 85 a lot of time on it. Another possible set of improvements comes by way of the fact that several of the variables stored in OpenMath can only have a specific set of values, such as status in the CD itself, and the Role in each OMS definition. Our system stores these as strings, but because the set of values is restricted, it would be reasonable for them to be stored as enumerations. This was not changed in the system because neither variable was used by the system, just stored.
An additional speed increase could be achieved during the ConvertToMetric method. As the units are stored in a HashTable, which is not in a logical order, this means that all the prefixed versions have to be attempted before determining which is best. However, it would be more efficient to iterate through the prefixes in order of size and stop when the one with the smallest absolute log has been found.
It would be desirable to have a better mechanism for the user for combining units. The system currently requires the user to spell out laboriously the desired unit, for example “metres per second sqrd”. This is because the only changes made by the front-end are to insert as required. It could be possible for the front-end of the system to recognise operators, and simple calculations, for example “(2+3) miles/hourˆ2” and either pass this to the back-end or pass an equivalent request, having simplified it. Certainly, operators should be allowed instead of “per” and “sqrd”.
At some stage, the log operator should be implemented, to allow ratio conversions to work. This would not be difficult, just mapping the symbol to a C# function. This has not happened so far because no units with logs have been encountered in the system.
Another area of inefficiency is the code to replace OpenMathSymbol objects with OpenMath- Operator objects as appropriate. It came out of an early development that replaced all symbols with units or operators, and therefore it is not very efficient for its current use. It could be rewritten so that every symbol that is read is replaced by an OpenMathOperator as necessary during the loading stage.
It is felt it should be possible for the user to choose how non-metric standard conversions are output—rather than a long string of potentially many units, they should be offered the choice of getting an output comparable to that of the ConvertToMetric method.