Consider adding <reportDate> element

[jborbely]

Currently, there is no pre-defined element to specify the report date. Should there be?

1. If so, it would make sense to name it <reportDate> or simply <date> (since the schema currently uses <number> and not <reportNumber>) and put it next to <startDate> and <endDate>. While adding this may seem like an obvious "yes", the reality is that it may take a long time from when the calibration was performed before a report is published.

2. Maybe <startDate> and <endDate> should be renamed to <measurementStartDate> and <measurementEndDate>. The documentation clearly states what the start and end dates refer to, but, the XML element name does not (and maybe it doesn't need to).

[BlairDHall]

17025 (clause 7.8.2.1) distinguishes between (and requires for reporting) the date(s) at which laboratory activity took place, and the date on which the report was issued.

I suggest you name the elements to clearly match 17025. So, yes <measurementStartDate> looks good. Perhaps also <reportIssueDate> ?

Also, if you are documenting the terms, it may help in future to include references to 17025 clauses or other related factors.

I suppose laboratory activity may be a list of dates and/or date intervals, but I have never seen MSL report in that way.

[jborbely]

Absolutely fantastic to provide a reference to a clause in 17025! So "yes", include the date the report was issued.

Also, if you are documenting the terms, it may help in future to include references to 17025 clauses or other related factors.

Agreed. The documentation does try to provide references to 17025 clauses, when the reference is known to the author (i.e., so far only me). Being notified of the clause, either by raising an Issue, or even better, providing a Pull Request, is certainly welcomed from anyone with the knowledge.

I suppose laboratory activity may be a list of dates and/or date intervals, but I have never seen MSL report in that way.

The limited number of reports I've seen from other NMIs also only list a date range (two dates, n=2) rather than specifying a list of dates (n>2) that describe more detail of what occurred on a particular date.

---

My proposal is to make the following changes 1) Add <reportIssueDate> 2) Rename the other two date elements to be <measurement*Date>. I like Start-Stop and Begin-End pairs that are typically found in different languages, so I think * should be filled in appropriately with one of those pairs. 3) Rename <number> to <reportNumber>

From previous in-person discussions, we could handle situations when the report is taking a while to be published so a <reportIssueDate> is not known yet. (I think) The Schema should not handle factors/reasons regarding delays that a report has not been issued and yet the results of the analysis need to be used and the Schema should simply define what is required; however, we could use a union between a xsd:date and an enum string, for example, Not Available as a date type . That way the <reportIssueDate> element must exist and someone must either write a YYYY-MM-DD value or Not Available but nothing else is allowed. I will not implement this hacky union option until more people provide feedback (here or offline).

[BlairDHall]

I think this will help. Documentation of elements is very important, because what people put into those elements must be consistent.

I am a bit surprised that this level of detail goes into the equipment register. I would have thought it better not to duplicate information already in another document (calibration report). But of course we can't easily access that info right now.

Have you considered using the PDF XMP data as a "future" way to expose report metadata? The MSL XMP could be extended to hold DCC administrative data elements. Just a thought.

[jborbely]

I would have thought it better not to duplicate information already in another document (calibration report).

@BlairDHall The following is not trying to convince you how/why digitalisation is useful. I completely agree with everything you mention! This comment is primarily for other readers.

I also don't think this level of detail needs to go into the equipment register, but it should be captured in a machine readable way somewhere to help solve various issues that MSLers have. My view of an equipment register is a document that contains the complete history (a list of pointers to calibration reports, embedded maintenance history, ...) of the equipment throughout its lifespan. A very simple document. Digital (meta)data about a single calibration belongs embedded in the report (e.g., DCC and/or XMP) so that the (meta)data moves with the report for anyone to access. There will be some basic metadata duplicated (e.g., manufacture, model, serial number, ...) in the equipment register file and in the calibration report.

So far, the offline conversations have been about fixing the current state of MSL's equipment register. I will create a new issue that proposes one way that the schema can be a bridge during the transition between business as usual and a digitalised MSL.

[jborbely]

2d940e397ca8fbe05b3bb8d9d23a8f07ba5a6e2a renamed <startDate> to <measurementStartDate>, <stopDate> to <measurementStopDate> and <number> to <reportNumber> and added 17025 Clause 7.8.2.1 to the documentation.

8412b62dbfccf97bba3e9c3eb8a43d14a6681072 moved the optional date attribute to be a required <reportIssueDate> element with type xsd:date (did not use a union between a xsd:date and an enum string Not Available as the type – can add later) and added 17025 Clause 7.8.2.1 to the documentation. If a union is desired, we can use something like

<xsd:element name="reportIssueDate" type="msl:issueDate">

where,

<xsd:simpleType name="issueDate">
    <xsd:union memberTypes="xsd:date">
        <xsd:simpleType>
            <xsd:restriction base="xsd:string">
                <xsd:enumeration value="Not Available"/>
            </xsd:restriction>
        </xsd:simpleType>
    </xsd:union>
</xsd:simpleType>