Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

IdentifierData encoding ruleRemarks (column to be deleted at the end)
ER-01Each 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--01All 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-03If "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-04If "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-05If "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-06If "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-02If 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-03The 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-04According 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-10It 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-11If 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".

...