Home » railML newsgroups » railml.timetable » Extension of places and service
| Extension of places and service [message #830] |
Thu, 18 October 2012 13:03  |
Dirk Bräuer
Messages: 313
Registered: August 2008
|
Senior Member |
|
|
Hallo allerseits,
für RailML 2.2 würde ich gern noch ein paar Erfahrungen aus laufenden
Projekten beisteuern, für die wir eine Erweiterung der Typen
"rail:tPlaces" und "rail:tService" brauchen. Diese werden bei
<rollingstock>...<vehicles>...<passenger>
<timetable>...<trainPart>...<passengerUsage>
verwendet. Ist hier alles nur als Vorschlag zu verstehen.
1) Neues Attribut "type" in
<trainPart><formationTT><passengerUsage><service>
(Enumeration) zur Kennzeichnung der Art des Services (optional ergänzend
zu "name")
mögliche Aufzählwerte:
<xs:enumeration value="mobileCatering" /> (Zug hat mobilen
Bordservice)
<xs:enumeration value="WLAN" /> (Zug hat drahtlosen
Netzwerkzugang)
2) Erweiterung der Aufzälwerte von tPlaceCategory für
<trainPart><formationTT><passengerUsage><places>.category:
<xs:enumeration value="business" /> (Anzahl Plätze in einem
Business-Abteil)
<xs:enumeration value="bistro" /> (Anzahl Plätze in einem
Bistrowagen(teil))
<xs:enumeration value="WR" /> (Anzahl Plätze in einem
Speisewagen(teil))
<xs:enumeration value="foldingSeat" /> (Anzahl Klappsitze)
<xs:enumeration value="WC_SD" /> (Anzahl behindertengerechte
WCs)
annotation: "SD = suitable for disabled"
<xs:enumeration value="WC" /> (Anzahl WC)
annotation: "total number, includes possible WC_SD"
3) neues Attribut "reservation" (optional; Enumeration: notPossible,
possible, recommended, compulsory) in
<trainPart><formationTT><passengerUsage><places>
Begründung: Wir brauchen eine "Anzahl reservierungspflichtiger
Fahrradplätze"; die Lösung löst aber Reservierungspflicht im Allgemeinen
auch für Sitzplätze usw.
Letzteres wird nur unter <trainPart> gebraucht, nicht unter <vehicle> -
daher ggf. außerhalb des globalen Typs anbringen.
Wäre schön, wenn man das noch in 2.2 mit einbauen könnte.
Dirk.
---
Dear all,
for RailML 2.2 we need some small extensions on types "rail:tPlaces" and
"rail:tService", used at:
<rollingstock>...<vehicles>...<passenger>
<timetable>...<trainPart>...<passengerUsage>
The following are all suggestions only.
1) New attribute "type" at
<trainPart><formationTT><passengerUsage><service>
(enumeration) to show the kind of service (optionally additional to "name")
possible enumeration values:
<xs:enumeration value="mobileCatering" /> (train has mobile
catering)
<xs:enumeration value="WLAN" /> (train has wireless local area
network)
2) Extension of enumeration values of tPlaceCategory at
<trainPart><formationTT><passengerUsage><places>.category:
<xs:enumeration value="business" /> (no. of places in a business
compartment)
<xs:enumeration value="bistro" /> (no. of places in a bistro
carriage or compartment)
<xs:enumeration value="WR" /> (no. of places in a dining car)
<xs:enumeration value="foldingSeat" /> (no. of folding places)
<xs:enumeration value="WC_SD" /> (no. of WCs suitable for
disabled)
annotation: "SD = suitable for disabled"
<xs:enumeration value="WC" /> (total no. of WCs)
annotation: "total number, includes possible WC_SD"
3) New attribute "reservation" (optional; enumeration: notPossible,
possible, recommended, compulsory) in
<trainPart><formationTT><passengerUsage><places>
Reason: We need a "no. of bicycle places compulsory for reservation"; the
suggested solution suites types of reservation in general, also for seats
a.s.o.
The latter is only needed at <trainPart>, not at <vehicle>, so it should
possible be arranged outside the global type.
Best regards,
Dirk.
|
|
|
|
| Re: Extension of places and service [message #834 is a reply to message #830] |
Tue, 30 October 2012 11:20  |
Andreas Tanner
Messages: 52
Registered: March 2012
|
Member |
|
|
Hallo railML-Interessenten,
Am 18.10.2012 13:03, schrieb Dirk Bräuer:
>
> 1) Neues Attribut "type" in
> <trainPart><formationTT><passengerUsage><service>
> (Enumeration) zur Kennzeichnung der Art des Services (optional ergänzend
> zu "name")
> mögliche Aufzählwerte:
> <xs:enumeration value="mobileCatering" /> (Zug hat mobilen
> Bordservice)
> <xs:enumeration value="WLAN" /> (Zug hat drahtlosen
> Netzwerkzugang)
Warum: weil enumeration besser ist als freier Text? Welche Rolle spielt
dann das (Pflicht)-attribut name? (Stichwort "Redundanzen"...)
>
> 2) Erweiterung der Aufzälwerte von tPlaceCategory für
> <trainPart><formationTT><passengerUsage><places>.category:
>
> <xs:enumeration value="business" /> (Anzahl Plätze in
> einem Business-Abteil)
Sollen die Business-Plätze extra zählen, oder als 1. Klasse, oder
womöglich als 2./3. Klasse Plätze?
Kleinkindabteil fehlt auch noch. In der Schweiz gibt's Familienwagen
oder -zonen...
>
> 3) neues Attribut "reservation" (optional; Enumeration: notPossible,
> possible, recommended, compulsory) in
> <trainPart><formationTT><passengerUsage><places>
>
klingt gut, finde ich.
> Begründung: Wir brauchen eine "Anzahl reservierungspflichtiger
> Fahrradplätze"; die Lösung löst aber Reservierungspflicht im Allgemeinen
> auch für Sitzplätze usw.
>
> Letzteres wird nur unter <trainPart> gebraucht, nicht unter <vehicle> -
> daher ggf. außerhalb des globalen Typs anbringen.
>
--Andreas.
|
|
|
|
| Re: Extension of places and service [message #837 is a reply to message #834] |
Thu, 01 November 2012 12:48 |
Dirk Bräuer
Messages: 313
Registered: August 2008
|
Senior Member |
|
|
Hallo Andreas,
>> 1) Neues Attribut "type" in
>> <trainPart><formationTT><passengerUsage><service>
>> (Enumeration) zur Kennzeichnung der Art des Services (optional
>> ergänzend zu "name")
>> mögliche Aufzählwerte:
>> <xs:enumeration value="mobileCatering" /> (Zug hat
>> mobilen Bordservice)
>> <xs:enumeration value="WLAN" /> (Zug hat drahtlosen
>> Netzwerkzugang)
>
> Warum: weil enumeration besser ist als freier Text?
Ja, genau. Weil nur durch die Aufzählung ein unmissverständlicher
Datenaustausch sichergestellt ist. Wenn ich die Attribute in einen freien
Text reinschreibe, woher weiß ein auswertendes Programm dann, wonach es
suchen soll (Sprache, Groß- und Kleinschreibung)?
> Welche Rolle spielt dann das (Pflicht)-attribut name? (Stichwort
> "Redundanzen"...)
Weiß ich nicht. Mir gefällt es da auch nicht, vor allem nicht wegen der
potentiellen Redundanz. Wir sollten es zumindest zu einem optionalen Feld
machen. Da das aber wohl nicht vor 3.0 geht, können wir "name" dann auch
ganz entfallen lassen, sofern niemand eine Bedeutung darin sieht.
> Sollen die Business-Plätze extra zählen, oder als 1. Klasse, oder
> womöglich als 2./3. Klasse Plätze?
Dieses Problem der Überlappung haben wir an vielen Stellen. (Welche Klasse
sind Speise- oder Bistrowagenplätze?) Bei den Toiletten wollen wir es
eindeutig klären (WCs gesamt inkludiert WCs behindertengerecht). Bei allen
anderen Fällen gilt m. E.:
Wenn es diese Unterscheidung in der Praxis gibt: Bitte für RailML
beantragen.
Wenn es diese Frage auch in der Praxis ungeklärt ist: Auch aus RailML
raushalten. RailML muss und soll keine Fragen beantworten, die die Praxis
nicht beantwortet.
Also: Ist Ihnen von irgendwo eine explizite Unterscheidung nach
"Business-Plätze 1. Klasse" und "Business-Plätze 2. Klasse" bekannt? Falls
ja: Bitte meinen Wunsch nach Aufnahme dieser Plätze sofort dahingehend
korrigieren bzw. erweitern. Falls nein: Belassen wir es dabei.
> Kleinkindabteil fehlt auch noch. In der Schweiz gibt's Familienwagen
> oder -zonen...
Bitte zur Aufnahme beantragen. Ich würde dem sofort zustimmen. Es soll
halt nach und nach immer vollständiger werden.
Viele Grüße,
Dirk.
|
|
|
|
| Re: Extension of places and service [message #838 is a reply to message #834] |
Thu, 01 November 2012 13:14 |
Dirk Bräuer
Messages: 313
Registered: August 2008
|
Senior Member |
|
|
Dear all,
since it is clear where Andreas' remarks lead to: How about the following
suggestion for RailML 3.0:
- Unification of <passengerUsage>.<service> and <passengerUsage>.<places>
- no determination between them, just "passengerUsage".
- "Type" as an attribute, enumeration of all known services and places:
Seats, folding seats, beds, WC, WLAN, mobile service... etc.
- Optional attribute independent from "type": class = enumeration of (1st,
2nd, 3rd, all, unknown...)
- Optional attribute independent from "type": reservation = enumeration of
(notPossible, possible, recommended, compulsory)
- Optional attribute independent from "type": numberOf = integer
That model would be:
- simple: Just a sequence of one element with four attributes.
- more flexible: One could assign classes to all type but one does not
need to or can also say "all classes". (One could make the dining car
seats or the sleeping beds or even the WCs for 1st class only...)
The types of "boolean character" such as "mobile service" or "WLAN" do not
need the "numberOf" attribute: They are just named, just enumerated.
The types of "numeral character" such as "seats" or "WCs" can have the
"numberOf" attribute if the number is known.
One could use such types as "restaurant seats" like boolean-style ("There
are restaurant seats but it doesn't matter how many") or with a certain
number. For many usages, it would be enough just to name/enumerate the
types of service without the number of places, namely just to place a
symbol in the passenger information.
Joachim: How about a track ticket?
Best regards,
Dirk.
|
|
|
|
| Re: Extension of places and service [message #852 is a reply to message #837] |
Wed, 07 November 2012 23:23 |
Susanne Wunsch railML
Messages: 0
Registered: January 2020
|
|
|
|
Dirk Bräuer <dirkbraeuer(at)irfpde> writes:
>>> 1) Neues Attribut "type" in
>>> <trainPart><formationTT><passengerUsage><service>
>>> (Enumeration) zur Kennzeichnung der Art des Services (optional
>>> ergänzend zu "name")
>>> mögliche Aufzählwerte:
>>> <xs:enumeration value="mobileCatering" /> (Zug hat
>>> mobilen Bordservice)
>>> <xs:enumeration value="WLAN" /> (Zug hat
>>> drahtlosen Netzwerkzugang)
>>
>> Warum: weil enumeration besser ist als freier Text?
>
> Ja, genau. Weil nur durch die Aufzählung ein unmissverständlicher
> Datenaustausch sichergestellt ist. Wenn ich die Attribute in einen
> freien Text reinschreibe, woher weiß ein auswertendes Programm dann,
> wonach es suchen soll (Sprache, Groß- und Kleinschreibung)?
>
>> Welche Rolle spielt dann das (Pflicht)-attribut name? (Stichwort
>> "Redundanzen"...)
>
> Weiß ich nicht. Mir gefällt es da auch nicht, vor allem nicht wegen
> der potentiellen Redundanz. Wir sollten es zumindest zu einem
> optionalen Feld machen. Da das aber wohl nicht vor 3.0 geht, können
> wir "name" dann auch ganz entfallen lassen, sofern niemand eine
> Bedeutung darin sieht.
>
>> Sollen die Business-Plätze extra zählen, oder als 1. Klasse, oder
>> womöglich als 2./3. Klasse Plätze?
>
> Dieses Problem der Überlappung haben wir an vielen Stellen. (Welche
> Klasse sind Speise- oder Bistrowagenplätze?) Bei den Toiletten wollen
> wir es eindeutig klären (WCs gesamt inkludiert WCs
> behindertengerecht). Bei allen anderen Fällen gilt m. E.:
>
> Wenn es diese Unterscheidung in der Praxis gibt: Bitte für RailML
> beantragen.
> Wenn es diese Frage auch in der Praxis ungeklärt ist: Auch aus RailML
> raushalten. RailML muss und soll keine Fragen beantworten, die die
> Praxis nicht beantwortet.
>
> Also: Ist Ihnen von irgendwo eine explizite Unterscheidung nach
> "Business-Plätze 1. Klasse" und "Business-Plätze 2. Klasse" bekannt?
> Falls ja: Bitte meinen Wunsch nach Aufnahme dieser Plätze sofort
> dahingehend korrigieren bzw. erweitern. Falls nein: Belassen wir es
> dabei.
Filed a Trac ticket for this issue:
http://trac.assembla.com/railML/ticket/183
Kind regards...
Susanne
--
Susanne Wunsch
Schema Coordinator: railML.common
|
|
|
|
| Re: Extension of places and service [message #853 is a reply to message #834] |
Wed, 07 November 2012 23:26 |
Susanne Wunsch railML
Messages: 0
Registered: January 2020
|
|
|
|
Andreas Tanner <ata(at)ivude> writes:
> Am 18.10.2012 13:03, schrieb Dirk Bräuer:
>> 2) Erweiterung der Aufzälwerte von tPlaceCategory für
>> <trainPart><formationTT><passengerUsage><places>.category:
>>
>> <xs:enumeration value="business" /> (Anzahl Plätze in
>> einem Business-Abteil)
>
> Sollen die Business-Plätze extra zählen, oder als 1. Klasse, oder
> womöglich als 2./3. Klasse Plätze?
> Kleinkindabteil fehlt auch noch. In der Schweiz gibt's Familienwagen
> oder -zonen...
Filed a Trac ticket for this issue:
http://trac.assembla.com/railML/ticket/184
Kind regards...
Susanne
--
Susanne Wunsch
Schema Coordinator: railML.common
|
|
|
|
|
|
| Re: Extension of places and service [message #855 is a reply to message #838] |
Wed, 07 November 2012 23:30 |
Susanne Wunsch railML
Messages: 0
Registered: January 2020
|
|
|
|
Dirk Bräuer <dirkbraeuer(at)irfpde> writes:
> since it is clear where Andreas' remarks lead to: How about the
> following suggestion for RailML 3.0:
>
> - Unification of <passengerUsage>.<service> and
> <passengerUsage>.<places> - no determination between them, just
> "passengerUsage".
>
> - "Type" as an attribute, enumeration of all known services and
> places: Seats, folding seats, beds, WC, WLAN, mobile service... etc.
>
> - Optional attribute independent from "type": class = enumeration of
> (1st, 2nd, 3rd, all, unknown...)
>
> - Optional attribute independent from "type": reservation =
> enumeration of (notPossible, possible, recommended, compulsory)
>
> - Optional attribute independent from "type": numberOf = integer
Filed a Trac ticket for this issue:
http://trac.assembla.com/railML/ticket/186
Kind regards...
Susanne
--
Susanne Wunsch
Schema Coordinator: railML.common
|
|
|
|
|
|
|
|
|
|
| Re: Extension of places and service [message #918 is a reply to message #916] |
Wed, 06 February 2013 20:49 |
Susanne Wunsch railML
Messages: 0
Registered: January 2020
|
|
|
|
Dear Jörg,
thanks for looking after this issue.
Joerg von Lingen <coordrollingstock(at)railmlorg> writes:
> Die Erweiterung der Aufzählung würde ich in Anlehnung des Vorschlags
> im Ticket #184 wie folgt machen:
> <xs:enumeration value="impairedToilette" />
> <xs:enumeration value="toilette" />
I would prefer the English spelling "toilet". ;-)
Kind regards...
Susanne
--
Susanne Wunsch
Schema Coordinator: railML.common
|
|
|
|
| Re: Extension of places and service [message #920 is a reply to message #918] |
Thu, 07 February 2013 18:05 |
Joachim Rubröder railML
Messages: 0
Registered: November 2019
|
|
|
|
Dear Jörg and Susanne,
I had a look at the changements for this issues - seems to be well
implemented according to the needs mentioned in the forum.
Many thanks for the help within the timetable schema!
Kind regards...
Joachim
Joachim Rubroeder
Schema Coordinator: railML.timetable
--
----== posted via PHP Headliner ==----
|
|
|
|
Goto Forum:
Current Time: Sun Nov 03 20:08:17 CET 2024
|
Members
Search
Help
Login
Home
