| Re: Extension suggestion for alternativeSectionTT [message #2391 is a reply to message #2388] |
Tue, 10 March 2020 17:10   |
Dirk Bräuer
Messages: 311
Registered: August 2008
|
Senior Member |
|
|
Dear Torben,
from a general railML view, I would not be happy with your suggestion to encode alternative paths at a <trainPart>. The original idea of a <trainPart> was that it should be the elementary, most little and impartible part of a train. With that reason, we already denied requests of making other attributes of <trainPart> divisible like formation or load. We should write that we should be consequent here...
So, I would expect hat for an alternative path, the <train> must be copied and the options connected with @trainNumber, @additionalTrainNumber and @scope should be used to encode two <train> elements as alternatives (same train number, different scope and/or different additionalTrainNumber).
Everything else leads to (even more) "uncontrolled growth".
I know, live is full of compromises and for the certain Norwegian use case, your suggestion may be easier and more direct. So please understand my post rather as a remark in general, a warning, but no decision on your case - this would be up to the community and the coordinators.
Only to avoid misunderstandings:
With "alternative paths" you mean just the route of the train (way along the network) but no different arrival/departure/run times? If you only copy the element <sectionTT>, you would not be able to encode different arrival/departure/run times. This is also a general problem I see, because the background you mention ("if the planned path is not available") may concern the route as well as the times! So, to encode alternative paths in general railML, I would expect being able for alternative routes as well as alternative times.
Best regards,
Dirk.
|
|
|
|
Members
Search
Help
Login
Home
