[Nexus] NeXus version

Fri Jan 23 13:58:21 GMT 2015

Hi Tobias,

I've overlooked that application definitions have their own version numbers.
Ah, so NeXus format is defined by application definitions and base
classes are only helpers.
Indeed, in that context the NeXus_version attribute does not make sense.

Thanks for explanations.

Bests,
Jan

On 01/23/2015 02:11 PM, Tobias Richter wrote:
> Hi Jan,
> 
> The individual application definitions have their own version numbers. At the moment those are the only elements that provide you with guaranteed content in the file. In a way for base classes there is no difference between backward compatible versions for the consumer, because added optional content may or may not be present.
> 
> No known software supports all features of NeXus, so a “3.1.0” compliant reader is not a thing. That may never be the case, given the diversity of the fields of neutron, muons and photons. Maybe there was less confusion, if we didn’t have a definitions repository release number? 
> 
> Tobias
> 
> 
>> On 23 Jan 2015, at 13:01, Jan Kotanski <jan.kotanski at desy.de> wrote:
>>
>> Hi,
>>
>> From my point of view new changes (even backward compatible) should be
>> also labeled by version numbers. Otherwise,
>>
>> 1) developer who writes NeXus readers supporting v3.1 (released 3 years
>> ago) does not know if he/she should include the newest NeXus definitions
>> or should stick to what is given by the v3.1.0 tag.
>>
>> 2) users who use "NeXus Reader supporting NeXus v3.1" should know if
>> this reader is able to read newer definitions or not.
>>
>> Therefore, from time to time I would suggest to release a new version of
>> NeXus definitions, also for base classes.
>>
>> Bests,
>> Jan
>>
>> On 01/23/2015 11:50 AM, Koennecke Mark (PSI) wrote:
>>> Hi,
>>>
>>> the situation is as such:
>>>
>>> * The NAPI and the NeXus definitions are on separate versioning schemes
>>> * At the time when this was decided we were at 3.1 Thus the definitions release was tagged as 3.1
>>> * NAPI moved on to 4.3.1 in the meantime. Though it may not make much sense to add a NAPI release tag when you are writing
>>>  the file with the HDF-5 API alone. Something for the NIAC to sort out eventually.
>>>
>>> When we put the definitions on a separate release tag the idea was that we would make incompatible changes to the definitions in some stage.
>>> Then versioning would come in handy. This never happened, we just added to the definitions. This is why there has been  no new definitions
>>> release for quite a while.
>>>
>>> Sorry about the confusion. But it is the way it is now.
>>>
>>> Regards,
>>>
>>>     Mark Koennecke
>>>
>>>
>>> Am 23.01.2015 um 11:05 schrieb V. Armando Solé <sole at esrf.fr<mailto:sole at esrf.fr>>:
>>>
>>> Hi,
>>>
>>> If you are not talking about application definitions, please ignore this mail.
>>>
>>> In the case of application definitions, I would not expect them to match with the API version. A program may support several versions of an application definition but it may be able to write one of version them. In addition, it may not use the NeXus API at all.
>>>
>>> Best regards,
>>>
>>> Armando
>>>
>>> On 23/01/2015 11:00, Wintersberger, Eugen wrote:
>>>
>>> Hi folks
>>> I just had a look in the manual. According to the reference manual the
>>> NeXus_version attribute, attached to the root node of the file, should
>>> be the API version used when writing the file (that's why I set it to
>>> 4.3 in my own code).
>>>
>>> This is most probably not the best choice for this attribute. It should
>>> rather refer to the current version of the Nexus definitions. I am not
>>> sure yet if the API and definitions version was coupled until now.
>>> Since we see many people using their own code to write Nexus files it is
>>> most probably more important to know which definition they follow rather
>>> than which API version they have used.
>>>
>>> @Pete: how are definition versions encoded in the XML (sorry for my
>>> limited knowledge of XML - am working on this)?
>>>
>>> regards
>>> Eugen
>>>
>>>
>>> On Fri, 2015-01-23 at 09:56 +0100, Jan Kotanski wrote:
>>>
>>>
>>> Hi Tobias,
>>>
>>> Thanks for your email.
>>>
>>> Usually, when someone creates an NXroot group he/she adds its
>>> NeXus_version attribute. Should it be 3.1.0 or something else.
>>>
>>> E.g. using Eugen's pni-libraries I get automatically
>>>
>>> NeXus_version = 4.3.0
>>>
>>> Is this version number is somewhere encoded in the “definitions” repository?
>>>
>>> NeXus_version could be helpful for NeXus readers.
>>>
>>>
>>>
>>> Bests,
>>> Jan
>>>
>>> On 01/23/2015 09:34 AM, Tobias Richter wrote:
>>>
>>>
>>> Hi Jan,
>>>
>>> I agree that the release situation requires some improvements. At least could do with a roadmap or so.
>>>
>>> Just to confirm: We are talking about the “definitions” repository, were we hold the manual and XML schema that define the standard (as opposed to the “code” that holds the API). Right?
>>>
>>> To my knowledge there hasn’t been another formal release of that since 3.1.0. And there hasn’t been one before. Maybe some day someone will explain to me why that was released as 3.1.0. I do not know.
>>>
>>> Since then we’ve been on a rolling release, if you like. Until very recently all changes since the release, tried to be backward compatible. In December we’ve deprecated NXgeometry. So it was difficult to make the call on how many small changes or additions here or there warrant a new release. I tend to just consult the manual for the latest version and for me that works well. Opinions from the community was the expectations would be are welcome.
>>>
>>> Does that help?
>>>
>>> Tobias
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 23 Jan 2015, at 09:01, Jan Kotanski <jan.kotanski at desy.de><mailto:jan.kotanski at desy.de> wrote:
>>>
>>> Hi,
>>>
>>> I've just been searching for the current NeXus version number in the
>>> nexusformat repo and I could find only a tag denoted by v3.1.0.
>>>
>>> But I suppose this is not the last version. Where can I find it and why
>>> I cannot find it on www.nexusformat.org<http://www.nexusformat.org/>? (It should be easily visible).
>>> In my opinion it would be good to have in the repo tags/branches
>>> corresponding to version numbers.
>>>
>>> Bests,
>>> Jan
>>>
>>> _______________________________________________
>>> NeXus mailing list
>>> NeXus at nexusformat.org<mailto:NeXus at nexusformat.org>
>>> http://lists.nexusformat.org/mailman/listinfo/nexus
>>>
>>>
>>>
>>> _______________________________________________
>>> NeXus mailing list
>>> NeXus at nexusformat.org<mailto:NeXus at nexusformat.org>
>>> http://lists.nexusformat.org/mailman/listinfo/nexus
>>>
>>>
>>>
>>> _______________________________________________
>>> NeXus mailing list
>>> NeXus at nexusformat.org<mailto:NeXus at nexusformat.org>
>>> http://lists.nexusformat.org/mailman/listinfo/nexus
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> NeXus mailing list
>>> NeXus at nexusformat.org<mailto:NeXus at nexusformat.org>
>>> http://lists.nexusformat.org/mailman/listinfo/nexus
>>>
>>>
>>> _______________________________________________
>>> NeXus mailing list
>>> NeXus at nexusformat.org<mailto:NeXus at nexusformat.org>
>>> http://lists.nexusformat.org/mailman/listinfo/nexus
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> NeXus mailing list
>>> NeXus at nexusformat.org
>>> http://lists.nexusformat.org/mailman/listinfo/nexus
>>>
>>
>> _______________________________________________
>> NeXus mailing list
>> NeXus at nexusformat.org
>> http://lists.nexusformat.org/mailman/listinfo/nexus
> 
> 
> _______________________________________________
> NeXus mailing list
> NeXus at nexusformat.org
> http://lists.nexusformat.org/mailman/listinfo/nexus
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
URL: <http://lists.nexusformat.org/pipermail/nexus/attachments/20150123/ef25e803/attachment-0001.sig>