[NeXus-tech] [Fwd: Re: dimensions]

[Pete Jemian]

Absolutely, right.  This is where applications tree and definitions tree 
overlap.

The use cases seem clearer now. I will modify the NXDL to match and
also rebuild the nxdl.xsd to describe the structure.  It will be a 
challenge to
put all the rules into XSD.  Some will have to be evaluated by nxvalidate.
That is why the "type" on all of these is NX_CHAR.  It is assumed the XSD
will only have rules for presence/absence of specifications but not the 
content.

The ":" (or "[:]") specification is still a puzzle.  Clarification needed.
Perhaps, one of you modify one of the NXDL instances as an example?
Try this one:  NXbeam.nxdl.xml, field="incident_energy"

In Mark's example, he moves the "value" of a "dim" from content to attribute
<dim>5</dim> is changed to <dim value="5"/>
This is an improvement (no need for closing tag and less likely
to overlook the specification during human inspection of a NXDL) and
does not challenge any XSD rules or common usage.

Can we agree on the nomenclature (oh no, not that again)?  This would 
change Mark's example to
<dimensions size="3">
  <dim index="1" value="25"/>
  <dim index="2" value="np"/>
  <dim index="3" ref="/entry/blablabla/somefield" refindex="0"/>
</dimensions>

Also, "ref" can be either relative or absolute:
    "polar_angle" or "../Qvec" or  "/entry/path/to/follow/to/ref/field"

Perhaps we could even dispense with the "incr" attribute and
combine that specification into the "value" attribute instead? 
One of Freddie's examples below
    <dim index="1" ref="num_time_channels" incr="1"/> 
would be changed to
    <dim index="1" ref="num_time_channels" value="+1"/>

---Pete

Mark Koennecke wrote:
> Hi,
>
> I think the dimensions encoding is tightly integrated with the algorithm we
> use to validate them later on. I thought about something like:
>
> <dimensions size="3">
>   <dim level="0" value="25"/>
>   <dim level="1" value="np"/>
>   <dim level="2" path="/entry/blablabla/somefield" dim="0"/>
> </dimensions>
> The first case is trivial: validate against a number
>
> The general idea is that the dimensions validator would initialise np 
> the first place it comes up against it and
> checks against the value ever after. We must allow expressions like np+1 
> here.
>
> The third syntax is to explicitly address a specific dimension of 
> another variable.
>
> Mark
>  
>
> Akeroyd, FA (Freddie) wrote:
>   
>> Hi,
>>
>> I think we have three cases to consider here:
>> (1) specifying an explicit value for a dimension
>> (2) specifying a dimension to be the same size as that of an array
>> already defined elsewhere (optionally +- a value)
>> (3) specifying a dimension to be the same as a data value defined
>> elsewhere (e.g. num_scan_points, optionally +- a value)
>>
>> For (1) how about
>>
>>             <dim index="1" value="3" />
>>
>> For (2) how about
>>
>>             <field name="data">
>>                 <dimensions size="3">
>> 			<dim index="1" label="num_time_channels"/>
>>                   <!-- dimensions with no constraints or labels do not
>> need to be mentioned -->
>> 		    </dimensions>
>>             </field>
>> 		<field name="time_of_flight">
>>                 <dimensions size="1">
>>                   <dim index="1" ref="num_time_channels" incr="1"/>
>>                 </dimensions>
>>                 ...
>>             </field>
>>
>> For (3) how about
>>
>> 		<field name="num_scan_points" type="NX_INT"
>> label="nscanpt" />
>>             <field name="data">
>>                 <dimensions size="3">
>> 			<dim index="1" label="num_time_channels"/>
>> 			<dim index="3" ref="nscanpt"/>		    
>> 		    </dimensions>
>> 		</field>
>>
>> Notes on dim tag:
>>
>> use 1 for first element in a sequence, +- to indicate sequence direction
>> (or we could use an attribute instead)
>>
>> <dim index="1">   ! refers to first index (fastest varying)
>> <dim index="-1">  ! refers to last index (slowest varying)
>>
>> <dim label="i">   ! we should constrain labels to be unique within the
>> file and thus could be referred to 
>> 			  from any location. This would mean that "i"
>> could not be used everywhere as a label, 
>> 			  but forcing the use of better names like
>> "num_time_channels" makes things clearer. In the 
>> 			  first instance by making label an xs:ID and
>> ref an xs:IDREF we can enforce "something" in
>> label="something" to always be unique and "some_ref" in ref="some_ref"
>> to always point to a 
>> 			  valid "label" (We may later want to use xs:key
>> / xs:keyref to do this if we needed a second
>> 			  set of unique labels for another purpose)
>>
>> Regards,
>>
>> Freddie
>>
>>