[NeXus-tech] Upcoming NeXus telco

[freddie.akeroyd at stfc.ac.uk]

Hi,

Sorry, I have a meeting clash so cannot make the telco. To answer the question against me:

Nexus fields currently all have a type <xs:complexType name="fieldType">   which is used to validate units attributes etc. if they are present

I believe the question here was whether we could designate a field as being an "axis" type and hence having a different set of required attributes.

If we defined a complex type "axisType" in xsd when we can certainly set up this validation, we then just need to specify that a field in NXDL is "axisType" and not "fieldType"

The easiest way to do this from the xsd schema point of view would be to use something like:

<axis name="whatever">   rather than <field name="whatever">  

in the NXDL to indicate an axis field. Doing

<field type="axis" name="whatever">

is more awkward - it might be possible to check at runtime with nxvalidate/schematron, but when editing the NXDL with an xml aware editior I'm not sure you can change the validation rules based on the content of the type attribute.

Regards,

Freddie 


> -----Original Message-----
> From: nexus-tech-bounces at nexusformat.org [mailto:nexus-tech-
> bounces at nexusformat.org] On Behalf Of Mark Koennecke
> Sent: 23 January 2014 12:45
> To: NeXus Technical sub-committee list
> Subject: [NeXus-tech] Upcoming NeXus telco
> 
> Hi,
> 
> In preparation of the upcoming Telco I send the summary of the last one
> again, as a
> reference.
> 
> Hear you soon,
> 
>         Mark
> ============================
> NeXus Telco Week 51/2013
> ============================
> 
> 
> AXIS Type for Fields
> =======================
> 
> This is about assigning a type to an SDS such that the presence of
> certain attributes can be validated. The use case is the axis type
> which needs to have the transformation_type, vector, offset and
> depends_on attributes.
> 
> We made a little progress here. Freddie is next to sure that the
> presence of
> attributes can easily be checked. He will verify this untill the next
> Telco.
> Herbert suggested to make the field type explicit through a NXclass or
> field_type attribute. Which seems to be a good idea.
> 
> There is also the requirement to verify the depends_on chain. It was
> agreed that this can only be done in code. Herbert has something in
> this direction.
> 
> 
> PX Application Definition
> ===========================
> 
> The rest of the time was spent on discussing the PX application definition.
> The first topic were the pose:NXcollection groups. They deviate from
> the normal NeXus usage. The meaning of them is to contain a list of axes
> to position the component. For PX two are needed: to position the detector
> and to position the sample. There is aggreement that this information
> needs to
> be stored.
> 
> If a NXcollection is the right place to store this information is a
> different matter. There are options:
> - Pull it down into either NXgoniometer, NXsample  or NXdetector. This
> poses
>    the risk of name collisions.
> - We briefly discussed to use NXgoniometer for this. Because
> NXgoniometer is
>    just this: a list of axes and a depends_on field. Herbert objected
>    that crystallographers use the word goniometer exclusively for the
> sample
>    positioner and would be confused by finding a NXgoniometer somewhere
> else.
> - As neither suggestion was satisfactory we briefly discussed creating a
>    new name, perhaps NXaxis_list to cover this use case.
> 
> To be mulled over until the next teleconference.
> 
> Next we went through Tobias list of issues about the PX definition:
> 
> Axis movement during frame acquisition
>     This is about an axis moving while the data for a frame is being
>     collected. Two values are needed: the start and stop value of the
>     movement. Obviously the information belongs at the axis moving. We
>     ended with making this axis two dimensional, [NP,2] with [NP,0]
>     being the start and [NP,1] being the end. Separating this into
>     two fields axis_start[NP], axis_end[NP] was rejected because it
>     breaks the dependency chain.
> Check that arrays are not flipped or rotated
>     This is about storage order of arrays. It was clarified that NeXus has
>     the offset/stride attribute scheme to cover this problem. Graeme is
>     going to verify that this works for him. Also see note below.
> Reconstruct scan intent
>     Was considerend non essential as it can be reconstructed from the
>     arrays stored for a scan.
> Tick of that information required by MOSFLM is present
>     Considered done by Graeme
> Define how NXbeam captures the full wavelength spectrum
>     The problem here is that the base class is fairly fussy about this.
>     We quickly aggreed (at least I think) to have the application
> definition
>     use a spectrum NXdata class which contains data(counts) versus
> wavelength.
>     For FEL this would be two dimensional with NP the first dimension as
>     the spectrum changes with each shot.
> 
> Herbert noted that we are very close to get this done. Good!
> 
> Offset conflict
> ===================
> 
> Something I noted on the Telco but did not mention because I did not
> want to
> open a new topic: we have a conflict about the offset attribute for fields
> in NeXus. There are two meanings:
> - offset is Rank values of offsets to use for each dimension if the data is
>    not in C storage order. Of type NX_INT. This at design#attributes
> - In the discussion on NeXus coordinate systems offset means: 3 float
>    components to describe a translation to be applied before applying
> the operation
>    of the real axis.
> Obviously this must be resolved. Obviously (to me) is that the case for
> the first
> use case of offset is weaker as it will be rarely used. Thus I suggest
> to rename it
> to pixel_offset or array_offset. To be discussed.
> 
> 
> Topics Still Pending
> =======================
> 
> Variants and ESD
> -------------------
> 
> Many people at the Telco liked Pete Jemians idea about specifying the
> names of error fields in an attribute. Concerning variants a mix of the
> different proposals was preferred. Tobias will provide an example
> file with an implementation for us to look at and discuss again.
> 
> 
> NXpinhole and NXslit
> -----------------------
> 
> I think this is ready for voting in the next year.
> 
> 
> Eugens Proposal on Non Standard Fields
> -----------------------------------------
> 
> What to we do with it?
> 
> 
> NeXus Interfaces
> --------------------
> 
> Do we want this? To be discussed later in 2014 when PX is done with.
> 
> 
> 
> I thank everyone for the work put in in 2013 and wish you a Merry Christmas
> and a Happy New Year 2014
> 
> Mark Koennecke
> 
> 
> 
> 
> 
> 
> _______________________________________________
> NeXus-tech mailing list
> NeXus-tech at nexusformat.org
> http://lists.nexusformat.org/mailman/listinfo/nexus-tech
-- 
Scanned by iCritical.