Re: constraints for OperatingPeriod [message #815 is a reply to message #813] |
Tue, 02 October 2012 17:34 ![Go to previous message Go to previous message](/forum/theme/default/images/up.png) ![Go to next message Go to previous message](/forum/theme/default/images/down.png) |
Dirk Bräuer
Messages: 311 Registered: August 2008
|
Senior Member |
|
|
Dear Andreas,
when the current operatingPeriod type was defined, the aim was to
explicitly allow a 'describing' definition and a bitMask redundantly. The
background is that there are many 'describing' expressions for the same
bitmask. For instance: "Mo-Fr, 01.08-31.08 only" and "[Sa+So], not until
31.07 and not from 01.09." lead to the same bitmask.
In some cases,
- we do want to have the bitmask for easier and clearer reading of the
real operating days,
- we do want to have the 'describing' expressions to exactly reconstruct
the input of the user, meaning to 'show' the contents of the bitmask to
the user in a kind which is familiar for him and which reflects the input.
If the user did input "Mo-Fr[S]", he should not be shown "W[Sa]" and vice
versa.
Please have a look at the examples in
www.irfp.de/download/railml_beispiel_verkehrstage.pdf
This means that
> - the calendar based operating period:
> -- bitmask and startDate are mandatory,
> -- endDate, operatingDay, specialService are not allowed.
would not fit to the current requirements.
---
Concerning a 'third' combination
> - abstract operating period
> -- name or code are mandatory
> -- bitmask, operatingDay, specialService are not allowed.
I would welcome such a possibility. But, from my side we need a definition
whether different 'abstract operating periods' are disjunctive or not.
Either we define a matrix or, at least, we define that different 'abstract
operating periods' _always_ have to be disjunctive.
Additionally, I would prefer to allow an abstract operating period to
refer to a 'real' operating period. In my opinion, any abstract operating
period earlier or later becomes real. So, we can have a timetable which
was planned with abstract operating periods (in the first instance) but in
the meantime, the user does know which real dates are assigned to which
abstract operating period.
So, an abstract operating period can have
- either a bitmask (at least)
- or a reference to another (non-abstract) operating period.
From these suggestions, I would prefer
- 'abstract operating periods' always have to be disjunctive
- 'abstract operating periods' can optionally reference another
(non-abstract) operating period.
Best regards,
Dirk.
|
|
|