457 early pre published alert pkp integration into sdpi a

[JavierEspina]

📑 Description

☑ 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

[JavierEspina]

@ToddCooper, @d-gregorczyk, @PeterKranich - this PR is still in drafting and hence incomplete. But feel free to start looking at the changes before my summer holiday starts (on Aug 2).

[JavierEspina]

@PaulMartinsen, I need your help! I am struggling to merge the master into this branch. It had many changes you had made but also changes that should not get lost (esp. to Table 1:12.1-1. SDPi-A Profile - Actors and Transactions). I tried resolving conflicts in my IDE and Github, but I seem to not fully manage. My last commits keep failing...
In the last one I manually recreated your changes, although I skipped all that have to do with the automatic generation of that table, because that would stomp on my changes to the table...

[PaulMartinsen]

Hi @JavierEspina is the problem that the document isn't building or are the branches not merging? That is, does the latest commit contain the document changes you want from this branch + master and we need to fix the document building or have some of the changes from master not come across?

In the build output I see the error Profile option alert_delegation requires an oid-arcs. Which means, around line 306,
[#vol1_clause_sdpi_a_actor_option_alert_delegation,role=profile-option,profile-option-id=alert_delegation] is missing an oid-arcs attribute. You can see the next value to use in 3:C.6, E.g.,
[#vol1_clause_sdpi_a_actor_option_alert_delegation,role=profile-option,profile-option-id=alert_delegation,oid-arcs=.7]

I'll take a closer look later today to see if it is just the missing oid that's causing a build problem.

[PaulMartinsen]

Turns out it was a bit more subtle than a missing oid arc. Looks like a few things got broken in the merge. Looking over tf1-ch-12-sdpi-a.adoc I found and resolved:

• the SDPi-A Profile - Actors and Transactions table was back into tf1-ch-12-sdpi-a.adoc. These tables got moved to volume1\actor-tables\sdpi-a-transactions.adoc. I updated that file with the changes from tf1-ch-12-sdpi-a.adoc and added the include::actor-tables/sdpi-a-transactions.adoc[] to merge it in.
• the ==== Alert Delegation Option was defined in two places. One had an oid and was mixed in with the definition of the distributed alarm system. I separated them out.
• the alert_user_acknowledgement and remote_alert_signaling options lost their oids which I added back.
• the sdpi_support_use_cases got lost; back now.

It builds locally; let's see if github can do it...

[PaulMartinsen]

Looks like it is building now.

In other news:

• I added markup for the new transactions.
• The markup to include transactions in the sdpi-a profile to include them in json artefacts appears to be gone; I'll look into that tomorrow.
• Markup for the Distributed Alarm System Option is missing.

[JavierEspina]

THANK you, Paul!
I am going to have a look at all that fixing you've been doing. I hope I won't make any damage 😇

[JavierEspina]

Looks like it is building now.

In other news:

• I added markup for the new transactions.
• The markup to include transactions in the sdpi-a profile to include them in json artefacts appears to be gone; I'll look into that tomorrow.
• Markup for the Distributed Alarm System Option is missing.

With my last two commits, I may have done the " Markup for the Distributed Alarm System Option " but have not checked the box so you can verify that I did it well and did not forget any detail somewhere.

[ToddCooper]

@JavierEspina - so remind me ...
Default is DIS and we have an option for DAS support. Yes?
Let me know when I should download a build to review especially the TF-1 SDPi-A stuff.

[JavierEspina]

@JavierEspina - so remind me ... Default is DIS and we have an option for DAS support. Yes? Let me know when I should download a build to review especially the TF-1 SDPi-A stuff.

Yes, by default a DIS. DAS is an option. When the DAS option is selected transactions DEV-48 and DEV-49 kick in (i.e., become mandatory)

You may want to download a build already to see how things are currently looking. There is no complete description of all steps in DEV-48 or -49 but the idea is there.

[PaulMartinsen]

Starting to look over adding in markup for the transactions I notice that in DEV-49, the alert provider is both a responder and initiator in the text but the alert consumer is listed only as an initiator. If the alert provider initiates this transaction wouldn't the alert consumer be at least a receiver as well?

[PaulMartinsen]

@JavierEspina , the markup for the Distributed Alarm System Option looks good to me. The markup doesn't support a transaction making multiple contributions (e.g., responder and initiator) currently so I'm going to have to add that to make the json export work.

What's the plan for merging this one? I could tackle this as a separate issue if you're in a hurry to merge it. Json exports would be incomplete in the meantime.

[JavierEspina]

Starting to look over adding in markup for the transactions I notice that in DEV-49, the alert provider is both a responder and initiator in the text but the alert consumer is listed only as an initiator. If the alert provider initiates this transaction wouldn't the alert consumer be at least a receiver as well?

You're right. It is not consistent right now. The first table of SDP-i A shows both actors and both initiator and responder. So does the diagram in the DEV-49 section. However the actor roles table in that section does not. I am going to correct this in my next commit...or at least try!

[JavierEspina]

@JavierEspina , the markup for the Distributed Alarm System Option looks good to me. The markup doesn't support a transaction making multiple contributions (e.g., responder and initiator) currently so I'm going to have to add that to make the json export work.

What's the plan for merging this one? I could tackle this as a separate issue if you're in a hurry to merge it. Json exports would be incomplete in the meantime.

My current expectation is to move this PR from draft to an actual PR (i.e. content complete for review for merging) within 1-2 weeks (maybe even 3). If that provides you with sufficient time to make that fix in this PR, I'd say: go ahead!

[PaulMartinsen]

Ok. 1 week might be a little challenging, but 2-3 should work. I'll make a start and can either include it or move to a separate issue if you are ready to merge first.