| Re: Request for a new optional attribute for train coupling and sharing [message #1348 is a reply to message #1347] |
Fri, 26 February 2016 10:02   |
Dirk Bräuer
Messages: 311
Registered: August 2008
|
Senior Member |
|
|
Dear Philip,
I know about the "conclusion" of the meeting in Berlin on this subject
and of course, we can easily accept it by implementing an own railML
extension.
I only want to warn because I think that "only for two data consumers"
should not be a real reason to refuse a suggestion. Always somebody will
be the first, won't it?
I think any reason for refusing a suggestion should be a technical one.
So which technical reason can be said against our suggestion? So far, I
think iRFP has always tried to argue with technical background so
shouldn't we have the right to get a technical answer as well, should we?
--
My concern is not a personal or embittered one but I am worried about
that we come to a stand still with the development of <timetable> if we
block improvements in railML 2.x and at the same time do not go ahead
with 3.x. iRFP has also made several attempts to start a <timetable> 3.x
with came to nothing so far, and in the case of the Berlin meeting do
not even have been discussed.
Sorry, but I think we have come to a stand still. I ask myself what we
should get some greater steps forward with <timetable> if even the
smaller steps are blocked. You should be careful not to administrate a
<monster> 2.x which went into a mess.
Best regards,
Dirk.
---
Am 18.02.2016 um 16:31 schrieb Philip Wobst:
> Dear Dirk,
>
> this topic was discussed during the timetable developer
> meeting in Berlin last month and the conclusion was that it
> is not needed as a temporary solution for 2.3 if the use
> case exists only for iRFP and one other potential data
> consumer.
> If you do have any further questions please do not hesitate
> to contact me directly.
>
> BR, Philip
|
|
|
|
Members
Search
Help
Login
Home
