...
Identifier | Data encoding rule | RemarkRemarks (column to be deleted at the end) |
---|---|---|
ER-01 | Each use of "daily", "on date", "date range", "on weekday", or "from weekday...to weekday" shall be encoded as a single Timesheet, according to the mapping table. (to be deleted) | The rule could be deleted from here. A new rule chould be put under the common coding part: Each use of "daily", "on date", "date range", "on weekday", or "from weekday...to weekday" shall be encoded as a single Timesheet, according to the [TS] and [/TS] indications in the graphical elements mapping tables. Note: There exists already an indication in the common coding patterns, that separate Timesheets are needed but they are mentioned with respect to the diagrams. Probably needs to be deleted. |
TSH.EVT--01 | All Timesheets shall get timeReference=UTC and daylightSavingAdjust=NO. Even the periods recuperated from the baseline data to fill in the gaps need to be converted to UTC. | |
ER-03 | If "on date" is used, then both the Timesheet.startDate and the Timesheet.endDate shall get the value specified for "on date". (to be deleted) | The rule could be deleted from here. A new rule chould be put under the common coding part: If the Timesheet is related to one single date, both the Timesheet.startDate and the Timesheet.endDate shall get the value specified for that date. |
ER-04 | If "on date" or "date range" are used, then Timesheet.day shall get the value "ANY" and Timesheet.dayTill shall be left empty. (to be deleted) | The rule could be deleted from here. A new rule chould be put under the common coding part: If the Timesheet is related to one single date or date range, then Timesheet.day shall get the value "ANY" and Timesheet.dayTill shall be left empty. |
ER-05 | If "daily", "on weekday" or "from weekday...to weekday" are used, then in the corresponding Timesheet(s) both startDate and endDate shall be left empty. (to be deleted) | The rule could be deleted from here. A new rule chould be put under the common coding part: If the Timesheet is related to one single date, a weekday or time interval spreading over multiple weekdays then in the corresponding Timesheet(s) both startDate and endDate shall be left empty. |
ER-06 | If "on weekday" is used, then Timesheet.day shall get that value and Timesheet.dayTill shall be left empty.(to be deleted) | The rule could be deleted from here. A new rule chould be put under the common coding part: If the Timesheet is related to a weekday then Timesheet.day shall get that value and Timesheet.dayTill shall be left empty. |
TSH.EVT-02 | If excluded date is used, then it shall be encoded as one Timesheet that has excluded=YES, startTime=00:00 and endTime=24:00; startDate and endDate shall both get the value specified for "exc. date". | I suggest to keep the rule here due to the time reference limitation. The common rules contain already an indication regarding excluded date, but require to be coded having timeReference='UTC+/-X' (local time as UTC zone). |
TSH.EVT-03 | The values WORK_DAY, BEF_WORK_DAY, AFT_WORK_DAY, HOL, BEF_HOL, AFT_HOL and BUSY_FRI cannot be used in Timesheet.day or Timesheet.dayTill. | |
TSH.EVT-04 | According to the OPADD, item D is not allowed to exceed 200 characters. The application interface should check the length of the item D that results from the schedule encoding and invite the operator to split the NOTAM into two separate events in case this limit is exceeded. The HMI should allow copying a draft event into a second draft event. | |
ER-10 | It is not allowed to use "overnight" time periods in Event Schedules, e.g. 2200-0600. These shall be split into two separate time periods, e.g. 2200-2400 and 0000-0600.(to be deleted) | The rule could be deleted from here. A new rule chould be put under the common coding part: It is not allowed to use "overnight" time periods in Schedules, e.g. 2200-0600. These shall be split into two separate time periods, e.g. 2200-2400 and 0000-0600. |
ER-11 | If a schedule is more complex than the ones supported by the Templates provided for this scenario, then it shall be described in as a free text "note".(to be deleted) | The rule could be deleted from here. A new rule chould be put under the common coding part: If a schedule is more complex than the types provided, then it shall be described in as a free text "note". |
...