Home » railML newsgroups » railml.timetable » blockPart mission="other:..." (A consumer can't handle inspection, instead suggests "other:...")
icon5.gif  blockPart mission="other:..." [message #2371] Thu, 05 March 2020 23:41 Go to next message
Stefan de Konink is currently offline  Stefan de Konink
Messages: 5
Registered: August 2019
Junior Member
We have been informed that a RailML consumer is not able to handle mission="inspection", instead they request to use a private definition prefixed by "other:". I read RailML mandated to use the predefined enumerations for types that have been defined in the standard, before resorting to alternatives. Would my production interface have certification problems if these common types would not be used?
Re: blockPart mission="other:..." [message #2373 is a reply to message #2371] Mon, 09 March 2020 10:25 Go to previous messageGo to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 311
Registered: August 2008
Senior Member
Dear Stefan,

I would say it depends on what exactly would be the "other:..." value and what would be semantically behind it.

In general, it is right that using an extension (including "other:...") for something which is already defined in railML is not the meaning of a standard, leads to incompatibility and therefore should not be certified.

However, there may be a reasonable semantic difference between mission="inspection" and what your customer/consumer needs. If so, they should give an explanation why the usage of mission="inspection" would be misleading. railML can naturally not foresee everything which occurs but railML wants to define a standard for compatibility in general.

But in this certain case, since mission="inspection" has no much fixed meaning/definition by railML, I can hardly imagine that.

Best regards,

P.S.: To avoid misunderstandings: This is an opinion of a member who is called "senior" by the railML system (which hurts me a bit); it is no official statement concerning certification, where I have no entitlement.
Re: blockPart mission="other:..." [message #2389 is a reply to message #2373] Tue, 10 March 2020 15:26 Go to previous message
Milan Wölke is currently offline  Milan Wölke
Messages: 143
Registered: April 2007
Senior Member
Hi Stefan and Dirk,

I completely agree with what Dirk said. In general an enumeration should not be extended if there is a standardized value available already. However in certain cases there may be the need for further distinction. But that would need to be explained. Certification actually checks for issues like this in particular.

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: Mon, 06 April 2020 20:55]

Report message to a moderator

Previous Topic: forgotten attribute <operatingPeriod> @dayOffset and its future
Next Topic: Extension of Enum @trainUsage of <category>
Goto Forum:

Current Time: Sat Jul 20 07:35:11 CEST 2024