Optimization for Validity Period definition

Submitted by Fabrizio.Paoletti on Wednesday, 3 October, 2012 - 15:29
Issue ID
109
Component
UML General
Category
Bug report
Priority
Normal
Assigned
Status
Won't fix
Source
Website
Description

Currente Implementation of the model give a chance to define a situaton record that remain valid for some time using the Overall Period adding information for Valid Period and Invalid Period in which the situation record is not currently valid. 

Once having specified the Overall Period ( in which the situation record is supposed to be valid implicitely ) the  usage of Valid Period could lead to some misunderstandig: in case for the same days or period of time both an invalidPeriod and also a validPeriod is defined.

as Valid Period allows to give information on day per week and time for days the situation record is Valid
the exception period should differ as being used just to indicate the period in which the situation record is not valid against any associated  Validity period, i.e. a ierarchy is seen in interpreting Valid and Invalid Period so that the Invalid Period need to be prioritized

Otherwise if both Validity and Invalidity period are assumed at same levele we could specify the same day as Valid and Invalid and no rule would allow us to understand the proper state for the situation record in that day

definition of exception period would be enough for this

validPeriod
"A single time period, a recurring time period or a set of different recurring time periods during which validity is true if no invalidPeriod is associated in the same period.."

invalidPeriod
"A single time period, a recurring time period or a set of different recurring time periods during which validity is false.."

otherwise there would be a need to redesign classes and/or relationships associating an Invalid Period only to a Valid Period and not to the overall Period to obtain a similar description.
 

Found Version
{"changeLogs":[{"date":1528371574712,"componentOLD":"- Select a value -","component":"UML General","categoryOLD":"- Select a value -","category":"Bug report","priorityOLD":"- None -","priority":"Normal","assignedOLD":"","assigned":"Josef Kaltwasser (18)","statusOLD":"- None -","status":"Won't fix"},{"date":1537269376153}]}

Posted by Joerg Freudenstein on June 14, 2025 Permalink

In another context, I wrote down some explanation for the DATEX validity model, including a figure for better understanding.
I attached it as PDF for your interest.

I think it goes along with the concern in this issue.

(Remarks are welcome, expecially if someone thinks, something might be wrong).

*EDIT* I'm not able to attach the file here, so I will send it per Mail.

Posted by Josef Kaltwasser on November 14, 2024 Permalink

I don’t think the current definition is ambiguous or weak. I also think it specifies already exactly what you are asking for. The definition of OverallPeriod says “A continuous or discontinuous period of validity defined by overall bounding start and end times and the possible intersection of valid periods (potentially recurring) with the complement of exception periods (also potentially recurring).” If you look at this, the definition of non-valid periods does indeed have “priority” since the mathematical definition of an intersection requires ALL three contributions to state validity, which is not the case in invalid periods. I would actually prefer to keep the current definition since it is mathematically clear.

Posted by Fabrizio.Paoletti on November 14, 2024 Permalink

the ambigous way of usage we found in Validity Time Spec is explained :

you can use validity ( valid period and invalid period) in a dual mode

e.g. roadworks for a period of two months on monday to friday weekly base

after issuing an Overall Period ( Overall Start and Overall End ) you can

1) set a validity period Mon to Fri

2) set an invalid period Sat to Sun ( set as invalid the complementary time )

3) define a set of Validity Period for each week Mon to Fri, not using the concept of recurring day per week

4) etc etc etc

in order to avoid a multiple ( potentially huge) valid implementation option for the same concept it should be convenient to add some constraint and state that we have a valid period (positive assesment of valid period) to be set ( when necessary besides overall period) and use invalid period only for exception period

the scope would be to semplify giving guidance on usage of Invalid and Valid period not allowing a scattered usage of the 2 classes, but give some clear priority rules to set and use these classes.