|Additional commercial attributes from TAP TSI for timetables [message #963]
||Wed, 14 May 2014 18:00
Registered: May 2014
as proposed during the railML-conference in Braunschweig, I would suggest
some changes for railML to incorporate requirements from the TAP TSI,
mainly for the commercial timetable.
The goal of the introductions of these attributes is to allow the creation
of TAP TSI compliant timetable data in EDIFACT, using railML-timetables as
For this purpose the following attributes shall be modified:
- rail:tPlaceCategory shall be modified in such a way that the values of
the corresponding TAP TSI code list B.4.9039 can be accomodated.
- rail:tServiceType shall be modified in such a way that the values of
the corresponding TAP TSI code list B.4.7161 can be accomodated.
1. Add the following values to the enumeration "rail:tPlaceCategory":
I would propose that the values "class3, "standing", "foldingSeat",
"impairedToilet", "toilet" shall remain from the current railML version
2. Add the following values to the enumeration "rail:tServiceType":
I would propose that the value "WLAN" will remain.
Furthermore the following addtional informations about the provided
accomodations and services for the TAP TSI should be discussed:
1. The availiability of the above mentioned services (e.g. only available
from June to August, even if the train is running the whole timetable
persiod). This information is not covered be the current railML data model.
2. The reservation status for a place or a service (e.g. reservation
----== posted via PHP Headliner ==----
|Re: Additional commercial attributes from TAP TSI for timetables [message #1300 is a reply to message #1299]
||Mon, 28 September 2015 12:54
Registered: November 2013
Location: Hanover, Germany
@Stefan: Thank you for the example file for further discussion. I do
have some questions/feedback:
1. additional attribute for 2.3
I believe the agreement of our meeting was to create a new and TSI
specific attribute - e.g. 'tapTsiCode' - so that the original railML 2.2
data representation is not affected. See #2 for sample.
2. Use of the number and not string code
Should we actually use a string as a code or should we use the actual
number value of the code? I would suggest to use the actual number code
value instead of a string because the code could be interpreted directly
if the default TAP TSI codes are used. Furthermore, it would allow for
at least a limited amount of verification - i.e. number from 1 to 999 as
a valid code reference instead of any string. A set of default mapping
for the existing railML enumeration categories could be provided in the
<!-- 100 seats in 1st class -->
<places category="class1" tapTsiCode="4" count="100"/>
<!-- 300 seats in 2nd class -->
<places category="class2" tapTsiCode="5" count="300"/>
<!-- Snack trolley available -->
<service name="trolley" tapTsiCode="25" count="1"/>
3. Documentation and versions
For me it is still not clear where the code list is 'published' and how
different versions can be managed between a railML provider and consumer.
Within the railML release there should be a codelist-schema xsd for the
file but the actual code list. It would then be up to the
provider/consumer to agree on an actual code list version - either
online or provided within their interface process.
Regarding external code lists in general I have found a similar approach
used by the ISO 20022 used by the financial industry
"... Unlike other ISO 20022 code sets, the codes are not included in the
message schema with the message element they type. The purpose of
externalising these codes is to be able to update the code sets (for
example, add new codes) without impacting the messages themselves and,
hence, without requiring the development of a new version of the
messages that use these code sets."
Am 21.09.2015 um 18:02 schrieb Stefan Jugelt:
> Dear all,
> as agreed during our railml timetable meeting last week I have created for
> the proposed attribues one example for the coding of places and services
> for a train part:
> <?xml version="1.0" encoding="UTF-8"?>
> <!--Sample XML file generated by XMLSpy v2015 sp2
> <railml xmlns="http://www.railml.org/schemas/2013"
> xsi:schemaLocation="http://www.railml.org/schemas/2013 railML.xsd">
> <railwayUndertaking id="CompanyCode_1080" code="1080"/>
> <infrastructure id="inf-0815">
> <ocp id="enee_8010085">
> <designator entry="8010085" register="ENEE"/>
> <ocp id="enee_8010205">
> <designator entry="8010205" register="ENEE"/>
> <timetable id="tt-0815">
> <trainPart id="TrainPart-0815-1">
> <!-- 100 seats in 1st class -->
> <places category="seatingFirstClass" count="100"/>
> <!-- 300 seats in 2nd class -->
> <places category="seatingSecondClass" count="300"/>
> <!-- Snack trolley available -->
> <service name="trolley" count="1"/>
> <ocpTT ocpRef="enee_8010085" ocpType="begin"/>
> <ocpTT ocpRef="enee_8010205" ocpType="end"/>
> <railwayUndertaking ref="CompanyCode_1080"/>
> Some further explanations:
> 1. The code values for the rail:places/@category shall be stored in an
> external code list, not in an enumeration in railML.
> 2. The code values are available in the files "Codelist_B.4.7161.xml"
> (servies) and "Codelist_B.4.9039.xml" (places).
> 3. The enumeration for the accomodation classes in "tPlaceCategory" and
> "tServces" are not needed anymore.
> Please check the example and provide your comments.
> Kind regards,
> Stefan Jugelt
|Re: Additional commercial attributes from TAP TSI for timetables [message #1350 is a reply to message #1305]
||Fri, 04 March 2016 11:06
Registered: November 2013
Location: Hanover, Germany
stefan.jugelt wrote on Wed, 14 October 2015 18:36|
The website with the actual version of the TAP TSI:
http://www.era.europa.eu/Document-Register/Pages/TAP-TSI.asp x . The code
lists will be available soon as XML-file on this website. We are waitung
for the final approval.
The Directory of passenger code lists for the ERA technical documents used in TAP TSI version 1.3.1 is now available as PDF and XSD via the ERA website (see link above).
The new TAP TSI attributes in railML 2.3 for places/services have been updated to reflect the type definition in the ERA XSD:
For details please see:
1) TRAC ticket #250
2) TRAC changeset #654