Home » railML newsgroups » railML.infrastructure » Alternative Stationsnamen (ocp, additionalName)
Alternative Stationsnamen (ocp, additionalName) [message #284] Mon, 26 March 2012 10:57 Go to previous message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 311
Registered: August 2008
Senior Member
Hallo Allerseits,

was mir beim Schreiben eines Beispiels zu alternativen Stationsnamen
(http://www.irfp.de/download/railml_doku_beispiele.pdf, Seite 3)
aufgefallen ist: Ein Umstand ist hier derzeit m. E. noch ungünstig. Wir
können zwar den alternativen Namen mitgeben, ob es sich um
(inner)betriebliche oder verkehrliche Namen handelt und welcher Sprache
sie angehören, es bleibt aber unklar, welcher Kategorie und Sprache der
„eigentliche“, im Element ocp, Attribut name genannte Name angehört.

So ist auch in derzeitigen deutschen Anwendungen unklar, ob unter ‚name’
der verkehrliche Name anzugeben und der betriebliche unter
‚additionalName’, type=trafficName aufzuführen ist oder umgekehrt der
verkehrliche als ‚name’ und der betriebliche unter ‚additionalName’,
type=operationalName. (Der Unterschied zwischen betrieblichem und
verkehrlichen Namen ist z. B. „Bft. Dresden-Neustadt Pbf.“ und
„Dresden-Neustadt“. Der Unterschied ist unvermeidbar spätestens bei
solchen Bahnhöfen, wo zwei oder mehr betriebliche Bahnhöfe als ein
verkehrlicher vermarktet werden, wie z. B. „Berlin Lehrter Bf oben“
[BHBF], „Berlin Lehrter Bf S-Bahn“ [BLS] und „Berlin Lehrter Bf unten“
[BL] gemeinsam als „Berlin Hbf - Lehrter Bahnhof“.)

Im Falle von Piräus und Athen habe ich deren griechische verkehrliche
Namen sowohl als ‚name’ angegeben als auch bei ‚additionalName’
wiederholt, um deren Zugehörigkeit zur Sprache deutlich zu machen, was in
diesem Beispiel für Mitteleuropäer nicht trivial ist. Hier wird deutlich,
dass ‚xml:lang’ eigentlich bei ‚ocp’ noch fehlt.

Wir haben aus meiner Sicht folgende Möglichkeiten:
a) Wir schreiben klar und deutlich vor, dass ‚name’ bei ocp immer der
(inner)betriebliche Name sein muss und eventuell abweichende verkehrliche
Namen immer als additionalName anzugeben sind. Dann brauchen wir die
Ausprägung ‚type=operationalName’ eigentlich nicht mehr, und wir gingen
dann davon aus, dass es immer nur einen betrieblichen Namen geben kann
(was ich für vernünftig hielte).
b) Wir erlauben weiterhin, dass alles möglich ist, fügen aber bei ocp die
optionalen Felder ‚type’ und ‚xml:lang’ hinzu, damit man eben deutlich
machen kann, für welche Wahl sich das schreibende Programm entschieden hat.

Ich wäre eigentlich für Lösung (a), weil Klarheit es den lesenden
Programmen leichter macht. Bei Lösung (b) muss ein lesendes Programm ja
quasi alles können. Ich fürchte aber, nur Lösung (b) ist so richtig
abwärtskompatibel.


--
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/
 
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Signals vs panels
Next Topic: SpeedChange : Protection system reference
Goto Forum:
  


Current Time: Tue Apr 30 00:22:17 CEST 2024