Closed jborbely closed 3 months ago
My comments:
Technical Procedure
Yes, add it. Create a <technicalProcedure>
element where the content may be any string (even empty). Some calibrations may use multiple methods so it should be free-form text to support the newline character. Move it outside of <criteria>
to be a child of <report>
.
Ranges Currently, there are four ways that a report can be defined: file, table, serialised and equation. I think it is import for an equation, but not convinced for the other three.
file: If someone wants to include the calibration data in an external file (e.g., Excel) then the necessary information about ranges should be in the external file. You wouldn't want some info to be in the XML file and some to be in the Excel file. The data should be defined in only one location.
table: I think the min/max values in a particular column indicate the range (similar concept to a "table" in an Excel file)
serialised: A <range>
element could be useful, but the schema could not provide structure on how to specify it. So, in this case it's up the individual/team and cannot be standardised in the schema.
equation: I think this is the only case that can be standardised, for example,
<equation>
<value variables="x y">x+y</value>
<uncertainty variables="">0.1</uncertainty>
<degreeFreedom>9</degreeFreedom>
<ranges> <!-- TODO maybe pick different tag names -->
<range variable="x">
<minimum>2</minimum>
<maximum>10</maximum>
</range>
<range variable="y">
<minimum>1</minimum>
<maximum>8</maximum>
</range>
</ranges>
</equation>
It would be easy to use a programming language to validate that each variable in variables has a corresponding range defined. Ensuring this within the schema may be possible, but the schema does not attempt to validate that the equation syntax is correct (e.g., missing a closing bracket) so it is much easier to pass the range-variable validation to whatever validates the equation syntax. Some things, like the minimum value is floating-point number, can be validated by the schema.
The <technicalProcedure>
element was added as child element of <report>
in bcb0f683320cdfb320174a2c938ac4000e241b47.
The <ranges>
child element for an <equation>
was added in 86cfe1ca38c0c917aa368ad2665988705c9ddcfc. The <ranges>
element is mandatory and it may be empty if there are no variables in the equations. This allows for an equipment register to have the required elements for the msl-lab-logger project to continue.
These commits remove the Technical Procedure and Ranges elements (that have so far been discussed in this issue) from being in <criteria>
, but we may still wish to add more structure to <criteria>
.
Currently, the
<criteria>
of a<report>
can be anything (it is unstructured). Perhaps we should add a few optional elements so that the tags that are used for elements are not arbitrarily chosen by an individual.For example,