add sdpi p history service option

[d-gregorczyk]

☑ Mandatory Tasks

The following aspects have been respected by the pull request assignee and at least one reviewer:

• Changelog update (necessity checked and entry added or not added respectively)
  • Pull Request Assignee
  • Reviewer

[PaulMartinsen]

Suggest changing R0512 to something like:

The provider shall transmit hm:HistoricMdib before transmitting each contiguous MDIB Sequence of Changes in the range requested by a consumer.
Note: this allows a provider to skip over gaps in its historical record while providing a MDIB Configuration for the consumer to apply changes to.

Possible need to tweak R0514 to something like:

For an MDIB Sequence of Changes that is requested from a SOMDS Provider, the SOMDS Provider shall provide exactly one MDIB Configuration in hm:ChangeSequence/hm:HistoricMdib for each contiguous MDIB sequence of changes.

Reasoning:

I was thinking more about the case where a provider starts providing history information but some of the history becomes unavailable before it is delivered. This could occur when:

1. the consumer requests all (or most) of the history available, and
2. the provider has limited memory and must discard old history records to make room for new changes to the mdib.

Some available options :

1. End subscription:

• The provider ends the history subscription, possibly with a (new) fault message.
• The consumer starts a new history subscription and gets the next lot of data.
• Repeat above steps each time items are lost from this history.

2. Send with gaps:

• The provider skips over the missing data and continues with what it has.
• This is (probably?) useless to the consumer who doesn't have a mdib starting point to apply changes to.

3. Send with gaps and starting mdib

• The provider sends a full mdib snapshot (if this was requested by the original subscription)
• Provider continues with change reports.

I quite like option 3 because:

• it avoids multiple subscriptions (with potential race conditions) and doesn't require any special handling of fault messages on the consumer end.
• the provider does its best to provide the information requested and while still letting the consumer create coherent mdib state.
• its more likely to avoid lost history than if the consumer has to re-subscribe. The consumer can unsubscribe if it doesn't want any more data following a gap.

If the consumer didn't request a baseline mdib, we could sensibly fallback to option 1: end the subscription.

Note

Added to review.

[PaulMartinsen]

I would quite like to be able to omit waveform streams from the history because:

1. they use up a lot of memory,
2. an hour old waveform stream may often not be relevant anymore, and
3. a deeper history of states other than waveform streams may be more relevant than a shallow history with waveform streams.

But the general case, where providers may omit any information, seems quite complicated and could be problematic. That is, important context may be lost.

Could the provider be allowed to omit waveform streams either:

1. without disclosing this to the consumer (except perhaps in the documentation), or
2. by sending RealTimeSamleArrayMetricState with @Off.

Or maybe there is no value in waveform streams in the historic record and they could just be omitted completely? That is, remove msg:WaveformStream from the HistoricReportType in HistoryModel.xsd

The main problem seems to be missing state versions (R1005), although I think we need to get rid of that one anyway.

Note

This is addressed in R0516 now

[PaulMartinsen]

The sequence diagrams weren't showing up for me. It looks like the action isn't copying them into the supplement from .ci\asciidoc-converter\images when it makes the zip file I downloaded from https://github.com/IHE/DEV.SDPi/actions/runs/15761385158

Note

Works now.

[PaulMartinsen]

I've focused on changes to improve clarity and provide a good starting point for trial implementation.

[PaulMartinsen]

For clarity:

… or filter request that point into the future.

… or the filter requests reports from the future.

[PaulMartinsen]

simplify for clarity:

The <<vol1_spec_sdpi_p_actor_somds_provider>> transmitting <<term_historic_localized_text>> shall transmit filtered <<term_historic_localized_text>>s before transmitting hm:HistoricMdib or hm:HistoricReport elements that reference the <<term_historic_localized_text>>s.

Note:
This ensures the localized text is available to the <<vol1_spec_sdpi_p_actor_somds_consumer>> before it is used by other elements.