Hi all (again),
Some more discussions on incidents from archives:
Ability to pass an IncidentID to a prescription: Three thumbs up.
For this one we don’t really need to do anything, as the spec provides this capability anyway (i.e. Syndrome signature may return a collection of symptoms, and then the Protocol directive can extract any kind of arguments to pass down to the prescription).
Paul discussed a higher level context such as when the Headaches are
caused by Pollution which is caused by poor Environmental Oversight.
It's a tiering of Incidents something like this...
All of these Incidents are related to poor Environmental Oversight:
IncidentID=A1 -- symptom1="increased pollution"
IncidentID=A2 -- symptom1="improper environmental spending"
All of these Incidents are related to Pollution:
IncidentID=B1 -- symptom1="slight headache" symptom2="severe headache"
IncidentID=B2 -- symptom1="dirty windows"
IncidentID=B3 -- symptom1="bad tasting drinking water"
In Paul's scenario, some kind of UberIncidentID would link together the
Pollution symptoms, and a UberUberIncidentID would link together the
Environmental Oversight symptoms.
It seems unlikely that a simple symptom emitter would be able to provide
these Uber*IncidentIDs. So maybe these kinds of relationships are
defined elsewhere, and leveraged by the Diagnostian.
Alvin: UberIncidentID: Two thumbs up on the notion that we need to somehow
support a complex linking of related symptoms... I think we might have
to get more sophisticated though.
Question: is the above not covered if we decide to support multiple incident IDs? I.e. a symptom would have three incident IDs: the direct incident one, the UberIncident and the UberUberIncident one :-)