Activity for Anna Feiler
-
Anna Feiler modified ticket #82
Typo in Clause 6.3.1 AlertSignalDescritpor -> AlertSignalDescriptor
-
Table 9 and related requirements have already been fixed in other tickets. B.128 needs to be checked for consistency with new solution.
-
Correct biceps:Table 9 and biceps:R0114 and biceps:B.128.
-
Clarify scope of clause 6
-
B.196 CodedValue/Translation/@CodingSystem should get implied value
-
Will also reinsert clause 6, since deletion is not possible in the scope of the Corrigendum - see [#382] and [#383]
-
Clarify scope of clause 6
-
Align clause 6 with APKP
-
Clarify scope of clause 6
-
B.30 Fix typo "operarting cycles"
-
B.196 CodedValue/Translation/@CodingSystem should get implied value
-
needs further discussion with Stefan
-
for [#212] fix consider rephrsing the definition of "Auto" and "Man"
-
ClockState@DateAndTime handling
-
needs further discussion with Stefan.
-
check if this is a valid approach for a corrigendum, maybe rephrase to be consistent with [#366] rather than remove.
-
R0057: Delete or rephrase
-
Not allowed in corrigendum, rephrase to be consistent with [#366]
-
see [#136] for replacement
-
R0013: Requirement is misleading and partly obsolete due to SDC participant ensembles
-
forward fix using BPKP is not allowed in Corrigendum
-
R0103: requirement text is misleading; the requirement does not add value
-
R0103: requirement text is misleading; the requirement does not add value
-
Remove Clause 6
-
Ok for Corrigendum, simply removes an imprecise statement that does not impact the scope or content of the section.
-
B.231 Tweak LimitAlertConditionDescriptor documentation
-
R5053 is wrongly scoped
-
-
R0139: rephrase such that advisory changes do not trigger alert system state updates
-
R0139: rephrase such that advisory changes do not trigger alert system state updates
-
B.231 Tweak LimitAlertConditionDescriptor documentation
-
5.3.12.3 - Attribute pm:Availability misspelled
-
R5050: remove requirement
-
Correct biceps:Table 9 and biceps:R0114 and biceps:B.128.
-
Change Table 9 / row 23
-
Table 9 / first row contradicts with R0116
-
Relationship between alert activation states
-
solved in [#378]
-
Table 9 / first row contradicts with R0116
-
solved in [#378]
-
Change Table 9 / row 23
-
solved in [#378]
-
Table 9 / row 13
-
solved in [#378]
-
Table 9 / row 25 (last row) contradicts with R0116
-
solved in [#378]
-
example in note 2 of R0114 contradicts table 8
-
solved in [#378]
-
R0129, R0115 & R0130: Rephrase or remove
-
solved in [#378]
-
B.128 SystemSignalActivation event/duration requirement
-
solved in [#378]
-
solved in [#378]
-
solved in [378]
-
Replace table 9
-
solved in https://github.com/ornet-ev/biceps/pull/142
-
Replace table 9
-
R0025: what does "in advance" implicate?
-
Replace table 9
-
Updated Table 9 including suggestions from Björn
-
Updated Table 9 including suggestions from Björn
-
B.231 Tweak LimitAlertConditionDescriptor documentation
-
Replace table 9
-
@cledoux did an in depth analysis of the existing table 9 as well as the full disclosure one from [#13]. It was found that the content and original intention of table 9 and 10 as well as the existing requirements surrunding them, can be corrected by introducing the following requirements: Reworked R0029: For each pm:AlertConditionState, while @Presence = true, a SERVICE PROVIDER SHALL set this pm:AlertConditionState/@ActivationState = On and the pm:AlertSystemState/@ActivationState = On of the ALERT...
-
@cledoux did an in depth analysis of the existing table 9 as well as the full disclosure one from [#13]. It was found that the content and original intention of table 9 and 10 as well as the existing requirements surrunding them, can be corrected by introducing the following requirements: Reworked R0029: For each pm:AlertConditionState, while @Presence = true, a SERVICE PROVIDER SHALL set this pm:AlertConditionState/@ActivationState = On and the pm:AlertSystemState/@ActivationState = On of the ALERT...
-
@cledoux did an in depth analysis of the existing table 9 as well as the full disclosure one from [#13]. It was found that the content and original intention of table 9 and 10 as well as the existing requirements surrunding them, can be corrected by introducing the following requirements: Reworked R0029: For each pm:AlertConditionState, while @Presence = true, a SERVICE PROVIDER SHALL set this pm:AlertConditionState/@ActivationState = On and the pm:AlertSystemState/@ActivationState = On of the ALERT...
-
@cledoux did an in depth analysis of the existing table 9 as well as the full disclosure one from [#13]. It was found that the content and original intention of table 9 and 10 as well as the existing requirements surrunding them, can be corrected by introducing the following requirements: Reworked R0029: For each pm:AlertConditionState, while @Presence = true, a SERVICE PROVIDER SHALL set this pm:AlertConditionState/@ActivationState = On and the pm:AlertSystemState/@ActivationState = On of the ALERT...
-
@cledoux did an in depth analysis of the existing table 9 as well as the full disclosure one from [#13]. It was found that the content and original intention of table 9 and 10 as well as the existing requirements surrunding them, can be corrected by introducing the following requirements: Reworked R0029: For each pm:AlertConditionState, while @Presence = true, a SERVICE PROVIDER SHALL set this pm:AlertConditionState/@ActivationState = On and the pm:AlertSystemState/@ActivationState = On of the ALERT...
-
@cledoux did an in depth analysis of the existing table 9 as well as the full disclosure one from [#13]. It was found that the content and original intention of table 9 and 10 as well as the existing requirements surrunding them, can be corrected by introducing the following requirements: Reworked R0029: For each pm:AlertConditionState, while @Presence = true, a SERVICE PROVIDER SHALL set this pm:AlertConditionState/@ActivationState = On and the pm:AlertSystemState/@ActivationState = On of the ALERT...
-
@cledoux did an in depth analysis of the existing table 9 as well as the full disclosure one from [#13]. It was found that the content and original intention of table 9 and 10 as well as the existing requirements surrunding them, can be corrected by introducing the following requirements: Reworked R0029: For each pm:AlertConditionState, while @Presence = true, a SERVICE PROVIDER SHALL set this pm:AlertConditionState/@ActivationState = On and the pm:AlertSystemState/@ActivationState = On of the ALERT...
-
Table 9 - full disclosure with comments from Clément
-
@cledoux did an in depth analysis of the existing table 9 as well as the full disclosure one from [#13]. It was found that the content and original intention of table 9 and 10 as well as the existing requirements surrunding them, can be corrected by introducing the following requirements: Reworked R0029: For each pm:AlertConditionState, while @Presence = true, a SERVICE PROVIDER SHALL set this pm:AlertConditionState/@ActivationState = On and the pm:AlertSystemState/@ActivationState = On of the ALERT...
-
Replace table 9
-
Replace table 9
-
Table 9 - full disclosure with comments from Clément
-
@cledoux did an in depth analysis of the existing table 9 as well as the full disclosure one from [#13]. It was found that the content and original intention of table 9 and 10 as well as the existing requirements surrunding them, can be corrected by introducing the following requirements: Reworked R0029: For each pm:AlertConditionState, while @Presence = true, a SERVICE PROVIDER SHALL set this pm:AlertConditionState/@ActivationState = On and the pm:AlertSystemState/@ActivationState = On of the ALERT...
-
B.231 Tweak LimitAlertConditionDescriptor documentation
-
@cledoux did an in depth analysis of the existing table 9 as well as the full disclosure one from [#13]. It was found that the content and original intention of table 9 and 10 as well as the existing requirements surrunding them, can be corrected by introducing the following requirements: Reworked R0029: For each pm:AlertConditionState, while @Presence = true, a SERVICE PROVIDER SHALL set this pm:AlertConditionState/@ActivationState = On and the pm:AlertSystemState/@ActivationState = On of the ALERT...
-
5.3.12.3 - Attribute pm:Availability misspelled
-
R5050: remove requirement
-
Wrong descriptor version in MDIB versioning example (fig. D.9)
-
B.30 Fix typo "operarting cycles"
-
Typo in Clause 6.3.1 AlertSignalDescritpor -> AlertSignalDescriptor
-
B.30 Fix typo "operarting cycles"
-
implied values, esp. in pm:DerivationMethod
-
In B.36, Delete: The default value SHALL be applied, depending on pm:AbstractDescriptor/@MetricCategory. — If pm:AbstractDescriptor/@MetricCategory is "Set" or "Preset", then the default value of DerivationMethod is "Man" — If pm:AbstractDescriptor/@MetricCategory is "Clc", "Msrmt", "Rcmm", then the default value of DerivationMethod is "Auto" — If pm:AbstractDescriptor/@MetricCategory is "Unspec", then no default value is being implied Open an additional ticket for the revision for the implied values....
-
implied values, esp. in pm:DerivationMethod
-
In B.36, Delete: The default value SHALL be applied, depending on pm:AbstractDescriptor/@MetricCategory. — If pm:AbstractDescriptor/@MetricCategory is "Set" or "Preset", then the default value of DerivationMethod is "Man" — If pm:AbstractDescriptor/@MetricCategory is "Clc", "Msrmt", "Rcmm", then the default value of DerivationMethod is "Auto" — If pm:AbstractDescriptor/@MetricCategory is "Unspec", then no default value is being implied Open an additional ticket for the revision for the implied values....
-
Implied values
-
B.283 MdsState/@OperatingMode case-sensitivity issue
-
MDIB definition suggests single MEDICAL DEVICE
-
B.283 MdsState/@OperatingMode case-sensitivity issue
-
MetricValue consistency
-
Add requirement:in the time-related attributes section: "pm:AbstractMetricValue/@StartTime SHALL NOT be earlier than pm:AbstractMetricValue/@DeterminationTime." NOTE- The SERVICE PROVIDER can either announce the start of a new measurement by using pm:AbstractMetricValue/pm:MetricQuality/@Validity=Ong with a new pm:AbstractMetricValue/@StartTime or it can continue to provide the previous value. It cannot indicate the start of a new measurement and retain the previous value, because the pm:AbstractMetricValue/@StartTime...
-
Keep previous metric value during ongoing measurements
-
MetricValue consistency
-
C.135 AbstractSet/OperationHandleRef typo
-
C.139 InvocationInfo/TransactionId typo
-
Clarify definition of @DeterminationTime
-
implied values, esp. in pm:DerivationMethod
1 >
