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

[Joachim Wuttke]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4916 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.nexusformat.org/pipermail/nexus-committee/attachments/20140716/9ee3edc6/attachment.p7s>