TT:specialService operatingPeriod

From railML 2 Wiki
Jump to navigation Jump to search


specialService
 


Schema description / Schemabeschreibung

Position of specialService in the XML-Tree / Position von specialService im XML-Baum

Multiplicity / Anzahl

[0..∞]

Semantics / Bedeutung

The Element <specialService> describes a calendar based modification of the operatingPeriod by including or excluding certain days or periods. The maximal duration of the underlying timetablePeriod and operatingPeriod may not be expanded with a this <specialService>.

There are 2 options for specifying the days on which the modification described here is valid. On the one hand, the @singleDate attribute can be used to describe a validity limited to a single day. Alternatively, the validity can be defined using a combination of the attributes @startDate/@endDate, possibly together with @startTime/@endTime. If no @startTime is specified, then it must be assumed that the validity refers to the entire specified @startDate. If no @endTime is specified, then it must be assumed that the validity refers to the entire specified @endDate. If no @startDate is specified, it must be assumed that the validity begins with the <operatingPeriod>; if no @endDate is specified, it must be assumed that the validity ends with the <operatingPeriod>. Specifying neither @singleDate, @startDate or @endDate, although syntactically possible, makes no sense for this element.

Das Element <specialService> beschreibt die auf einen Kalender bezogene Modifizierung einer Verkehrsperiode operatingPeriod um einzelne Zusatz- und/oder Ausfalltage oder auch Zusatz- und/oder Ausfallperioden. Die maximale Dauer der zugrundeliegenden Fahrplanperiode timetablePeriod beziehungsweise der darauf basierenden Verkehrsperiode operatingPeriod darf dabei aber nicht erweitert werden.
Um festzulegen, an welchen Tagen die hier beschriebene Modifizierung gültig ist, gibt es 2 Möglichkeiten. Einerseits kann das Attribut @singleDate genutzt werden um eine Gültigkeit beschränkt auf einen einzelnen Tag zu beschreiben. Alternativ kann die Gültigkeit über eine Kombination der Attribute @startDate/@endDate, ggf. zusammen mit @startTime/@endTime. Wenn keine @startTime angegeben wird, dann muss angenommen werden, dass die Gültigkeit sich über den gesamten angegebenen @startDate bezieht. Wenn keine @endTime angegeben wird, dann muss angenommen werden, dass die Gültigkeit sich über den gesamten angegebenen @endDate bezieht. Wird kein @startDate angegeben, muss angenommen werden, dass die Gültigkeit zusammen mit der <operatingPeriod> beginnt, wird kein @endDate angegeben, muss angenommen werden, dass die Gültigkeit mit der <operatingPeriod> endet. Weder @singleDate, @startDate oder @endDate anzugeben, obwohl syntaktisch möglich macht für dieses Element keinen Sinn.


Please, be aware of the semantic constraint(s)!

Attributes of specialService / Attribute von specialService

  • type: It has to follow the constraints of xs:string. Possible values are:
  • singleDate: This is used to include or exclude a single day.
  • startDate: This is used to include or exclude a time period. Please, take notice of the semantic constraint.
  • endDate: This is used to include or exclude a time period. Please, take notice of the semantic constraint.
  • startTime: This is used for a more detailed description of the time period.
    (deprecated with version 2.4)
  • endTime: This is used for a more detailed description of the time period.
    (deprecated with version 2.4)
  • xs:anyAttribute(introduced with version 2.3) This provides an extension point for non-railML® attributes in a foreign namespace. How to use it?

Syntactic Constraints / Syntaktische Beschränkungen

  • startTime xs:time, optional; shall be lower or equal endDate if both are used.
  • endTime xs:time, optional; shall be higher or equal startDate if both are used.

Semantic Constraints / Semantische Beschränkungen

Private-cloud-icon.png Semantic Constraint "CO:002":
 
Relation of starting and ending timestamps of a time period
 
Any starting time stamp (as it may result e.g. from a combination of startDate and startTime) shall be lower or equal any ending time stamp (e.g. endDate) if both are given.
 
Proposed on November 12th 2018
Approved on March 21st 2019
FIXME Forum missing

Please, recognize our guidelines on semantic constraints 

Private-cloud-icon.png Semantic Constraint "TT:021":
 
Within the same <operatingPeriod> element, a date must not be contained in more than one <specialService> element.
 
Proposed on February 13th 2025
Approved on April 07th 2025
https://www.railml.org/forum/index.php?t=msg&th=1014&start=0&

Please, recognize our guidelines on semantic constraints 

Private-cloud-icon.png Semantic Constraint "TT:022":
 
The values of @singleDate, @startDate and @endDate of <specialService> must not be outside of the time period defined in the enclosing <operatingPeriod>.
 
Proposed on February 13th 2025
Approved on April 07th 2025
https://www.railml.org/forum/index.php?t=msg&th=1014&start=0&

Please, recognize our guidelines on semantic constraints 

Best practice & Examples / Empfohlene Anwendung & Beispiele

<specialService type="include" singleDate="2009-12-24"/>


Weitere Informationen und railML®-Beispiel zu Verkehrstagen (externer Link, PDF; 185 kBytes)

Explanation of TT021

Semantic constraint means that the range of days as well as a single date given in special services must not overlap because they might:]

1) contradict each other;

2) introduce redundancy.

Both cases shall be avoided.

It is not assumed that the range is always provided with either both of @startDate and @endDate or @singleDate. The specialService defined by only @startDate or only @endDate implies the missing date from parent operatingPeriod.

Although there is no restriction that a single date can be also given with @startDate and @endDate date of the same value, it’s recommended to define a single day special services with @singleDate attribute.

The intersection of the ranges of days given in special services can be defined by either of the combinations:

1) Intersection of ranges

   specialSevice[@id=”sp1”]/@startDay 
   specialSevice[@id=”sp1”]/@endDay 
   specialSevice[@id=”sp2”]/@startDay 
   specialSevice[@id=”sp2”]/@endDay

2) Intersection of a range and a single date

   specialSevice[@id=”sp1”]/@startDay 
   specialSevice[@id=”sp1”]/@endDay 
   specialSevice[@id=”sp2”]/@singleDate

3) Intersection of single dates

   specialSevice[@id=”sp1”]/@singleDate
   specialSevice[@id=”sp2”]/@singleDate

Inconsistent data

When software reads the example below it is not clear if 2025-04-10 is included or excluded. The range [2025-01-01 ; 2025-12-01] and a single date 2025-04-10 intersect and contradict each other.


      <operatingPeriod id="op_1">
        <specialService type="include"
                        startDate="2025-01-01"
                        endDate="2025-12-01"/>
        <specialService type="exclude"
                        singleDate="2025-04-10"/>
      </operatingPeriod>

The fix of the example above is splitting the ranges. The example below is valid because the ranges [2025-01-01 ; 2025-04-09], [2025-04-11; 2025-12-01] and single date 2025-04-10 do not intersect.

      <operatingPeriod id="op_1">
        <specialService type="include"
                        startDate="2025-01-01"
                        endDate="2025-04-09"/>
        <specialService type="exclude"
                        singleDate="2025-04-10"/>
        <specialService type="include"
                        startDate="2025-04-11"
                        endDate="2025-12-01"/>
    </operatingPeriod>

Data with redundancy

When software reads the example below it is clear that 2025-04-10 is included. However, the ranges [2025-01-01 ; 2025-12-01] and [2025-04-01 ; 2025-05-01] intersect and introduce redundancy.


      <operatingPeriod id="op_1">
        <specialService type="include"
                        startDate="2025-01-01"
                        endDate="2025-12-01"/>
        <specialService type="include"
                        startDate="2025-04-01"
                        endDate="2025-05-01"/>
      </operatingPeriod>

The fix of example above is the elimination of the redundant data.

      <operatingPeriod id="op_1">
        <specialService type="include"
                        startDate="2025-01-01"
                        endDate="2025-12-01"/>
      </operatingPeriod>

Notes / Anmerkungen

Not yet described. / Noch nicht beschrieben.

Open issues / Offene Punkte/Pendenzen

Not yet described. / Noch nicht beschrieben.