| @categoryPriority of <category> to be declared deprecated in version 2.5 [message #2277] |
Tue, 26 November 2019 18:03  |
Milan Wölke
Messages: 146
Registered: April 2007
|
Senior 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 #2289 is a reply to message #2284] |
Mon, 09 December 2019 13:56  |
Milan Wölke
Messages: 146
Registered: April 2007
|
Senior 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 |
Vasco Paul Kolmorgen
Messages: 61
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 #2332 is a reply to message #2324] |
Wed, 19 February 2020 08:39 |
Janne Möller
Messages: 14
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:
- 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.
- 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 |
Milan Wölke
Messages: 146
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 |
|
|
|
|
|
| Re: @categoryPriority of <category> in version 2.5 / Extension of train part [message #2472 is a reply to message #2414] |
Fri, 26 June 2020 13:38 |
Milan Wölke
Messages: 146
Registered: April 2007
|
Senior Member |
|
|
Hi all,
I wanted to update the comunity on what happend regarding this topic; After the last post we discussed this in the TT-developer group. We came to the conclusion that since there actually is usage we will not deprecate this attribute. However we decided that we improve the wiki documentation by adding a best practice description (https://wiki2.railml.org/index.php?title=TT:category). There will be no change to the xsd regarding this issue (thus no trac ticket).
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 #2478 is a reply to message #2472] |
Wed, 01 July 2020 10:34 |
Dirk Bräuer
Messages: 313
Registered: August 2008
|
Senior Member |
|
|
Dear Janne, Nadia, Milan and "along-readers",
concerning the question
> 1) trainPart or category?
I would say: <trainPartSequence>!
- With a @rank at <trainPart>, we would have the problem that a train consisting of <trainPart>s with different @ranks, which rank would the resulting train have? A mean value? Since Janne wrote she needs that attribute for a priority of trains in a simulation software, railML should provide a value per train.
- A @rank at <category> would fit since there is a @categoryRef at <trainPartSequence>. But I'm afraid in some countries the meaning of categories already lost their operational background, they could have a rather commercial background. I can easily imagine that many trains have the same <category> for formal reasons but different priorities. In Germany, currently all "private" trains (non-DB-trains) must have one of the limited categories starting with "D", so there is not much freedom to express priorities. At least the "government" categories have much more expression of priorities.
So, I think it would be good to separate categories and priorities, to be flexible giving two trains with the same <category> a (slightly) different priority. Since in every timetable there should be trains of the same category meeting each other, this would also allow to give the simulation software a "hint" of which one would be the more important by traffic means (rush hour direction or such).
So, I would recommend to keep a @rank at <category> and to add a @rank at <trainPartSequence> which optionally overwrites any @rank possibly inherited from <category>.
Concerning the question
> the actual type of @categoryPriority is a String.
I would agree that we can clarify this by constrains and best practices.
Concerning the question
> lower value means a higher priority
I would agree with that rule.
Best regards,
Dirk.
|
|
|
|
Members
Search
Help
Login
Home
