Introduction
Documentation
Syntax
|
|
| Documentation
|
A validity may be made up of an OperatingDayValidity. This kind of validity may be used in early planning stages, when the precise dates are not clear yet. It allows describing that an operation takes place on a certain day of the week.
|
| Subschema
|
timetable
|
| Parents*
|
validity
|
| Children
|
None
|
Attributes:
- timetableScenarioRef: Optional reference to a timetable scenario. (optional;
xs:IDREF),
- pattern: 7-character field with 0 or 1 for each day of the week, the first day of the week being a Monday. A 0 indicates a non-operating day, while a 1 indicates an operating day. (obligatory;
xs:string; length: 7; patterns: [0-1]{7}),
- publicHolidayMode: Indicates how the enclosing validity operates in regards to public holidays.
Default value is runsOnIndicatedHolidays. (optional; xs:string)
- Possible values:
- neverRunsOnHolidays: Indicates that the validity does not apply on all public holidays no matter if the specified pattern is marked with one for that day. Trains referencing a validity with this value set will not run on public holidays.
- runsOnAllHolidays: Indicates that the validity applies on all public holidays. This means that no matter what is specified via the bitMask, the validity will apply and a train using this validity is scheduled to run.
- runsOnIndicatedHolidays: Indicates that the validity applies even if a day is a public holiday.
|
*Notice:
Elements may have different parent elements. As a consequence they may be used in different contexts.
Please, consider this as well as a user of this Wiki as when developing this documentation further.
Aspects that are only relevant with respect to one of several parents should be explained exclusively in the documentation of the respective parent element.
|
|
|
| Documentation
|
A validity may be made up of an OperatingDayValidity. This kind of validity may be used in early planning stages, when the precise dates are not clear yet. It allows describing that an operation takes place on a certain day of the week.
|
| Subschema
|
timetable
|
| Parents*
|
validity
|
| Children
|
None
|
Attributes:
- timetableScenarioRef: Optional reference to a timetable scenario. (optional;
xs:string; patterns: (urn:uuid:)?[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}|{[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}}),
- pattern: 7-character field with 0 or 1 for each day of the week, the first day of the week being a Monday. A 0 indicates a non-operating day, while a 1 indicates an operating day. (obligatory;
xs:string; length: 7; patterns: [0-1]{7}),
- publicHolidayMode: Indicates how the enclosing validity operates in regards to public holidays. (optional;
xs:string)
- Possible values:
- neverRunsOnHolidays: Indicates that the validity does not apply on all public holidays no matter if the specified pattern is marked with one for that day. Trains referencing a validity with this value set will not run on public holidays.
- runsOnAllHolidays: Indicates that the validity applies on all public holidays. This means that no matter what is specified via the bitMask, the validity will apply and a train using this validity is scheduled to run.
- runsOnIndicatedHolidays: Indicates that the validity applies even if a day is a public holiday.
|
*Notice:
Elements may have different parent elements. As a consequence they may be used in different contexts.
Please, consider this as well as a user of this Wiki as when developing this documentation further.
Aspects that are only relevant with respect to one of several parents should be explained exclusively in the documentation of the respective parent element.
|
This element does not appear in railML® 3.1 within the TT subschema. It is available only in railML® 3.2, 3.3. Do not hesitate to contact railML.org for further questions.
Changes 3.1→3.2
There exists an overview of all changes between railML® 3.1 and railML® 3.2 on page Dev:Changes/3.2.
Introduced with version 3.2.
Changes 3.2→3.3
There exists an overview of all changes between railML® 3.2 and railML® 3.3 on page Dev:Changes/3.3.
The parents have been changed.
The attributes have been changed.
Semantics
Best Practice / Examples
Additional Information
Notes
Open Issues