...
Annotations may be associated with both individual Timesheet and the classes that are derived from PropertiesWithSchedule, the later being used for annotations (remarks) that concern the whole timetable.
The data type or the list of allowable values associated with each Timesheet attribute are listed in the following diagram.
Model principles and limitations
Order of priorities
There is no explicit "priority indicator" attribute for a Timesheet. However, there exists a natural order of priorities that shall be applied when Timesheet are interpreted. This concerns:
- the day attribute, where the values shall be interpreted in the following order of priorities (values that are first in the list overrule values that are later in the list): 'HOL', 'BEF_HOL', 'AFT_HOL', 'WORK_DAY', 'BEF_WORK_DAY', 'AFT_WORK_DAY', 'BUSY_FRI', 'MON', 'TUE', 'WED', 'THU', 'FRI', 'SAT', 'SUN', 'ANY'
- the excluded attribute, where Timesheet that are have excluded="YES" take precedence over other Timesheet.
Overlapping times from different timesheets
If two or more non-excluded timesheets refer to the same date, day and/or time period, then the resulting time period shall be derived by applying the order of priority rules.
End of day format
According to ICAO Annex 15, Appendix 6, NOTAM Format, "the end of a day shall be indicated by '2359'". In static data (AIP) the end of the day is usually indicated by "2400". ICAO Annex 10 states that "3.4.1 Universal Co-ordinated Time (UTC) shall be used by all stations in the aeronautical telecommunication service. Midnight shall be designated as 2400 for the end of the day and 0000 for the beginning of the day."
In addition, feedback from developers having used the AIXM Temporality Concept show that using "23:59" as end of day in digital data is problematic because it requires a special interpretation for comparison operators: 23:59:01 is numerically higher than 23:59 and therefore is numerically after the end time. However, in the NOTAM practice, 23:59:01 is still considered inside a time interval that ends at 23:59.
To avoid such problems, the end of the day in digital data shall be indicated as 24:00. However, in order to remain compliant with the ICAO Annex 15 requirements for NOTAM format (item C in particular), this shall be translated into "2359", when the NOTAM is generated automatically.
Weekday range
The concept of "weekday ranges" (such as "MON-WED") is not directly supported in AIXM because sometimes there are confusions between MON-FRI and "working days".This does not exclude implementing an HMI that allows the input of weekday ranges, for efficiency reasons. They will have to be converted into individual week days in AIXM.
From date & time to date & time
Schedules in the form "from date & time" - "to date & time" (such as "MAR 02 09:00 - 09 16:00") are not supported. The startTime and endTime properties are, by definition, related only to day and/or dayTill. It is also highly questionable if such schedules are really needed, as they most likely correspond to feature lifetimes, which need to be encoded as timeslice validity times, not as schedules.
Excluded timesheets
It is not possible to indicate that a Timesheet with excluded="YES" concerns only another (not excluded) Timesheet or just a subset of other Timesheet. The exclusion is general, it has to be subtracted from all not excluded timesheets.
Same hours as..
The encoding of operational dependencies, such as a service having the same working hours as the airport administration, etc. are not supported. When considered necessary to be modelled, such operational dependencies are indicated with explicit associations between the features concerned.
Twilight
There is no code for "twilight" in the current model, only sunrise/sunset can be used. The explicit SR/SS +/- 30 minutes (or another value) needs to be encoded.