Other non-Alice/LORRI-specific issues found during merge conflict resolution

[cgobat]

Let's use this issue to discuss and track the other "Unresolved" items from Anne's spreadsheet, besides the 2 already mentioned in #25.

Location	@acraugh identified issue	@cgobat response/comment
<detector_name> definition	Values "Linear Etalon Imaging Spectral Array", "Long-Range Reconnaissance Imager", "Radio Science Experiment", "Student Dust Counter", "Solar Wind Around Pluto", and Ultraviolet Imaging Spectrograph" do not follow established value formation conventions, name the instrument rather than the detector, and describe the instrument rather than the detector.	What formation conventions do these not follow? The attribute definition is "The nh:detector_name provides the identifier of the detector that recorded the observation(s) comprising the product. For instruments with multiple detectors, as in the case of MVIC, for example, this string will include both the instrument ID and the specific detector ID." How else should the detectors of instruments with only one detector be identified, other than by the instrument they belong to?
<leisa_rate>	This attribute is described as a "rate" but has units of time, not rate.	This is not a mistake. Note that it is actually not described as a rate, but as a time, which is consistent with its <unit_of_measure_type>
<leisa_rate>	This attribute has a unit of measure and a specified minimum, but no <specified_units_id>.	I think 0 means the same thing for all of the possible Units_of_Time (i.e., 0 sec ≡ 0 min ≡ 0 hr ≡ 0 days etc.), but I can pick one and add it if need be.
<pointing_method>	The description indicates this attribute has a permissible value list, but none is defined. Worse, it describes in plain text and encoding format that might be used, making this field programmatically non-actionable.	This one is tricky due to the fact that it cannot be reasonably captured in an enumerated list of permissible values. As stated in the attribute definition: "Alternatively, this value can take the form 'RADEC=[X],[Y]' (where [X] and [Y] represent a numeric right ascension and declination in degrees, respectively) to indicate inertial pointing." Since (as far as I know) DD_Permissible_Value can only have a value (not a pattern), the best I could do was to implement the entire thing as a RegEx pattern instead of a permissible value list. The definitions are provided in the definition field because I'm not aware of anywhere else to put them (though I am open to ideas if anyone has them). I disagree that this makes the field programmatically non-actionable.
<scan_type>	This attribute description is specific to MVIC, but the new permissible value references LEISA. It is not clear how LEISA framing mode differs from the existing definition of framing mode.	The current definition is: "The nh:scan_type attribute indicates what sort of scanning was employed in collecting the data." I don't see how anything there is MVIC-specific... LEISA doesn't have multiple different scan types like MVIC does, so its one mode is most easily identified simply as "LEISA"—the scan type is one-to-one with the instrument in this case.
<target_motion_rate>	Does not have units of measure specified	I have a pending question out to the instrument team about what exactly the units for this quantity are. I will add the attribute when I hear back.
Comments at bottom of file	There are comments about rules that need to be created that are not flagged by either "[CHECK]" or "[INCOMPLETE]"	Those comments have been there since well before I started working on this dictionary. Whoever wrote them will have to comment on their intent.

[acraugh]

@cgobat and @benjhirsch: Most of these issues remain unresolved and I've found a few more also not (directly) related to Alice and LORRI. I find it impossible to work around the syntax required by the table format to continue the discussion in writing here. I'm going to close this issue and open a new one to track the remaining issues here plus some others I noted that should be resolved for version 1.2.0.0. We should determine the ultimate course of action on those things much sooner than that to avoid wasting a lot of time tweaking labels. You'll find that list in issue #30. We can modify it as needed.

[cgobat]

Okay, sounds good.