History: declaring excluded content

[PaulMartinsen]

Providers may elect not to make all content available from the history service (e.g. real-time samples). We discussed, at plug-a-thon 18, whether anyone (e.g., consumers, responsible organizations) needs to know what is available and how to disclose this?

One method to disclose available history information is a per-metric extension, for example:

<Metric xsi:type="RealTimeSampleArrayMetricDescriptor" Resolution="1" SamplePeriod="PT0.001S" MetricCategory="Msrmt" MetricAvailability="Cont" Handle="rtsa_metric_0.channel_1.vmd_0.mds_0" DescriptorVersion="1">
  <ext:Extension>
    <hm:History Available="true" Period="PT30S" xmlns:hm="urn:oid:1.3.6.1.4.1.3592.2.6933.5.1"/>
  </ext:Extension>
  <Type Code="67108881"/>
    :
    :

• we weren't able to identify specific use cases where someone needed to know this information but didn't necessarily believe there aren't any; may need discussion with other stakeholders to identify specific use cases.
• tagging the unavailable items with an extension (similar to retrievability) seemed problematic for several reasons
  • historic availability could be considered part of transport information and doesn't belong in the mdib;
  • an alternative view that availability in the history service might be considered part of the mdib description and not transport information
  • providers may modify the subscription so there may be no description present for states that won't be included in the history service in the current mdib at the time a consumer is making a request.
• a separate function in the history service may be needed to indicate what's available. This needs to account for
  • multiple version sequences,
  • parts of the description that come and go,
  • clock-versioning anticipated for non-slewing time-adjustments.

[PaulMartinsen]

After more thought, I like the per-metric extension again:

• for me, a history element in the MdDescription is like the NumericMetricDescriptor/@MetricAvailability or NumericMetricDescriptor/@LifeTimePeriod information, here describing the historic data that is available (however it might be retrieved) and the history service is a separate thing, that happens to be one (and currently only?) method that historic data may be retrieved,
• placing the information in a separate function:
  • binds the availability of historic information to the history service, which may be overly restrictive,
  • seems very complicated when considering multiple version sequences, description modifications etc,
• its possible this information doesn't need to be provided in SDC messages at all (that is, it could be in user instructions), but if it does need to be in SDC messages,
  • perhaps the consumer is collecting it for audit purposes, so it is going to make history requests regardless of what's available,
  • description modifications already enable the enthusiastic provider to alter the availability of history data in interesting, and perhaps not recommended, ways (e.g., dropping historic availability as resources diminish).
  • if the consumer isn't using availability when deciding to subscribe to the history service, there may be no reason to separate it into a separate function.

Other notes on the per-metric extension idea:

• I would really like it to default to available since I'd expect few to be not available and this would reduce mdib size/maintenance effort.

Example schema addition:

  <xsd:element name="History" type="hm:HistoryAvailabilityType">
    <xsd:annotation>
      <xsd:documentation>Extension point that MAY be included as a pm:AbstractDescriptor extension to describe availability of historic state reports.</xsd:documentation>
    </xsd:annotation>
  </xsd:element>
  <xsd:complexType name="HistoryAvailabilityType">
    <xsd:attribute name="Available" default="true" type="xsd:boolean" use="optional" />
    <xsd:attribute name="Duration" type="xsd:duration" use="optional" />
  </xsd:complexType>

[ToddCooper]

SDPi Friday 2024.12.06 Review -
May need to consider at some point ... but need clear, meaningful use cases to understand the requirements and priority.
Question: What is the business case driving this finding? (if any?!)
Could be addressed by History Service extension to address these kinds of questions.