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

[Akeroyd, FA (Freddie)]

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. 

Regards,

Freddie

> -----Original Message-----
> From: nexus-tech-bounces at nexusformat.org [mailto:nexus-tech-
> bounces at nexusformat.org] On Behalf Of Pete Jemian
> Sent: 21 February 2009 13:54
> To: NeXus Technical sub-committee list
> Subject: Re: [NeXus-tech] [Fwd: Re: dimensions]
> 
> 
> 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
> >>
> >>
> 
> _______________________________________________
> NeXus-tech mailing list
> NeXus-tech at nexusformat.org
> http://lists.nexusformat.org/mailman/listinfo/nexus-tech
-- 
Scanned by iCritical.