XML Schema Definition (XSD) for an Equipment Register
Schema Document Properties
Target Namespace | https://measurement.govt.nz/equipment-register |
---|---|
Version | 0.1 |
Element and Attribute Namespaces |
|
Schema Composition |
|
Copyright (c) 2024, Measurement Standards Laboratory of New Zealand.
XML Schema Definition for the vocabulary and structure of an Equipment Register.
An Equipment Register contains information to satisfy ISO/IEC 17025:2017 Clause 6.4.13:
```
Records shall be retained for equipment which can influence laboratory activities.
The records shall include the following where applicable:
a) the identity of equipment, including software and firmware versions;
b) the manufacturer's name, type identification, and serial number or other unique identification;
c) evidence of verification that equipment conforms with specified requirements;
d) the current location;
e) calibration dates, results of calibrations, adjustments, acceptance criteria, and the due date of the next calibration or the calibration interval;
f) documentation of reference materials, results, acceptance criteria, relevant dates and the period of validity;
g) the maintenance plan and maintenance carried out to date, where relevant to the performance of the equipment;
h) details of any damage, malfunction, modification to, or repair of, the equipment.
```
Global Declarations
Element: register
Name | register |
---|---|
Type | Locally-defined complex type |
Nillable | no |
Abstract | no |
Root element that contains zero or more [equipment](#type_equipment) elements.
<xsd:element name="register"> <xsd:complexType> <xsd:sequence minOccurs="0" maxOccurs="unbounded"> <xsd:element name="equipment" type="msl:equipment"/> </xsd:sequence> <xsd:attribute name="team" type="msl:teamEnumerationString" use="required"/> </xsd:complexType> <xsd:unique name="uniqueID"> <xsd:selector xpath="msl:equipment/msl:id"/> <xsd:field xpath="."/> </xsd:unique> </xsd:element>
Global Definitions
Complex Type: any
Super-types: | None |
---|---|
Sub-types: | None |
Name | any |
---|---|
Abstract | no |
Anything. May contain zero or more child elements and each child element
may contain zero or more attributes and zero or more grandchildren, etc.
<... Allow any attributes from any namespace (lax validation). > Start Sequence [0..*] Allow any elements from any namespace (lax validation). [1] End Sequence </...>
Complex Type: calibrations
Super-types: | None |
---|---|
Sub-types: | None |
Name | calibrations |
---|---|
Abstract | no |
Contains zero or more [measurand](#type_measurand) elements.
<...> Start Sequence [0..*] <msl:measurand> msl:measurand <!-- Uniqueness Constraint - uniqueComponentName Selector - msl:component Field(s) - @name --> </msl:measurand> [1] End Sequence </...>
<xsd:complexType name="calibrations"> <xsd:sequence minOccurs="0" maxOccurs="unbounded"> <xsd:element name="measurand" type="msl:measurand"> <xsd:unique name="uniqueComponentName"> <xsd:selector xpath="msl:component"/> <xsd:field xpath="@name"/> </xsd:unique> </xsd:element> </xsd:sequence> </xsd:complexType>
Complex Type: comment
Super-types: | xsd:string < nonEmptyString (by restriction) < comment (by extension) |
---|---|
Sub-types: | None |
Name | comment |
---|---|
Abstract | no |
A non-empty string that shall not contain the line feed (0x0A)
nor carriage return (0x0D) characters and shall have a date
as an attribute. The date must be in the YYYY-MM-DD format (see
[xsd:date](https://www.w3.org/TR/xmlschema-2/#date) for details).
<... date="xsd:date" [1] > msl:nonEmptyString </...>
Complex Type: component
Super-types: | None |
---|---|
Sub-types: | None |
Name | component |
---|---|
Abstract | no |
A component of the equipment that measures the [quantity](#type_quantity).
Contains a sequence of reports (either digital and/or non-digital reports)
for the measured [quantity](#type_quantity).
<xsd:complexType name="component"> <xsd:sequence minOccurs="0" maxOccurs="unbounded"> <xsd:choice> <xsd:element name="digitalReport" type="msl:digitalReport"/> <xsd:element name="report" type="msl:report"/> </xsd:choice> </xsd:sequence> <xsd:attribute name="name" type="xsd:string" use="required"/> </xsd:complexType>
Complex Type: digitalReport
Super-types: | file < digitalReport (by extension) |
---|---|
Sub-types: | None |
Name | digitalReport |
---|---|
Abstract | no |
A digital calibration report.
A digital calibration report contains embedded
metadata and data that is required by ISO/IEC 17025:2017
Clause 7.8.2.1 (and perhaps additional information).
<... format="msl:digitalFormatEnumerationString" [1] > <msl:url Allow any attributes from any namespace (skip validation). > [1] msl:nonEmptyString </msl:url> <msl:sha256> xsd:string (pattern = [a-fA-F0-9]{64}) </msl:sha256> [1] </...>
Complex Type: documentation
Super-types: | None |
---|---|
Sub-types: | None |
Name | documentation |
---|---|
Abstract | no |
Satisfy ISO/IEC 17025:2017 Clause 6.4.13 \
f) documentation of reference materials, results, ..., relevant dates
and the period of validity
Also includes the _optional_ information that is specified in Section 4.3.6
of the MSL Quality Manual.
<...> Start All [0..1]
<msl:accessories> xsd:string </msl:accessories> [0..1] <msl:manual> xsd:anyURI </msl:manual> [0..1] <msl:personnelRestrictions> xsd:string </msl:personnelRestrictions> [0..1] <msl:referenceMaterials> xsd:string </msl:referenceMaterials> [0..1] <msl:technicalProcedures> xsd:string </msl:technicalProcedures> [0..1] End All
</...>
<xsd:complexType name="documentation"> <xsd:all minOccurs="0"> <xsd:element name="accessories" type="xsd:string" minOccurs="0"/> <xsd:element name="manual" type="xsd:anyURI" minOccurs="0"/> <xsd:element name="personnelRestrictions" type="xsd:string" minOccurs="0"/> <xsd:element name="referenceMaterials" type="xsd:string" minOccurs="0"/> <xsd:element name="technicalProcedures" type="xsd:string" minOccurs="0"/> </xsd:all> </xsd:complexType>
Complex Type: equation
Super-types: | None |
---|---|
Sub-types: | None |
Name | equation |
---|---|
Abstract | no |
The calibration is expressed as an equation. Both the `value` and the
`uncertainty` may be expressed as an equation.
The content of the equation to parse may contain
* the space (0x20) and tab (0x09) characters
* integer and floating-point numbers (e.g., 100, 100.0, 1e2, 1.0E+02)
* the following brackets: `(` `)`
* the following (unary) operators: `+` `-` `*` `/`
* the following names to represent the corresponding numerical value:
- pi = 3.14159...
* the following functions:
- pow
- sqrt
- sin
- asin
- cos
- acos
- tan
- atan
- exp
- log (natural logarithm, base _e_)
- log10 (common logarithm, base _10_)
Depending on the programming language that is used to parse an equation,
a search and replace may need to be performed. If the programming language
does not support the `pow(x,y)` function to raise `x` to the power of `y`,
you may use the following regular expression (which uses a named capture
group for the `x` and `y` text) `pow\((?<x>[^,]+),(?<y>[^,]+)\)`
to perform a search and replace.
_Attention: This XSD document validates the content of an XML document
(e.g., that the `value` and `uncertainty` elements exist and the content
is a [nonEmptyString](#type_nonEmptyString)). It does not attempt to validate
that the equation is mathematically correct (e.g., whether the equation
is missing a closing bracket). You must use another tool to validate the
mathematical correctness of the equation._
**Example**
The correction to apply for the `value` is expressed as a second-order
polynomial and the `uncertainty` is a constant.
```
<equation>
<value variables="T">T + (-10.66 + 1.58e-2*T + 1.212e-3*pow(T,2))</value>
<uncertainty variables="">0.45</uncertainty>
<unit>°C</unit>
<ranges>
<range variable="T">
<minimum>15</minimum>
<maximum>25</maximum>
</range>
</ranges>
</equation>
```
<...> <msl:value variables="msl:variables" [1] > [1] msl:nonEmptyString </msl:value> <msl:uncertainty variables="msl:variables" [1] > [1] msl:nonEmptyString </msl:uncertainty> <msl:unit> msl:nonEmptyString </msl:unit> [1] <msl:ranges> msl:ranges </msl:ranges> [1] <msl:degreeFreedom> xsd:double (1 <= value <= INF) </msl:degreeFreedom> [0..1] </...>
<xsd:complexType name="equation"> <xsd:sequence> <xsd:element name="value"> <xsd:complexType> <xsd:simpleContent> <xsd:extension base="msl:nonEmptyString"> <xsd:attribute name="variables" type="msl:variables" use="required"/> </xsd:extension> </xsd:simpleContent> </xsd:complexType> </xsd:element> <xsd:element name="uncertainty"> <xsd:complexType> <xsd:simpleContent> <xsd:extension base="msl:nonEmptyString"> <xsd:attribute name="variables" type="msl:variables" use="required"/> </xsd:extension> </xsd:simpleContent> </xsd:complexType> </xsd:element> <xsd:element name="unit" type="msl:nonEmptyString"/> <xsd:element name="ranges" type="msl:ranges"/> <xsd:element name="degreeFreedom" minOccurs="0"> <xsd:simpleType> <xsd:restriction base="xsd:double"> <xsd:minInclusive value="1"/> <xsd:maxInclusive value="INF"/> </xsd:restriction> </xsd:simpleType> </xsd:element> </xsd:sequence> </xsd:complexType>
Complex Type: equipment
Super-types: | None |
---|---|
Sub-types: | None |
Name | equipment |
---|---|
Abstract | no |
Contains information about the equipment to satisfy ISO/IEC 17025:2017
Clause 6.4.13 as well as the MSL Quality Manual Section 4.3.6.
<... keywords="msl:keywordsList" [0..1] > <msl:id> msl:idPatternString </msl:id> [1] <msl:manufacturer> msl:tokenizedString </msl:manufacturer> [1] <msl:model> msl:tokenizedString </msl:model> [1] <msl:serial> msl:tokenizedString </msl:serial> [1] <msl:description> msl:tokenizedString </msl:description> [1] <msl:location> msl:labEnumerationString </msl:location> [1] <msl:status> msl:statusEnumerationString </msl:status> [1] <msl:loggable> xsd:boolean </msl:loggable> [1] <msl:traceable> xsd:boolean </msl:traceable> [1] <msl:calibrations> msl:calibrations <!-- Uniqueness Constraint - uniqueMeasurandQuantity Selector - msl:measurand Field(s) - @quantity --> </msl:calibrations> [1] <msl:maintenance> msl:maintenance </msl:maintenance> [1] <msl:firmware> msl:firmware </msl:firmware> [1] <msl:acceptanceCriteria> msl:any </msl:acceptanceCriteria> [1] <msl:financial> msl:financial </msl:financial> [1] <msl:documentation> msl:documentation </msl:documentation> [1] <msl:extra> msl:any </msl:extra> [0..1] </...>
<xsd:complexType name="equipment"> <xsd:sequence> <xsd:element name="id" type="msl:idPatternString"/> <xsd:element name="manufacturer" type="msl:tokenizedString"/> <xsd:element name="model" type="msl:tokenizedString"/> <xsd:element name="serial" type="msl:tokenizedString"/> <xsd:element name="description" type="msl:tokenizedString"/> <xsd:element name="location" type="msl:labEnumerationString"/> <xsd:element name="status" type="msl:statusEnumerationString"/> <xsd:element name="loggable" type="xsd:boolean"/> <xsd:element name="traceable" type="xsd:boolean"/> <xsd:element name="calibrations" type="msl:calibrations"> <xsd:unique name="uniqueMeasurandQuantity"> <xsd:selector xpath="msl:measurand"/> <xsd:field xpath="@quantity"/> </xsd:unique> </xsd:element> <xsd:element name="maintenance" type="msl:maintenance"/> <xsd:element name="firmware" type="msl:firmware"/> <xsd:element name="acceptanceCriteria" type="msl:any"/> <xsd:element name="financial" type="msl:financial"/> <xsd:element name="documentation" type="msl:documentation"/> <xsd:element name="extra" type="msl:any" minOccurs="0"/> </xsd:sequence> <xsd:attribute name="keywords" type="msl:keywordsList"/> </xsd:complexType>
Complex Type: file
Super-types: | None |
---|---|
Sub-types: |
|
Name | file |
---|---|
Abstract | no |
Calibration data is stored in another file.
Specifying an absolute path in an equipment register should only be
performed if the location of the file will remain constant for an
extended period of time. This is not typically the case, as MSL has
had to migrate data multiple times (i.e., a network drive, then GDrive,
then OneDrive, ...).
One option is to think of the file-system path as a combination of two parts
```
root \ <url>
```
where,
* root: This is not stored in an equipment register. Instead, it may be
stored in a separate file (ideally in a single file) on a local
hard drive. How and where this is stored is up to the individual.
* url: This is the `<url>` element in an equipment register.
For example, consider the following absolute path
```
C:\Users\username\OneDrive - My Company Name\Length\Quality\Equipment\register.xml
```
each part could be broken down as follows
* root = `C:\Users\username\OneDrive - My Company Name\`
- this value could be stored, for example, in a file in the users home directory
or as a constant in the analysis software
* url = `Length\Quality\Equipment\register.xml`
Whenever someone needs to load the file, the `root` is read from a local
file and the `<url>` element is read from the equipment register and
the absolute path is constructed.
_Attention: This XSD document validates the content of an XML document
(e.g., that the `url` element exists and the content is a
[nonEmptyString](#type_nonEmptyString)). It does not attempt to validate
that the file exists nor if the SHA-256 checksum is correct for the file
(although the general format of the checksum, i.e., has the proper length
and contains only allowed characters, is validated). You must use another
tool to validate the existence of the file and the validity of the
checksum value._
**Examples**
The data is stored in an Excel file that is located at a _relative_ path
```
<file>
<url sheet="2024-May" cell="B2:D25">relative\path\data.xlsx</url>
<sha256>70d79d2eb24dc2515faaf4ab7fa3540e5a73ca6080181908a0ea87a309293609</sha256>
</file>
```
The data is stored in a digital calibration certificate on a network server
```
<file>
<url>file://msl-nas/Photometry/Calibrations/job123456.xml</filename>
<sha256>8392e473a047543773138653b98037956fa2086e4a54fc882d913f10cc217728</sha256>
</file>
```
<xsd:complexType name="file"> <xsd:sequence> <xsd:element name="url"> <xsd:complexType> <xsd:simpleContent> <xsd:extension base="msl:nonEmptyString"> <xsd:anyAttribute processContents="skip"/> </xsd:extension> </xsd:simpleContent> </xsd:complexType> </xsd:element> <xsd:element name="sha256"> <xsd:simpleType> <xsd:restriction base="xsd:string"> <xsd:pattern value="[a-fA-F0-9]{64}"/> </xsd:restriction> </xsd:simpleType> </xsd:element> </xsd:sequence> </xsd:complexType>
Complex Type: financial
Super-types: | None |
---|---|
Sub-types: | None |
Name | financial |
---|---|
Abstract | no |
Includes the _optional_ financial information about the equipment
to satisfy Section 4.3.6 of the MSL Quality Manual.
The child elements, if specified, may appear in any order and
are each optional.
Complex Type: firmware
Super-types: | None |
---|---|
Sub-types: | None |
Name | firmware |
---|---|
Abstract | no |
Satisfy ISO/IEC 17025:2017 Clause 6.4.13 \
a) ... software and firmware version
A distinction is made between _software_ and _firmware_ version.
**Software**: May be provided by the manufacturer of the equipment
and may be installed/updated by an end user on _any_ computer. The
manufacturer of the equipment may provide this software as, for
example, a graphical user interface (GUI) and/or as a software
development kit (SDK) to interface with the equipment. Software
could also refer to the version of the bespoke code that is written
by a metrologist to control the equipment. Both the manufacturer and
the bespoke software version are important to document, but it shall
not be specified in the equipment register. It shall be documented in a
different manner, e.g., as metadata in a file during data acquisition.
**Firmware**: Embedded within the equipment. May be updated by either
the manufacturer and/or the end user. If applicable, it shall be
specified in the equipment register.
The primary difference is that the _firmware_ version has a single
value of truth (it is independent of where the equipment
is physically located and independent of which computer is used to
interface with it) whereas the _software_ version depends on which
computer (perhaps even on which executable is run on the same computer)
is used to interface with the equipment and therefore there may not be
a single value of truth that can be defined in the equipment register.
For equipment that support the `*IDN?` query, the firmware version is
typically found as the fourth item in the reply: _manufacturer,model,serial,firmware_
Complex Type: maintenance
Super-types: | None |
---|---|
Sub-types: | None |
Name | maintenance |
---|---|
Abstract | no |
Satisfy ISO/IEC 17025:2017 Clause 6.4.13 \
g) the maintenance plan and maintenance carried out to date, where relevant to the performance of the equipment \
h) details of any damage, malfunction, modification to, or repair of, the equipment
Complex Type: measurand
Super-types: | None |
---|---|
Sub-types: | None |
Name | measurand |
---|---|
Abstract | no |
The quantity intended to be measured.
<... quantity="msl:quantityEnumerationString" [1] calibrationInterval="msl:nonNegativeDecimal" [1] > Start Sequence [0..*] <msl:component> msl:component </msl:component> [1] End Sequence </...>
<xsd:complexType name="measurand"> <xsd:sequence minOccurs="0" maxOccurs="unbounded"> <xsd:element name="component" type="msl:component"/> </xsd:sequence> <xsd:attribute name="quantity" type="msl:quantityEnumerationString" use="required"/> <xsd:attribute name="calibrationInterval" type="msl:nonNegativeDecimal" use="required"/> </xsd:complexType>
Complex Type: ranges
Super-types: | None |
---|---|
Sub-types: | None |
Name | ranges |
---|---|
Abstract | no |
The numeric range for each variable that an `equation` is valid for.
<xsd:complexType name="ranges"> <xsd:sequence minOccurs="0" maxOccurs="unbounded"> <xsd:element name="range"> <xsd:complexType> <xsd:sequence> <xsd:element name="minimum" type="xsd:double"/> <xsd:element name="maximum" type="xsd:double"/> </xsd:sequence> <xsd:attribute name="variable" type="msl:nonEmptyString" use="required"/> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType>
Complex Type: report
Super-types: | None |
---|---|
Sub-types: | None |
Name | report |
---|---|
Abstract | no |
A (non-digital) calibration report.
Since the report is not digital (does not contain embedded
metadata and data) _some_ of the information that is required
by ISO/IEC 17025:2017 Clause 7.8.2.1 must be explicitly
included in the equipment register.
<...> <msl:reportNumber> msl:nonEmptyString </msl:reportNumber> [1] <msl:reportIssueDate> xsd:date </msl:reportIssueDate> [1] <msl:measurementStartDate> xsd:date </msl:measurementStartDate> [1] <msl:measurementStopDate> xsd:date </msl:measurementStopDate> [1] <msl:issuingLaboratory person="msl:nonEmptyString" [0..1] > [1] msl:nonEmptyString </msl:issuingLaboratory> <msl:technicalProcedure> xsd:string </msl:technicalProcedure> [1] <msl:criteria> msl:any </msl:criteria> [1] Start Choice [1] <msl:equation> msl:equation </msl:equation> [1] <msl:file> msl:file </msl:file> [1] <msl:serialised> msl:serialised </msl:serialised> [1] <msl:table> msl:table </msl:table> [1] End Choice <msl:extra> msl:any </msl:extra> [0..1] </...>
<xsd:complexType name="report"> <xsd:sequence> <xsd:element name="reportNumber" type="msl:nonEmptyString"/> <xsd:element name="reportIssueDate" type="xsd:date"/> <xsd:element name="measurementStartDate" type="xsd:date"/> <xsd:element name="measurementStopDate" type="xsd:date"/> <xsd:element name="issuingLaboratory"> <xsd:complexType> <xsd:simpleContent> <xsd:extension base="msl:nonEmptyString"> <xsd:attribute name="person" type="msl:nonEmptyString"/> </xsd:extension> </xsd:simpleContent> </xsd:complexType> </xsd:element> <xsd:element name="technicalProcedure" type="xsd:string"/> <xsd:element name="criteria" type="msl:any"/> <xsd:choice> <xsd:element name="equation" type="msl:equation"/> <xsd:element name="file" type="msl:file"/> <xsd:element name="serialised" type="msl:serialised"/> <xsd:element name="table" type="msl:table"/> </xsd:choice> <xsd:element name="extra" type="msl:any" minOccurs="0"/> </xsd:sequence> </xsd:complexType>
Complex Type: serialised
Super-types: | None |
---|---|
Sub-types: | None |
Name | serialised |
---|---|
Abstract | no |
Calibration data is stored in a serialised format.
Serialisation (also known as marshalling) is the process of
translating a data structure or object state into a format
that can be stored and reconstructed later.
<...> Start Choice [1] <gtc:gtcArchive> ... </gtc:gtcArchive> [1] <msl:gtcArchiveJSON Allow any attributes from any namespace (skip validation). > [1] xsd:string </msl:gtcArchiveJSON> End Choice </...>
<xsd:complexType name="serialised"> <xsd:choice> <xsd:element ref="gtc:gtcArchive"/> <xsd:element name="gtcArchiveJSON"> <xsd:complexType> <xsd:simpleContent> <xsd:extension base="xsd:string"> <xsd:anyAttribute processContents="skip"/> </xsd:extension> </xsd:simpleContent> </xsd:complexType> </xsd:element> </xsd:choice> </xsd:complexType>
Complex Type: table
Super-types: | None |
---|---|
Sub-types: | None |
Name | table |
---|---|
Abstract | no |
Calibration data is expressed as a CSV table.
_Attention: This XSD document validates the content of an XML document
(e.g., that the `header` element exists and that the content matches
the allowed pattern). It does not attempt to validate that the table
is structurally correct (e.g., whether `type`, `unit`, `header` and
`data` contain the same number of columns). You must use another tool
to validate the structure of the table._
**Example**
```
<table>
<type> int , double , double</type>
<unit> nm , W/m^2 , W/m^2</unit>
<header>Wavelength, Irradiance , Irradiance Std. Uncertainty</header>
<data> 250 , 0.018184693 , 0.020338474
300 , 0.184783924 , 0.017558388
350 , 0.808454870 , 0.016061036
400 , 2.213559358 , 0.014050724
450 , 4.490045649 , 0.012509585
500 , 7.451358772 , 0.012003620
550 , 10.75754957 , 0.011528671
600 , 14.03809504 , 0.011028261
650 , 16.99469553 , 0.011031749
700 , 19.44093973 , 0.010771097
</data>
</table>
```
<...> <msl:type> xsd:string (pattern = \s*(bool|int|double|string)\s*(,\s*(bool|int|double|string)\s*)*) </msl:type> [1] <msl:unit> xsd:string </msl:unit> [1] <msl:header> xsd:string (pattern = [^,]+(,[^,]+)*) </msl:header> [1] <msl:data> xsd:string (pattern = [^,]+(,[^,\n][^,]*)*) </msl:data> [1] </...>
<xsd:complexType name="table"> <xsd:sequence> <xsd:element name="type"> <xsd:simpleType> <xsd:restriction base="xsd:string"> <xsd:pattern value="\s*(bool|int|double|string)\s*(,\s*(bool|int|double|string)\s*)*"/> </xsd:restriction> </xsd:simpleType> </xsd:element> <xsd:element name="unit" type="xsd:string"/> <xsd:element name="header"> <xsd:simpleType> <xsd:restriction base="xsd:string"> <xsd:pattern value="[^,]+(,[^,]+)*"/> </xsd:restriction> </xsd:simpleType> </xsd:element> <xsd:element name="data"> <xsd:simpleType> <xsd:restriction base="xsd:string"> <xsd:pattern value="[^,]+(,[^,\n][^,]*)*"/> </xsd:restriction> </xsd:simpleType> </xsd:element> </xsd:sequence> </xsd:complexType>
Simple Type: digitalFormatEnumerationString
Super-types: | xsd:string < digitalFormatEnumerationString (by restriction) |
---|---|
Sub-types: | None |
Name | digitalFormatEnumerationString |
---|---|
Content |
|
The format of a digital calibration report.
Simple Type: idPatternString
Super-types: | xsd:string < idPatternString (by restriction) |
---|---|
Sub-types: | None |
Name | idPatternString |
---|---|
Content |
|
Satisfy ISO/IEC 17025:2017 Clause 6.4.13 \
a) the identity of equipment ...
The id pattern shall consist of
* the upper-case letters **MSLE**
* followed by one period **.** (0x2E)
* followed by one of the following letters
* **E**: Electrical
* **F**: Frequency (Time)
* **H**: Humidity
* **L**: Length
* **M**: Mass
* **O**: Optics (Light)
* **P**: Pressure
* **T**: Temperature
* followed by one period **.** (0x2E)
* followed by one or more upper-case letters and/or digits
Simple Type: keywordsList
Super-types: | None |
---|---|
Sub-types: | None |
Name | keywordsList |
---|---|
Content |
|
Keywords that may be used to describe the equipment.
Each keyword is separated by whitespace.
**Example**
```
keywords="Source Voltage AC DC"
```
<xsd:simpleType name="keywordsList"> <xsd:list> <xsd:simpleType> <xsd:restriction base="xsd:string"> <xsd:enumeration value="AC"/> <xsd:enumeration value="Barometer"/> <xsd:enumeration value="Current"/> <xsd:enumeration value="DAQ"/> <xsd:enumeration value="DC"/> <xsd:enumeration value="DMM"/> <xsd:enumeration value="GaugeBlock"/> <xsd:enumeration value="Hygrometer"/> <xsd:enumeration value="Laser"/> <xsd:enumeration value="Monochromator"/> <xsd:enumeration value="Oscilloscope"/> <xsd:enumeration value="PRT"/> <xsd:enumeration value="ResistanceBridge"/> <xsd:enumeration value="Sense"/> <xsd:enumeration value="Source"/> <xsd:enumeration value="Thermometer"/> <xsd:enumeration value="Voltage"/> </xsd:restriction> </xsd:simpleType> </xsd:list> </xsd:simpleType>
Simple Type: labEnumerationString
Super-types: | xsd:string < labEnumerationString (by restriction) |
---|---|
Sub-types: | None |
Name | labEnumerationString |
---|---|
Content |
|
The laboratory that the equipment is usually located in.
<xsd:simpleType name="labEnumerationString"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="CMM Lab"/> <xsd:enumeration value="Cryogenic Radiometer"/> <xsd:enumeration value="Detector Responsivity"/> <xsd:enumeration value="Flexible Optics"/> <xsd:enumeration value="Goniospectrophotometer"/> <xsd:enumeration value="Hilger Lab"/> <xsd:enumeration value="Kibble Balance"/> <xsd:enumeration value="Laser Lab"/> <xsd:enumeration value="Long Room"/> <xsd:enumeration value="Mass Standards Laboratories"/> <xsd:enumeration value="Photometric Bench"/> <xsd:enumeration value="Pressure Standards Laboratories"/> <xsd:enumeration value="Single Photon"/> <xsd:enumeration value="Spectrophotometer"/> <xsd:enumeration value="Underground Tape Tunnel"/> </xsd:restriction> </xsd:simpleType>
Simple Type: nonEmptyString
Name | nonEmptyString |
---|---|
Content |
|
A non-empty string that shall not contain the line feed (0x0A)
nor carriage return (0x0D) characters.
Simple Type: nonNegativeDecimal
Super-types: | xsd:decimal < nonNegativeDecimal (by restriction) |
---|---|
Sub-types: | None |
Name | nonNegativeDecimal |
---|---|
Content |
|
A decimal number that is ≥ 0.
Derived from [xsd:decimal](https://www.w3.org/TR/xmlschema-2/#decimal)
by setting the value of _minInclusive_ to be 0.
Simple Type: quantityEnumerationString
Super-types: | xsd:string < quantityEnumerationString (by restriction) |
---|---|
Sub-types: | None |
Name | quantityEnumerationString |
---|---|
Content |
|
The quantity intended to be measured.
<xsd:simpleType name="quantityEnumerationString"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="Angle"/> <xsd:enumeration value="Angularity"/> <xsd:enumeration value="Current"/> <xsd:enumeration value="Cylindricity"/> <xsd:enumeration value="Deviation in Length"/> <xsd:enumeration value="Flatness"/> <xsd:enumeration value="Frequency"/> <xsd:enumeration value="Humidity"/> <xsd:enumeration value="Length"/> <xsd:enumeration value="Parallelism"/> <xsd:enumeration value="Perpendicularity"/> <xsd:enumeration value="Pressure"/> <xsd:enumeration value="Resistance"/> <xsd:enumeration value="Roundness"/> <xsd:enumeration value="Runout"/> <xsd:enumeration value="Sphericity"/> <xsd:enumeration value="Straightness"/> <xsd:enumeration value="Temperature"/> <xsd:enumeration value="Total Runout"/> <xsd:enumeration value="Variation in Length"/> <xsd:enumeration value="Voltage"/> <xsd:enumeration value="Wavelength"/> </xsd:restriction> </xsd:simpleType>
Simple Type: statusEnumerationString
Super-types: | xsd:string < statusEnumerationString (by restriction) |
---|---|
Sub-types: | None |
Name | statusEnumerationString |
---|---|
Content |
|
The status of the equipment is an indication of whether the
equipment is _active_ (in use) or _inactive_ (not in use).
A single value indicates that the equipment is _active_:
* **Active**: The equipment is operable and may be used
The following values indicate that the equipment is _inactive_, but
provide more context as to the reason why it is _inactive_:
* **Damaged**: The equipment is damaged and is no longer usable
* **Dormant**: The equipment is still operable, it is no longer in use but may be used again
(e.g., the equipment was replaced with a newer/different model, and it is kept as a backup)
* **Lost**: The equipment is lost, but if found may be put back into service.
* **Retired**: The equipment is still operable, but there are no intentions of using it again
(e.g., the equipment depends on other equipment that is not available or is no longer manufactured)
Simple Type: teamEnumerationString
Super-types: | xsd:string < teamEnumerationString (by restriction) |
---|---|
Sub-types: | None |
Name | teamEnumerationString |
---|---|
Content |
|
The team that is responsible for the equipment register.
<xsd:simpleType name="teamEnumerationString"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="Electrical"/> <xsd:enumeration value="Humidity"/> <xsd:enumeration value="Length"/> <xsd:enumeration value="Light"/> <xsd:enumeration value="Mass"/> <xsd:enumeration value="Pressure"/> <xsd:enumeration value="Temperature"/> <xsd:enumeration value="Time"/> </xsd:restriction> </xsd:simpleType>
Simple Type: tokenizedString
Super-types: | xsd:string < tokenizedString (by restriction) |
---|---|
Sub-types: | None |
Name | tokenizedString |
---|---|
Content |
|
A non-empty string that shall not
* contain the tab (0x09), line feed (0x0A) nor carriage return (0x0D) characters,
* contain sequences of two or more spaces (0x20),
* have leading or trailing spaces.
This implementation is what [xsd:token](https://www.w3.org/TR/xmlschema-2/#token)
indicates; however, to achieve the desired validation outcome, string normalisation
must not occur before validation. This is the reason why the _base_ class is
[xsd:string](https://www.w3.org/TR/xmlschema-2/#string) (with a _pattern_ facet)
and not [xsd:token](https://www.w3.org/TR/xmlschema-2/#token). The
[lexical space](https://www.w3.org/TR/xmlschema-2/#lexical-space)
is not what is in the raw XML document, it is what you get after applying
_pre-lexical_ normalisations.
Simple Type: variables
Super-types: | None |
---|---|
Sub-types: | None |
Name | variables |
---|---|
Content |
|
A list of variable name(s) in an equation.
Each variable name must begin with a letter and may be
followed by zero or more letter, digit or underscore
characters.
Whitespace shall be used to separate each variable name.
If no variables are used in the equation (i.e., the
equation is a constant numerical value), the `variables`
attribute must still exist, but the value may be empty.
**Examples**
* variables=""
* variables="x"
* variables="t rh"
* variables="x1 x2 x3"