[Nexus-developers] NeXus Reference Manual, Classes

[Pete Jemian]

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