| Re: Production interfaces with further limitations [message #2374 is a reply to message #2365] |
Mon, 09 March 2020 10:51  |
Dirk Bräuer
Messages: 311
Registered: August 2008
|
Senior Member |
|
|
Dear Stefan, Milan and all,
first: I do not want to disagree with Milan's statement.
But I think we must distinguish between railML in general and certain concrete, practical interfaces (instances of railML). railML gives a base standard which can be substantiated by practical interfaces. (From railML 3 at least, they are called "use cases".) Such a substantiation or use case can define more restrictions than railML in general.
For instance, in some cases a train number (value of attribute trainNumber) can be alphanumeric, so can have letters. "2S05" may be a typical British train "number", 32768a may be a German train number of a commercial train in some use cases. But many experts and many use cases linked with passenger information would probably say that a train number always must be pure numerical. So it may of course be possible that for instance, a valid railML file containing a non-numerical train number may be refused for a certain use case.
Since the attribute code is something similar to train number (an external identifier), I can at least imagine the same concerning code. Of course you can always expect the importing software to replace the incompatible identifier by one which respects the own restrictions, but exchanging an identifier would at the same time mean incompatibility. So, such a case is not easy, the discussion on external identifiers in railML is a very long one and life is full of compromises...
Best regards,
Dirk.
|
|
|
|
Members
Search
Help
Login
Home
