<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi,<br>
<br>
everyone has now voted on the NXpositioner class. The results of the
vote are :<br>
<br>
FOR = 10 / 15 = 67%<br>
<br>
AGAINST = 3 / 15 = 20%<br>
<br>
ABSTAIN = 2 / 15 = 13%<br>
<br>
This means that the NXpositioner class has been been ACCEPTED with two
thirds majority.<br>
<br>
At the end of this email are some of the comments made during the vote.
I find them instructive and would like to see them taken into account
in the future to improve the NXpositioner class.<br>
<br>
Best regards<br>
<br>
Andy<br>
<br>
comment 1 :<br>
<br>
<p><font face="sans-serif"><i>I vote against on the basis of the way
units are treated. If the units were moved to be on each of the fields
I would be for since this passes<br>
the "looks like NXlog" test.</i></font></p>
<br>
comment 2 :<br>
<br>
<p><font face="sans-serif"><i>I would like to see /raw_units and
/controller_record removed.</i></font></p>
<p><font face="sans-serif"><i>/raw_units are redundant without a
/raw_units_value & /conversion_factor. </i></font></p>
<p><font face="sans-serif"><i>/controller_record is also redundant.</i></font></p>
<p><font face="sans-serif"><i>These field look to me like instrument
'debug' fields.</i></font></p>
<p><font face="sans-serif"><i>Responsibility for correct conversion
goes to the control system. NeXus is a data format. Is is not a
container to debug/verify a control system. I therefore agree with Mark
K's comments in the discussion that we are putting hardware fields into
the data which we decided as a committee not to do.</i></font></p>
<p><font face="sans-serif"><i>If we had inheritance, we could have
debug fields, optional fields and facility specific extensions etc.</i></font></p>
comment 3 :<br>
<br>
<p><i><font face="sans-serif">I see the purpose of a generic positioner
/ motor, in<br>
particular where it is impractical to define a class<br>
which reflects the physical meaning for each component.<br>
I actually think we <span class="moz-txt-underscore"><span
class="moz-txt-tag">_</span>need<span class="moz-txt-tag">_</span></span>
more general classes because<br>
we just can't imagine each possible component which will<br>
be invented and dedicate a class to it.<br>
On the other hand, the NXpositioner is too limited for<br>
many cases (eg the hexapods which seem to be fashionable<br>
these days). I was musing about building on NXgeometries...<br>
So I'm undecided between the "simple but works" and the<br>
"elegant concept" approaches and therefore resort to<br>
ABSTAIN.</font></i></p>
<br>
<br>
<br>
</body>
</html>