[NeXus-committee] obsolescence and evolution: NeXus needs a historic dimension

Herbert J. Bernstein yayahjb at gmail.com
Wed Jul 16 12:37:32 BST 2014


Good point.  The model of programming languages such as Fortran or C
is a good one.  We had Fortran 77, Fortran 90, Fortran 95, etc.   C
compilers know about and support compliance with C89 and higher
variants.   This is more useful to the community than simply having
feature-by-feature versions, such as NXmx 1.0, 1.1, etc.  So, might it
not be useful
to target some fully documented overall version of NeXus to become,
say, NeXus 2015 that
the community can use and rely on as a true standard, and then say
that _all_ revisions after that will be considered as possibilities
for inclusion in, say, NeXus 2020.

If we can learn to cope with such an approach, we might consider
forming a formal ISO standards committee with an eye towards the
creation of a formal ISO NeXus standard.
While the formality involves a lot of time, effort and resources, it
does provide a very
real service for the community.

Regards,
    Herbert

On Wed, Jul 16, 2014 at 6:29 AM, Joachim Wuttke <j.wuttke at fz-juelich.de> wrote:
> Dear all,
>
> Tobias just reminded us about historic ballast in NeXus. Besides
> XML and HDF4, there are several other aspects of NeXus that can
> only be understood from history. At the same time, parts of NeXus
> keep changing and growing, and new abstraction layers are being
> proposed. As a result, NeXus becomes ever more complex.
>
> From recent correspondence I learned that to this date not a single
> institute is writing fully valid NeXus. I suspect this highly
> unsatisfactory state of affairs is not the least due to NeXus being
> a moving target.
>
> Compliance with "the NeXus standard" is a meaningless aim, and will
> never ensure interoperability, unless precisely located on a timeline:
> what we should aim at is that a data set can be said to be compliant
> with NeXus versions from <..> to <..>.
>
> I would suggest to learn from other projects how to manage life
> cycles and how to add a historic dimension to a specification.
> As an example, programming languages come to mind. How could
> Fortran survive for more than 60 years? By being renewed every
> ten years or so, and occasionally in radical ways, with features
> having their own life cycles via "deprecated" to "obsolete". Why
> was compatibility intentionally broken between Python2 and Python3?
> For "fixing well-known annoyances and warts, and removing a lot
> of old cruft". Is this enough to justify the annoyance caused
> by a compatibility break? In the long run, yes: to keep things
> manageable, you have to be tough with burdens of the past.
>
> Are there any such plans for NeXus? Leaving aside the question of
> manpower and institutional support, has time come to start thinking
> about a compatibility breaking next major version?
>
> Best regards, Joachim
>
>
> _______________________________________________
> NeXus-committee mailing list
> NeXus-committee at nexusformat.org
> http://lists.nexusformat.org/mailman/listinfo/nexus-committee
>


More information about the NeXus-committee mailing list