Home » railML newsgroups » railML.infrastructure » request for an attribute for the Infrastructure Manager of a line
| request for an attribute for the Infrastructure Manager of a line [message #309] |
Wed, 23 May 2012 14:57  |
Dirk Bräuer
Messages: 313
Registered: August 2008
|
Senior Member |
|
|
Dear all,
in RailML 2.0, we used the attributes <trackGroups>.<line>.uicNumber and
<trackGroups>.<line>.lineNumber to uniqely describe a railway line of
infrastructure. In RailML 2.1, there is the new attribute
<trackGroups>.<line>.code as the only possibility for an external primary
key of a line.
In practice, the Infrastructure Managers give their lines numbers or
names/abbreviations but so far there is no international unique key for a
line. Therefore, it is necessary to add the In-frastructure Manager’s key
to the primary key of a line.
If we would put both into ‘code’, e. g. code=’80.6363’ or ‘DB.6363’, this
would mean to ‘scan’ the code when importing infrastructure or a
timetable. It is one of the agreed principles of RailML to avoid known
‘scanning’ of strings due to all the problems which comes along (for
instance to force a unique separating character between IM code and line
number). Therefore, we (iRFP) cannot import RailML 2.1 because we refuse
to scan the ‘code’.
I think we should introduce attributes
- clearly to define the Infrastructure Manager of a line separated from
‘code’,
- to define the key (number or abbreviation) of the line at this IM which
may be ‘code’.
This means: Christian, please provide one new attribute ‘IM’, string, or
analogous.
Best regards,
Dirk.
|
|
|
|
| Re: request for an attribute for the Infrastructure Manager of a line [message #313 is a reply to message #309] |
Sat, 23 June 2012 10:22  |
Christian Rahmig
Messages: 151
Registered: January 2011
|
Senior Member |
|
|
Hello Dirk,
> in RailML 2.0, we used the attributes <trackGroups>.<line>.uicNumber and
> <trackGroups>.<line>.lineNumber to uniqely describe a railway line of
> infrastructure. In RailML 2.1, there is the new attribute
> <trackGroups>.<line>.code as the only possibility for an external
> primary key of a line.
>
> In practice, the Infrastructure Managers give their lines numbers or
> names/abbreviations but so far there is no international unique key for
> a line. Therefore, it is necessary to add the In-frastructure Manager’s
> key to the primary key of a line.
+1
> If we would put both into ‘code’, e. g. code=’80.6363’ or ‘DB.6363’,
> this would mean to ‘scan’ the code when importing infrastructure or a
> timetable. It is one of the agreed principles of RailML to avoid known
> ‘scanning’ of strings due to all the problems which comes along (for
> instance to force a unique separating character between IM code and line
> number). Therefore, we (iRFP) cannot import RailML 2.1 because we refuse
> to scan the ‘code’.
>
> I think we should introduce attributes
> - clearly to define the Infrastructure Manager of a line separated
> from ‘code’,
> - to define the key (number or abbreviation) of the line at this IM
> which may be ‘code’.
I propose the following implementation for railML 2.2, which can be also
found in the trac ticket [1]:
The new attribute 'uicNumber', which contains the UIC country code, will
be added to complex type 'tLine':
<xs:attribute name="uicNumber" type="rail:tTwoDigits" />
For defining the number of the line (without the UIC Country Code),
please use the generic attribute 'code'.
The ID of the infrastructure manager will be stored in the new attribute
'imNumber' in complex type 'tLine':
<xs:attribute name="imNumber" type="xs:string" />
Any questions and comments appreciated...
Regards
[1] https://trac.assembla.com/railML/ticket/152
--
Christian Rahmig
railML.infrastructure coordinator
|
|
|
|
|
|
| Re: request for an attribute for the Infrastructure Manager of a line [message #323 is a reply to message #316] |
Fri, 29 June 2012 21:30 |
Dirk Bräuer
Messages: 313
Registered: August 2008
|
Senior Member |
|
|
Dear Christian,
thank you for the proposal on Infrastructure Manager of a line.
> <line code="..." uicCountryCode="80" imCode="DB-Netz">...
Well, many 'codes', but of course it would fit, so no objection from my
side.
It may be mis-understandable that sometimes a 'code' shall contain rather
a number and sometimes rather an abbreviation or name. So again much
depends on good documentation and examples...
> Refining the attribute "imNumber" into "imCode" as an enumeration list
> with typical infrastructure managers with the free (schema-independent)
> extension possibility (other:xxx):
Assuming the IM is a free character string in the writing program: What
shall the writing program do to map the free character string to the
pre-defined enumeration values? It is possibly demanded a little bit too
much to expect that a program can map all spellings of "DB Netz", "DB Netz
AG", "DB-Netz", "DB-Netz AG", "DB-Netz-AG", "DB Netze" a.s.o. to the
enumeration value.
The problem is that from my opinion, the name or abbreviation of an IM is
not a typical case for an enumeration. One should assume that they can
change their names as they do it with their shirts...
What should prevent us from writing anything behind "other:", treating the
imCode attribute as a simple string without any mapping? Since there is no
need to ask a central authority (the Scheme coordinator) to use a new
enumeration value, there is also no chance to avoid that two instances use
different enumeration values for the same (new) IM. Consequently, we could
define imCode as a string from the beginning...
---
> <xs:attribute name="[uicCountryCode]" type="rail:tTwoDigits" />
Sometimes it is common practice to allow more-than-two-digit numbers to
code IM which have no official UIC number. It is not a big problem from my
side if we force a UIC-only code here. As earlier discussed in this forum,
it is rather a question of how general RailML should be: Should it be
valid in UIC countries only or outside also? America, Asia, Africa,
Australia?
With uicCountryCode=tTwoDigits, RailML seams to be usable in continents
starting with 'E' only but not in continents starting with 'A'. At least,
the world has more countries than we could code into two digits. So, we
put forward the original problem but do not solve it: With two US-American
infrastructure companies both numbering their lines from #1, the
uicCountryCode attribute does not help us to distinguish uniquely between
the lines.
Best regards,
Dirk.
|
|
|
|
| Re: request for an attribute for the Infrastructure Manager of a line [message #326 is a reply to message #323] |
Mon, 02 July 2012 08:43 |
Christian Rahmig
Messages: 151
Registered: January 2011
|
Senior Member |
|
|
Hello Dirk,
> It may be mis-understandable that sometimes a 'code' shall contain
> rather a number and sometimes rather an abbreviation or name. So again
> much depends on good documentation and examples...
Yes, you are right. Therefore, Susanne gave already few examples in her
comment to trac ticket #153 [1].
>> Refining the attribute "imNumber" into "imCode" as an enumeration list
>> with typical infrastructure managers with the free
>> (schema-independent) extension possibility (other:xxx):
>
> [...]
> The problem is that from my opinion, the name or abbreviation of an IM
> is not a typical case for an enumeration. One should assume that they
> can change their names as they do it with their shirts...
> [...]
> Consequently, we could define imCode as a string from the beginning...
I agree with your opinion. On the other side: Wouldn't it be great to
having a list with possible entries instead of thinking about the
spelling of "DB-Netz" or "DB Netz"? All applications may refer to the
enumerations and there is no need for further discussions between the
different applications' users. Of course, if the IM decides to change
his shirt, we should track this change and update the list.
>> <xs:attribute name="[uicCountryCode]" type="rail:tTwoDigits" />
>
> [...]
> With uicCountryCode=tTwoDigits, RailML seams to be usable in continents
> starting with 'E' only but not in continents starting with 'A'. At
> least, the world has more countries than we could code into two digits.
Yes, there are countries that don't have a UIC country code, because
they are not members of the UIC. However, it is possible to map the
whole world to a two-digit code defined as ISO 3166-1 alpha-2 in ISO
3166-1 [2]. If we generalize the attribute 'uicCountryCode' into e.g.
'countryCode' and allow for the alpha-2 codes, railML may become usable
in "A-continents" as well.
> [...] With two
> US-American infrastructure companies both numbering their lines from #1,
> the uicCountryCode attribute does not help us to distinguish uniquely
> between the lines.
For distinguishing betweeen the lines, you need to look at the whole
"key", which consists of the parameters 'uicCountryCode', 'code' and
'imCode'. In your example, the infrastructure companies would have
different values for 'imCode' and thus, their lines could be identified.
[1] https://trac.assembla.com/railML/ticket/152
[2] http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2
Regards
---
Christian Rahmig
railML.infrastructure coordinator
|
|
|
|
|
|
| Re: request for an attribute for the Infrastructure Manager of a line [message #370 is a reply to message #326] |
Mon, 01 October 2012 15:11 |
Christian Rahmig
Messages: 151
Registered: January 2011
|
Senior Member |
|
|
Dear railML users,
>>> <xs:attribute name="[uicCountryCode]" type="rail:tTwoDigits" />
>>
>> [...]
>> With uicCountryCode=tTwoDigits, RailML seams to be usable in continents
>> starting with 'E' only but not in continents starting with 'A'. At
>> least, the world has more countries than we could code into two digits.
>
> Yes, there are countries that don't have a UIC country code, because
> they are not members of the UIC. However, it is possible to map the
> whole world to a two-digit code defined as ISO 3166-1 alpha-2 in ISO
> 3166-1 [2]. If we generalize the attribute 'uicCountryCode' into e.g.
> 'countryCode' and allow for the alpha-2 codes, railML may become usable
> in "A-continents" as well.
>
> [1] https://trac.assembla.com/railML/ticket/152
> [2] http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2
In the above discussion, we agreed on the opinion that the attribute
'isoCountryCode' is not needed: Many lines in border regions include
tracks in two or more countries. To avoid additional cuts of the line,
the attribute 'isoCountryCode' is deleted. However, the line is uniquely
defined by the 'infrastructureManagerCode' and the 'code' given by the
infrastructure manager.
Regards
--
Christian Rahmig
railML.infrastructure coordinator
|
|
|
|
| Re: request for an attribute for the Infrastructure Manager of a line [message #471 is a reply to message #353] |
Tue, 27 November 2012 12:52 |
Susanne Wunsch railML
Messages: 0
Registered: January 2020
|
|
|
|
Hello Christian, Dirk and others,
as discussed at the railML-conference in Zurich and already noticed by
Dirk in another thread, we agreed on having a free string field for the
'infrastructureManager' with an additional XML-file providing a
pre-defined list of possible values.
>> Refining the attribute "imNumber" into "imCode" as an enumeration list
>> with typical infrastructure managers with the free (schema-independent)
>> extension possibility (other:xxx):
The Trac ticket [1] and current implementation should be changed
therefore.
Any objections?
[1] https://trac.assembla.com/railML/ticket/152
Kind regards...
Susanne
--
Susanne Wunsch
Schema Coordinator: railML.common
|
|
|
|
|
|
| Re: request for an attribute for the Infrastructure Manager of a line [message #481 is a reply to message #474] |
Mon, 03 December 2012 11:45 |
Susanne Wunsch railML
Messages: 0
Registered: January 2020
|
|
|
|
Hi Christian, Dirk and others,
>> as discussed at the railML-conference in Zurich and already noticed by
>> Dirk in another thread, we agreed on having a free string field for the
>> 'infrastructureManager' with an additional XML-file providing a
>> pre-defined list of possible values.
>> [1] https://trac.assembla.com/railML/ticket/152
I would propose the following structure for the XML file:
<infrastructureManagerCodes xmlns="http://www.railml.org/lists">
<infrastructureManagerCode id="d1e3">
<version>
<code>ThE</code>
<name>Thüringer Eisenbahn GmbH</name>
<validity begin="2001-08-01"/>
<remarks/>
</version>
</infrastructureManagerCode>
<infrastructureManagerCode id="d1e84">
<version>
<code>EIB</code>
<name>Erfurter Industriebahn GmbH</name>
<validity begin="1990-05-01" end="2007-03-02"/>
<remarks/>
</version>
<version>
<code>EB</code>
<name>Erfurter Bahn GmbH</name>
<validity begin="2007-03-03"/>
<remarks/>
</version>
</infrastructureManagerCode>
</infrastructureManagerCodes>
The code itself is referred inside the 'line' element:
<rail:trackGroups>
<rail:line id="l1" infrastructureManagerCode="EIB">
<rail:trackRef ref="t1"/>
</rail:line>
</rail:trackGroups>
Kind regards...
Susanne
--
Susanne Wunsch
Schema Coordinator: railML.common
|
|
|
|
|
|
| Re: request for an attribute for the Infrastructure Manager of a line [message #488 is a reply to message #481] |
Mon, 03 December 2012 16:27 |
Dirk Bräuer
Messages: 313
Registered: August 2008
|
Senior Member |
|
|
Dear Susanne,
Am 03.12.2012, 11:45 Uhr, schrieb Susanne Wunsch <coord(at)commonrailmlorg>:
> I would propose the following structure for the XML file:
....
> <infrastructureManagerCode id="d1e3">
> <version>
....
> <rail:line id="l1" infrastructureManagerCode="EIB">
> <rail:trackRef ref="t1"/>
> </rail:line>
As far as I see, the /id/ and /infrastructureManagerCode/ are used
redundantly. Which one of both attributes is the real reference and which
one is "for information only"? I think <trackRef /ref/> is the real
reaference and /infrastructureManagerCode/ is "for information only". But
this
- is different than in the past (where there was no /ref/ at a line),
- is confusing because not self-explaining.
At least, is not practical because in cases when a software knows only the
abbreviation of the IM, it is not known whether one should simple use the
attribute <line /infrastructureManagerCode/ > or one should create an
element <infrastructureManagerCode> for only this code.
In total: Well, it would of course be possible but a little bit
complicated, confusing and from my side not to be recommended.
At least, if you decide to do it anyway, please say that the addresses and
such (what Andreas suggested) is included in
<infrastructureManagerCode><version>.
Dirk.
|
|
|
|
| Re: request for an attribute for the Infrastructure Manager of a line [message #497 is a reply to message #488] |
Mon, 03 December 2012 21:55 |
Susanne Wunsch railML
Messages: 0
Registered: January 2020
|
|
|
|
Dear Dirk,
Dirk Bräuer <dirkbraeuer(at)irfpde> writes:
> Am 03.12.2012, 11:45 Uhr, schrieb Susanne Wunsch <coord(at)commonrailmlorg>:
>
>> I would propose the following structure for the XML file:
> ...
>> <infrastructureManagerCode id="d1e3">
>> <version>
> ...
>> <rail:line id="l1" infrastructureManagerCode="EIB">
>> <rail:trackRef ref="t1"/>
>> </rail:line>
>
> As far as I see, the /id/ and /infrastructureManagerCode/ are used
> redundantly. Which one of both attributes is the real reference and
> which one is "for information only"?
Not "redundantly", but currently the 'id' of the
<infrastructureManagerCode> in the separate XML file is not used at all.
We thought about using the "id" value instead of the "code" value, but
that would mean, that any software which reads a railML file without
knowledge of the separate "list-XML-file" gets _no information_ for this
attribute.
> I think <trackRef /ref/> is the real reaference and
> /infrastructureManagerCode/ is "for information only".
The 'trackRef' is the "real information" for grouping the tracks into
lines for the railML file context. The 'infrastructureManagerCode' is
the "real information" for defining the "owner" of the defined 'line'.
I don't see any redundancy here. If the importing software already has
some knowledge about lines, their tracks and its infrastructure manager,
it has to check the consistency of the railML data.
> But this
> - is different than in the past (where there was no /ref/ at a line),
The concept of 'trackRef's in the 'line' element was introduced with
railML 2.0.
> - is confusing because not self-explaining.
Please help me out, I don't see the confusion yet. But I know, I'm
sometimes a bit blind regarding the semantics of railML constructs.
> At least, is not practical because in cases when a software knows only
> the abbreviation of the IM, it is not known whether one should simple
> use the attribute <line /infrastructureManagerCode/ > or one should
> create an element <infrastructureManagerCode> for only this code.
* 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.
* 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.
* 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.
> At least, if you decide to do it anyway, please say that the addresses
> and such (what Andreas suggested) is included in
> <infrastructureManagerCode><version>.
I see the addresses as some kind of contact data. I don't want to host
them at railML. It's more or less a hint for the railML-file-consumer
whom to contact in case of any questions. It may be a special personal
contact information, eg. a person responsible for a single region with
its mobile number.
Kind regards...
Susanne
--
Susanne Wunsch
Schema Coordinator: railML.common
|
|
|
|
| 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: 313
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.
|
|
|
|
| Re: request for an attribute for the Infrastructure Manager of a line [message #507 is a reply to message #481] |
Fri, 04 January 2013 16:33 |
Christian Rahmig
Messages: 151
Registered: January 2011
|
Senior Member |
|
|
Hi Susanne,
as well as for all the other railML users, I would like to wish you a
happy New Year 2013!
Am 03.12.2012 11:45, schrieb Susanne Wunsch:
> Hi Christian, Dirk and others,
>
>>> as discussed at the railML-conference in Zurich and already noticed by
>>> Dirk in another thread, we agreed on having a free string field for the
>>> 'infrastructureManager' with an additional XML-file providing a
>>> pre-defined list of possible values.
>>> [1] https://trac.assembla.com/railML/ticket/152
>
> I would propose the following structure for the XML file:
>
> <infrastructureManagerCodes xmlns="http://www.railml.org/lists">
> <infrastructureManagerCode id="d1e3">
> <version>
> <code>ThE</code>
> <name>Thüringer Eisenbahn GmbH</name>
> <validity begin="2001-08-01"/>
> <remarks/>
> </version>
> </infrastructureManagerCode>
> <infrastructureManagerCode id="d1e84">
> <version>
> <code>EIB</code>
> <name>Erfurter Industriebahn GmbH</name>
> <validity begin="1990-05-01" end="2007-03-02"/>
> <remarks/>
> </version>
> <version>
> <code>EB</code>
> <name>Erfurter Bahn GmbH</name>
> <validity begin="2007-03-03"/>
> <remarks/>
> </version>
> </infrastructureManagerCode>
> </infrastructureManagerCodes>
Since the attribute "id" is not really needed for the purpose of
referencing an IM list entry from a <line> within a railML file, I
prefer to leave it out. The question is if the user is really interested
in the history of the entry i.e. which name did the IM had before.
Because that seems to be the only reason why we introduced that "id"
attribute first.
To make the structure a little bit slimmer, I suggest the following layout:
<infrastructureManagerCodes xmlns="http://www.railml.org/lists">
<infrastructureManager code="ThE">
<name>Thüringer Eisenbahn GmbH</name>
<validity begin="2001-08-01" />
<remarks />
</infrastructureManager>
...
</infrastructureManagerCodes>
Any comments appreciated...
Regards
--
Christian Rahmig
railML.infrastructure coordinator
|
|
|
|
Goto Forum:
Current Time: Sun Nov 03 20:11:25 CET 2024
|
Members
Search
Help
Login
Home
