[Nexus-developers] NeXus Reference Manual, Classes

Mark Koennecke Mark.Koennecke at psi.ch
Wed Feb 2 10:01:15 GMT 2011


Pete,

Pete Jemian wrote:
>
> Mark:
>
> Now I can see clearly what nxdlformat.tcl does.  Had to run it on Linux.
Ahhhhhh, yes!  I once more forgot about the great OS divide......:-)
>
> Also, I can see why it won't run on NXdata.  Needs an application or 
> contributed definition.  AND, that NXDL has to have a surrounding 
> NXentry group.  (I don't see where this last requirement is in the 
> NXDL rules yet, by the way.  It will need to be added.  I see how it 
> clarifies how application defs overlay the standard NXentry or 
> NXsubentry.)  The nxdlformat.tcl code should also allow NXsubentry, in 
> place of NXentry.
>
This is correct, NXsubentry ought to be supported.
> I suggest doing the whole thing in XSLT instead.  It can be even more 
> useful.  Do you know how to write that?
>
Nope, I had to whip up something quickly in order to have a reasonable 
representation to show on the
upcoming PanData meeting in Paris. This is why I choose a technology I 
was fast and familiar with. XLST, I would
need to learn. Also, on a first glance, XLST seems to be good at text  
replacement but  difficult if you need 
logic. And I like logic when programming. And I may be terribly mistaken 
about the capabilities of XLST.

In another matter I am not tied to documenting the application 
definitions as a a tree. I just do not like nested
tables, I find that confusing. Another option would be to have a single 
table but with field names containing full
path strings, like /entry:NXentry/sample:NXsample/rotation_angle.

Mark
> Pete
>
>
> On 2/1/2011 8:59 PM, Pete Jemian wrote:
>>
>> Mark:
>>
>> nxdlformat.tcl shows a condensed version of the structure of groups and
>> fields in application and contributed definitions. The rendering
>> produced by nxdlformat.tcl simplifies the understanding of NXDL
>> specifications. It does not render any of the attributes or
>> documentation content.
>>
>> It is not easy to decide how to add the documentation from NXDL files to
>> the output of nxdlformat.tcl. Rendering of the attributes could be
>> easily added nxdlformat.tcl.
>>
>> nxdlformat.tcl uses Tcl and the additional tdom package, both of which
>> are not currently required to build the NeXus manual.
>>
>> It seems the entire function of nxdlformat.tcl could be re-engineered in
>> XSLT (call it nxdlformat.xsl), thus removing the need to add another
>> language requirement to the construction of the manual.
>>
>> As an added benefit with nxdlformat.xsl, we could add a line near the
>> top of each NXDL file referencing nxdlformat.xsl as the default
>> stylesheet. With this addition, any NXDL file, when opened in any common
>> WWW browser, would be rendered in the "nxdlformat" style. This is pure
>> sugar.
>>
>> Either the nxdlformat.tcl or an XSLT transform based on nxdlformat.xsl
>> could be built into the construction of the manual. But neither can
>> replace the tables currently shown in the manual since they provide the
>> detailed documentation about each item.
>>
>> Pete
>>
>>
>> On 2/1/2011 8:48 AM, Mark Koennecke wrote:
>>> Hi,
>>>
>>> attacking ticket #174 I had a good look at the NeXus classes section in
>>> the reference manual.
>>> Most of this is autogenerated. The section on the NeXus base classes is
>>> OK. I have some
>>> issues with the application definition section:
>>> - NXfillin has to go. It is indeed only a template and just confuses
>>> people.
>>> - I find the presentation of the application definitions in tables as
>>> suboptimal. I would
>>> rather have this replaced by the output from nxdlformat. How does
>>> everyone else feel?
>>> Pete, how difficult will it be to run nxdlformat before inclusion into
>>> the manual?
>>>
>>> I am also pondering if we should not do a first step towards OO-NeXus
>>> for beamline
>>> components. This by introducing a common base class in which we keep
>>> things like
>>> rotation_angle, polar_angle, distance, geometry:NXgeometry etc. which
>>> can occur in anything which happens to be in the beamline. Any 
>>> opinions?
>>>
>>>
>>> Best Regards,
>>>
>>> Mark
>>>
>>>
>>>
>>> _______________________________________________
>>> NeXus-developers mailing list
>>> NeXus-developers at nexusformat.org
>>> http://lists.nexusformat.org/mailman/listinfo/nexus-developers



More information about the NeXus-developers mailing list