Forum - RDF feed
https://www.railml.org/forum/index.php
Request for a new optional attribute for train coupling and sharing
https://www.railml.org/forum/index.php?t=rview&goto=1341&th=441#msg_1341
we would like to make a petition for one more attribute in railML 2.3 at
the meeting tomorrow in Berlin. In preparation of that meeting, we have
created a document as a kind of (electronic) hand-out. Following Vasco's
suggestion, I provide a download link for the document here for everyone
who wants to take part in the discussion: [1].
It is not a big matter. The suggested attribute and background is
described on the fist two pages only. The other pages contain examples only.
Also, it is probably clear that the new attribute will last for 2.3 only
and will be obsolete with 3.0 due to the "re-factoring" already planned.
But, as long as we do not have 3.0, we have a problem without that
attribute in 2.2/2.3. That's why we (iRFP) have to do the attribute
anyway, at least as a custom attribute. For more compatibility, I would
prefer an official attribute rather than a custom one.
Best regards,
Dirk Bräuer.
[1] http://download.irfp.de/umsteigefreie_verbindungen_in_railml .pdf]]>Dirk Bräuer2016-01-21T15:02:29-00:00Re: Request for a new optional attribute for train coupling and sharing
https://www.railml.org/forum/index.php?t=rview&goto=1347&th=441#msg_1347
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]]>Philip Wobst2016-02-18T15:31:27-00:00Re: Request for a new optional attribute for train coupling and sharing
https://www.railml.org/forum/index.php?t=rview&goto=1348&th=441#msg_1348
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]]>Dirk Bräuer2016-02-26T09:02:26-00:00Re: Request for a new optional attribute for train coupling and sharing
https://www.railml.org/forum/index.php?t=rview&goto=1356&th=441#msg_1356
railML's Timetable developer meeting in Berlin on June 2nd, 2016.
Conclusion: As a solution in a (possibly) upcoming railML 2.x is not urgent as a <any> field was used by the proposer. The issue has to be take into consideration for the refactoring in railML 3.x and -if not solved by the refactoring process- to be discussed again.
Regards,
--
Vasco Paul Kolmorgen
railML.org Coordinator
Dresden; Germany www.railml.org]]>Vasco Paul Kolmorgen2016-06-02T10:51:12-00:00