[NeXus-tech] Summary of last telco

[Campbell, Stuart I.]

Concerning the migration to github - I was planning on looking at it next
week or the week after (we have a mantid release next week so I was hoping
to give to time to it after that)

Cheers
Stu

On 10/22/13 11:40 AM, "Pete Jemian" <prjemian at gmail.com> wrote:

>Very quietly, in the deep background, I'm working on a revision to the
>nxdl.xsd (XSD Schema) that will validate/define the difference between a
>base class and an application definition.  (See definitions ticket #266)
>  The current implementation in the branch is not going to be the final
>since it has a significant problem (comment #14).  Rather, it will be
>necessary to make separate "definition" elements for each case.
>Contributed definitions do not require a third case since they will be
>either a proposed base class or a proposed application definition.  As a
>result, _all_ NXDL specifications will be modified, but with only a
>trivial change.
>
>The only complication in this work is to avoid unnecessary redefinition
>of common components shared by base classes and application definitions.
>  This is a technical detail best left for an uninterrupted few days.
>Which happens rarely.  It will get done.
>
>
>There was talk of moving from subversion to git.  What's the current
>status of that talking?  Is it waiting for ticket #266 to be closed?
>
>Pete
>
>
>
>http://trac.nexusformat.org/definitions/ticket/266
>
>On 10/22/2013 6:56 AM, Mark Koennecke wrote:
>> Hi,
>>
>> I made a little summary of what we were up to on the last telco.
>> To keep us on track. I hope I did not miss something important.
>>
>> Hear you tomorrow,
>>
>>               Mark
>>
>> NeXus Telco Summary, Week 41
>> ==============================
>>
>> Main topic: requirements of MX
>>
>> 1) Coordinate frame (done)
>> 2) SI Units, can be specified in application definition
>> 3) Missing feature: standard way to detail standard error:
>>     Suggestion: append _esd to data name.
>> 4) variants, still open
>> 5) Structure of beam etc. May  be missing fields, easy
>> 6) Rotation axes. This kicked off a discussion on NXgoniometer.
>>     Which is essentially a collection of axes. What was felt missing
>>     was a way to give a field a type. NeXus knows types up to now
>>     only for classes. A type for a field would mean that certain
>>     attributes must be present. For examples for an axes:
>> transformation_type,
>>     vector, offset, depends_on and some.
>>
>>     There was some understanding that this field type should be a
>>     separate attribute, like NX_class.
>>
>>     The idea of an axes class came up and was rejected (temporarily)
>>     for two reasons:
>>     - The transformation_type, vector,... attribute scheme has been
>>       decided upon
>>     - A common criticism of NeXus is that there is to much hierarchy. An
>>      NXaxis group would increase this.
>>
>>     It was felt that this is a bigger thing. To let sink in  a bit and
>>     discuss at the next Telco
>> 7) Detector orientation and such: covered, additional fields may be
>>needed
>> 8) Image masks: covered with the DECTRIS work
>> 9) some more additional fields
>>
>> Other pending issues:
>>
>>
>> NXgoniometer
>> -------------
>>
>> Is ready for suggestiona and voting pending the resolution of the
>> field type axis issue mentioned above. As NXgoniomter is just a
>> collection of axes and a depends_on field and may be some stuff like
>> name etc.
>>
>>
>> Variants
>> ------------
>>
>> Different versions of fields, may be updated after a refinement.
>> We more or less ditched the approaches:
>> - Having an NXsubentry because it requires populating a whole
>>    hierarchy with links
>> - NXvariant group, holding only variants of some fields. Deemed to
>>    complicated
>>
>> The most popular approach appeared to be some form of appending
>> _variant to field names. Or, if there is more then one variant:
>> _variant_somename, _variant_someothername. It is still unclear
>> how this is to be used. IMHO, the latest stance on this was to
>> update the actual value with the best one and store the old one
>> in a variant. There was agreement that time_stamps ought to be added
>> to affected fields and variants.
>>
>> Polarisation
>> -----------------
>>
>> Current polarisation fields in NeXus reflect neutron use cases.
>> Needs enhancement for X-rays. Waiting for an expert to make
>> suggestions.
>>
>> NXaperture
>> -------------
>>
>> Eugen trying to reformulate this.
>>
>>
>> NXslit and NXpinhole
>> -----------------------
>>
>> Check again.
>>
>> FEL
>> --------
>>
>> Herbert argued for two more detector parameters in order to cober the
>> FEL case. This was not principally opposed but Herbert was tasked to
>> provide a little description what this is for. For us to understand
>> what we agree too.
>>
>>
>> Missing
>> ------------
>>
>> I am feeling like I missed something important in this summary.
>> But seem not to remember it. Someone to help out?
>>
>> _______________________________________________
>> NeXus-tech mailing list
>> NeXus-tech at nexusformat.org
>> http://lists.nexusformat.org/mailman/listinfo/nexus-tech
>_______________________________________________
>NeXus-tech mailing list
>NeXus-tech at nexusformat.org
>http://lists.nexusformat.org/mailman/listinfo/nexus-tech