Home » railML newsgroups » railml.timetable » @categoryPriority of <category> to be declared deprecated in version 2.5
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 messageGo to previous message
Milan Wölke is currently offline  Milan Wölke
Messages: 139
Registered: April 2007
Senior 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

 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Continuation: different stop types / Mehrere Betriebshalt-Haltegründe usw.
Next Topic: [railML2] Usage of //ocpTT/times/@scope
Goto Forum:
  


Current Time: Sun May 05 07:10:15 CEST 2024