Home » railML newsgroups » railml.timetable » @categoryPriority of <category> to be declared deprecated in version 2.5
@categoryPriority of <category> to be declared deprecated in version 2.5 [message #2277] Tue, 26 November 2019 18:03 Go to next message
Milan Wölke is currently offline  Milan Wölke
Messages: 26
Registered: April 2007
Junior Member
Hi,

bei einem Review der Dokumentation für das Element <category> im Wiki im Rahmen der TT-Developer Telcos sind wir auf das Attribut @categoryPriority gestoßen. Dieses Attribut ist als String definiert und erlaubt beliebigen Freitext, der dann durch das lesende Programm interpretiert werden muss. Da der Standard keinerlei Vorgaben bzgl. des Inhalts macht, muss es eine Abstimmung zwischen Produzent und Konsument geben, was ja eigentlich durch den Standard vermieden werden soll. In der Developer Group ist keine aktive Verwendung des Attributs bekannt. Entsprechend hat sich die Gruppe dafür ausgesprochen dieses Attribut mit railML 2.5 für deprecated zu erklären. Sollte es Verwendungen des Attributs in der Community geben, die einem solchen Schritt entgegenstehen würden, bitte ich darum diese hier vorzustellen. Vielen Dank schon mal im Voraus.

-------------------------------------------------

during a review of the documentation for the element <category> in the Wiki within the TT-Developer Telco we came across the attribute @categoryPriority. This attribute is defined as string and allows any free text, which has to be interpreted by the reading program. Since the standard does not make any specifications concerning the content, there must be a coordination between producer and consumer, which should actually be avoided by the standard. No active use of the attribute is known in the Developer Group. Accordingly, the group has decided to declare this attribute deprecated with railML 2.5. If there are uses of the attribute in the community that would stand in the way of such a step, please introduce them here. Many thanks in advance.

Best regards, Milan


Milan Wölke - Timetable scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: @categoryPriority of <category> to be declared deprecated in version 2.5 [message #2284 is a reply to message #2277] Wed, 04 December 2019 16:32 Go to previous messageGo to next message
Janne Möller is currently offline  Janne Möller
Messages: 8
Registered: March 2019
Location: Oslo
Junior Member
Dear Milan and railML-community,

since I am new in the railML timetable community, I would first like to introduce myself: My name is Janne Möller and I work at the Norwegian Railway Directorate in Oslo. We are currently working on a unified usage of the timetable scheme (and possibly needed extensions) within the Norwegian railway sector.

For simulation purposes we want to use the abovementioned @categoryPriority, so we would very much like to keep this attribut. Though we will be using the free string to set in values that correspond integer values, with a higher value meaning a lower priority.

Additionally we have the requirement to specify the priority of a trainPart, in case it differs from the referenced category priority. We are planning to add an extension to a Norwegian version of railML2.4 (railML2.4nor), and would like to propose a category-attribute for train parts in future railML-versions. In railML2.4nor we will use this attribute with type integer.

Best regards,
Janne Möller
Re: @categoryPriority of <category> to be declared deprecated in version 2.5 [message #2289 is a reply to message #2284] Mon, 09 December 2019 13:56 Go to previous messageGo to next message
Milan Wölke is currently offline  Milan Wölke
Messages: 26
Registered: April 2007
Junior Member
Hi Janne,
thanks for your feedback and welcome to the community. Can you please outline the usecase for your intended use of these priorities? You mentioned simulation, could you provide some detail so we can better understand what you need to do. Maybe there is a better way of modelling this, after all the @categoryPriority is just a string...

Thanks in advance.

Best regards, Milan


Milan Wölke - Timetable scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: @categoryPriority of <category> in version 2.5 / Extension of train part [message #2291 is a reply to message #2284] Wed, 11 December 2019 21:21 Go to previous messageGo to next message
vpkolmorgen
Messages: 41
Registered: November 2004
Member
Dear Janne,

thank you for the feedback. railML.org welcomes the work on the uniform
use of the railML-TT schema in Norway.

Can you describe an usement/example for the use of
<railml><timetable><categories><category>@categoryPriority in Norway for
the wiki page and maybe also specify the using programme and use case?
Maybe we could contact this railML partner and ask for in-depth
documentation to publish in the wiki after discussion in the TT
developers group. This would help the community to use the element in a
proper manner.

Regarding the extension of the attributes of the train part, a modelling
suggestion here in the forum and an introduction in one of the upcoming
TT developer phone calls would certainly make sense. Ideally, the
extension in railML2.4nor would be identical to the new modelling in
railML 2.5, which would reduce the later conversion effort for all
participants.

A question: How should the priority be processed, if it is indicated at
the same time at the train part and at the category? Can you make the
corresponding railML2.4nor documentation (also about higher priority
ascending/descending) available to the railML community and the Wiki?

Thank you and kind regards,

Vasco
--
Vasco Paul Kolmorgen - Governance Coordinator
railML.org (Registry of Associations: VR 5750)
Phone railML.org: +49 351 47582911
Altplauen 19h; 01187 Dresden; Germany www.railML.org

Am 04.12.2019 um 16:32 schrieb Janne Möller:
> For simulation purposes we want to use the abovementioned
> @categoryPriority, so we would very much like to keep this
> attribut. Though we will be using the free string to set in
> values that correspond integer values, with a higher value
> meaning a lower priority.
>
> Additionally we have the requirement to specify the priority
> of a trainPart, in case it differs from the referenced
> category priority. We are planning to add an extension to a
> Norwegian version of railML2.4 (railML2.4nor), and would
> like to propose a category-attribute for train parts in
> future railML-versions. In railML2.4nor we will use this
> attribute with type integer.
>
> Best regards,
> Janne Möller
Re: @categoryPriority of <category> in version 2.5 / Extension of train part [message #2324 is a reply to message #2291] Mon, 10 February 2020 14:00 Go to previous messageGo to next message
Milan Wölke is currently offline  Milan Wölke
Messages: 26
Registered: April 2007
Junior Member
Any news here?

Milan Wölke - Timetable scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: @categoryPriority of <category> in version 2.5 / Extension of train part [message #2332 is a reply to message #2324] Wed, 19 February 2020 08:39 Go to previous messageGo to next message
Janne Möller is currently offline  Janne Möller
Messages: 8
Registered: March 2019
Location: Oslo
Junior Member
Dear Milan and Vasco,

Thank you for your feedback and apologies for the long answering time on my part.

We would like to specify a rank/priority for trains in timetable simulations using railML, as this characteristic is used for conflict solution during the simulation process. Also are we planning to use the information about the rank of a train or a category in the timetabling process to determine for example crossing patterns.

To enable the possibility to not only define a rank/priority for all train parts belonging to one category, but also for deviation of one or several train parts, we would highly welcome the introduction of a new attribute with type integer that can contain this information within the element <trainPart> in railML2.5. For the development of railML2.4 with Norwegian extensions, we are planning to use a new attribute called @nor:rank, also within <trainPart> with type integer. We suggest that the smaller the number the higher the priority of the train part is, with 1 being the highest priority.

Concerning the attribute @categoryPriority we see two possibilities:

  1. We could use the attribute @categoryPriority with the same possible values like in @nor:rank because they have to be comparable. But yes, the actual type of @categoryPriority is a String.
  2. Alternatively, in the Norwegian extensions we could introduce the attribute @nor:rank with type integer also under <category>, thus making it clear that the two @nor:rank attributes are connected and ensuring the same datatype. This seems to be a cleaner solution that we would prefer. Could it be a possibility to deprecate @categoryPriority as planned, but introduce an attribute like @rank in 2.5 instead?
As for having a rank/priority in both <category> and <trainPart> we suggest a hierarchy: the value of <category> applies to all <trainPart> elements of this category unless something different is specified in <trainPart>.

What are your thoughts on this?

Best regards,
Janne Möller
Re: @categoryPriority of <category> in version 2.5 / Extension of train part [message #2348 is a reply to message #2332] Wed, 26 February 2020 11:58 Go to previous message
Milan Wölke is currently offline  Milan Wölke
Messages: 26
Registered: April 2007
Junior Member
Hi Janne,

thanks for the explanation. With type integer this makes a lot more sense. From my point of view the best solution here would be to declare @categoryPriority deprecated as it simply isnt clear how to use it. In consequence data exchange regarding this attribute is not really possible without additional coordination between the two data exchange partners. In order to distinguish two versions of the same train a rank attribute sounds reasonable. However there are two questions I see here:
1) trainPart or category? I guess this depends on how the simulation system classifies the data. I think, trainPart would be more flexible, though.
2) is this related to the status/processStatus thread we have? basically this is also different versions of a train.

I suggest to discuss those questions in the next developer telco.

Best regards, Milan


Milan Wölke - Timetable scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

[Updated on: Wed, 26 February 2020 12:00]

Report message to a moderator

Previous Topic: Extension of Enum @trainUsage of <category>
Next Topic: Attribute processStatus to be declared deprecated for <train>, <trainPart> and <trainGroup>
Goto Forum:
  


Current Time: Fri Feb 28 18:17:13 CET 2020