| Re: request for an attribute for the Infrastructure Manager of a line [message #505 is a reply to message #497] |
Fri, 07 December 2012 16:13   |
Dirk Bräuer
Messages: 311
Registered: August 2008
|
Senior Member |
|
|
Dear Susanne and all others,
there are some small questions on the usage of the new additional "XML
list files" which I want to write here as an answer to Susanne's post for
better understanding. Further writings should possibly take place at
<misc>.
a)
> * If the abbreviation of the IM matches one "currently valid" "code" in
> the XML-list-file, all is fine. This abbreviation should be taken for
> the attribute "infrastructureManagerCode" in the "line" element.
Soweit klar.
b)
> * If the "string" look up fails, the abbreviation may be defined in the
> XML-list-file in a slightly different way, eg. "DB-Netz" vs. "DB Netz
> AG". Then the XML-list-file entry "code" is recommended to use for the
> attribute "infrastructureManagerCode" in the "line" element.
Ok. Wie soll ein Programm herausfinden, ob "may be defined ... in a
slightly different way" zutrifft? Dir ist sicherlich bewusst, dass eine
phonetische Korrelationsanalyse hier kaum auf Gegenliebe stoßen wird. Ich
bezweifle auch, dass jemand tatsächlich etwa eine n:1-Ersetzungsliste mit
allen n Schreibweisen einer Bahnverwaltung in seiner RailML-Schnittstelle
umsetzt.
c)
> * If the look up fails at all, because this IM is currently not
> registered at the XML-list-file this "RFE (request for enhancement)"
> should be sent to the railML infrastructure coordinator in order to
> add this value. The proposed new abbreviation for the IM should be
> used for the attribute "infrastructureManagerCode" in the "line"
> element.
Auch klar. Hierbei soll dann wohl kein "other:" davorgeschrieben werden?
(Dieses "other:" hätte ja den Vorteil, dass man einem lesenden Programm
gleich signalisieren kann, dass es den Wert nicht im XML-list-file zu
suchen braucht.)
Da (b) unpraktikabel ist, wird wohl nach (a) immer gleich (c) kommen. Das
war ja aber klar und in Kauf genommen. Bei unserem RailML wird es
vermutlich relativ häufig zu dem Fall kommen, dass unter
/infrastructureManagerCode/ eine nicht registrierte Abkürzung bzw.
Schreibweise auftaucht - ohne dass wir (iRFP) dem Schemenkoordinator
Bescheid geben könnten, da wir gar nichts davon erfahren. (Daher wäre eine
Art Signalisierung mit "other:" durchaus sinnvoll, da der Zustand durchaus
dauerhaft sein kann.)
---
English summary: The question is whether a RailML writing software should
write "other:" or such in front of values of /infrastructureManagerCode/ if
- either it knows that the value is not in the current XML file list,
- or it does not know whether the value is in the current XML file list.
This "signalisation" could be helpful
- to prevent a reading software from unnecessarily scanning the xml file
list,
- to tell a reading software that any possible entry with the same value
in the xml file list is not meant.
The background is that currently there is no version-referencing planned
for the additional xml list files. So it may be that an
infrastructureManagerCode will be added to the list _after_ the RailML
file was created and for a different IM. But besides this 'accidentally
naming conflict', this technique could also be used to intentionally
overwrite an existing infrastructureManagerCode if necessary.
We already have this "other:"-signalisation for enumeration values but so
far, it is not compulsory for the new XML list file references.
This question applies not only to /infrastructureManagerCode/ but to all
information we will provide using additional XML list files.
> Crosspost & Followup-To: railML.misc
Ja. Irgendwie so. (Bin Forum-Laie.)
Best regards,
Dirk.
|
|
|
|
Members
Search
Help
Login
Home
