Peterson, Peter F.
petersonpf at ornl.gov
Wed Dec 3 22:07:44 GMT 2003
Thank you for your examples, they are very helpful in determining the correct solution to the problem. I agree that programmatic control does belong on the list of requirements (simple, flexible, extensible, straightforward, small, starting format independent, portable, and programmatic control). However, looping over a set of files should be done outside the actual translation program by a shell script.
What we desire is actually three functions (that could exist separate, in a coherent front-end, or as a single program):
combine - Bring information from various sources, in a variety of formats, into a single napi file.
translate - Change the structure of one napi file.
convert - Transform data in a NeXus file in place. Examples of this are converting int to float, changing relative distances to absolute distances, and converting 100*nano*second to micro*second. For all of these some of the attributes, like type and units, will need to be automatically changed.
[Note: I call files that conform with the standard "NeXus" while ones that are nonconforming and can be read with the api as "napi"]
Due to my own biases I prefer to try to implement these as three separate codes that rely on a common library for some of the shared functionality. A pretty GUI could be put on top to ease the user through generating the "translation"-type files for each step and run them.
The other option, what we have been discussing so far, is to put this into a single program (the GUI could still be a separate code that generates the translation file) and use a single syntax for the translation file. This does not seem like the way to go since the symantic requirements of the three functions are fairly different.
Your idea of a program which takes the translation file(s) and generates c-code from it is good, but could take a long time to develop/debug.
From: nexus-developers-bounces at anl.gov on behalf of Mark Koennecke
Sent: Wed 12/3/2003 4:26 AM
To: nexus-developers at anl.gov
Subject: Re: [Nexus-developers] NXtranslate
In short if I do not have some form of programmatic control, I will have
to write an own conversion utility. Sorry. So, I would add generality
and programmatic control to the requirements list.
Possible solutions to this dilemma include:
- embedded code in the XML file alike Java Server Pages or ASP
- Perhaps Jelly, an XML scripting language, can be a solution. See:
Unfortunately jelly is java only these days.
- Enhance the XML-DTD with programming constructs and use it as a
template from which NXtranslate generates a suitable C program
which can then be compiled and linked. This would also guarantee
the most efficient translation programs.
More information about the NeXus-developers