[NeXus-definitions-tickets] [NeXusDefinitions] #32: dimensions in NXDL
NeXus Base Classes and Instrument Definitions
noreply at nexusformat.org
Sat Nov 27 18:59:03 GMT 2010
#32: dimensions in NXDL
------------------------+---------------------------------------------------
Reporter: Pete Jemian | Owner: Pete Jemian
Type: task | Status: assigned
Priority: major | Milestone: release NXDL 1.0
Keywords: |
------------------------+---------------------------------------------------
Comment(by Pete Jemian):
There are some comments from 2009-02 in the {{{nxdl.xsd}}} file that
belong here instead.
{{{
On 02/20/2009 04:15 AM, 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)
}}}
{{{
On 02/20/2009 10:20 AM, 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.
}}}
{{{
On 02/21/2009 07:54 AM, Pete Jemian wrote:
>
> 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"/>
one more thing: Can we make the "index" attribute optional when
it is obvious? See this case from NXtranslation:
<dimensions><!--[numobj,3]-->
<dim value="numobj"/>
<dim value="3"/>
</dimensions>
</field>
This also treats the "size" attribute as optional. Otherwise:
<dimensions size="2"><!--[numobj,3]-->
<dim index="1" value="numobj"/>
<dim index="2" value="3"/>
</dimensions>
</field>
}}}
{{{
On 02/22/2009 05:27 PM, Akeroyd, FA (Freddie) wrote:
> We need to draw a balance between what is easiest for a user to type and
> what provides us with the best validation and error checking.
>
> In the case of using e.g.<value="npoints"> everywhere and initialising
> it at first reference, this is easy for somebody to use but if they were
> to type<value="npoint"> somewhere in a definition by mistake this would
> not be picked up and just create a second variable "npoint" without the
> intended constraint. In a "one label + many ref" model typing
> <label="npoints"> and<ref="npoint"> would be trapped by the nxdl
schema
> editor as a reference to a non-specified label. Thus I think there is
> useful gain in keeping "value" for just for pure numbers and not use it
> for variables.
>
> I wonder whether we need to provide a reference to an explicit path e.g.
> ref="/entry/blablabla/somefield" in the dimensions syntax ... the same
> can be accomplished by creating a label/ref pair. I believe forcing the
> definition of a variable for all linked dimensions makes the definition
> intentions clearer.
>
> [:] in the meta-DTD syntax just indicated a one dimensional array of
> unspecified length...it would be the same as writing [i] in a file if
> there were no other instances of [i] for it to match up to.
}}}
--
Ticket URL: <http://trac.nexusformat.org/definitions/ticket/32#comment:11>
NeXus Base Classes and Instrument Definitions <http://www.nexusformat.org/>
NeXus Base Classes and Instrument Definitions
More information about the NeXus-definitions-tickets
mailing list