[Nexus-developers] NXconvert-NXtranslate

[Ray Osborn]

On 11/19/03 8:46, "Mark Koennecke" <Mark.Koennecke at psi.ch> wrote:

> Well, yes, you have to learn a scripting language. But you have to learn
> something to use NXtranslate.

For NXtranslate, you need either to know the path to any particular item in
the source file or to have a document of the source library tag names.
That's all.  I think that is the minimum that would be required by any
scheme, so it's not a great overhead.

> I think here is a major point which I missed to make sufficiently
> clear in my first posting. I actually think that scripting is more
> versatile, at the expense of a little overhead for the SEPD case. I
> fail to see how Peters scheme handles the case when we have to compute
> values before we write to a file. This is not negligible, I reckon I
> have to redo distances in +80000 files! Or if you wish to convert to
> our coordinate system. The latter would probably involve calculations
> involving several angles and values from the source file. How
> would this be reasonably expressed in Peter's tag scheme:
>   <distance tag="nexus:/entry1/FOCUS/bank1/distance * -1 "/
>          mime-type="nxtranslate-script">
> or something?? Note that I need some scripting language here as well to
> parse the expression. Or an own expression parser.

You raise some important issues here and in the rest of your message.  Peter
and I did discuss the need for adding some scripting capabilities for the
few cases where the data needed manipulation.  The thing I like about
Peter's scheme is that it allows for external data to be read in, while
leaving the rest of the NeXus file the same.  Peter came up with this scheme
after talking with data acquisition people, who wanted to have a regular
NeXus file containing all the instrumental information, but with a means of
accessing the live data stored in electronic memory.  Mark's scheme doesn't
allow that because it requires every data item to contain a script command,
not just the external data.

It seems to me that there is a possible compromise here, combining the best
of both schemes, i.e., put the script into the tag attribute.  In fact,
Peter's example had a tag that contained SQL commands when the mime_type was
a database, so this is not a significant extension.  The mime_type will
determine whether this is a data path, a keyword, or a script command.  By
putting the script into the "tag" attribute, we leave the contents of any
data tag to the data itself.

I haven't thought through all the consequences of such a scheme, but I am
anxious not to sacrifice simplicity for the cases where greater flexibility
are required.  I believe that it is the job of NeXus utilities to hide
complexity from the average user (like me).  Even with this compromise
scheme, I am worried about the user having to learn a new scripting
interface, with its own set of commands, for every different type of data we
access.  However, I agree that some scripting is useful in more complicated
translations.

Best regards,
Ray 
-- 
Dr Ray Osborn                Tel: +1 (630) 252-9011
Materials Science Division   Fax: +1 (630) 252-7777
Argonne National Laboratory  E-mail: ROsborn at anl.gov
Argonne, IL 60439-4845