| Re: Delay Causes Representation in RailML [message #820 is a reply to message #818] |
Wed, 10 October 2012 13:42   |
Susanne Wunsch railML
Messages: 0
Registered: January 2020
|
|
|
|
Hi Matteo and others interested,
Thanks for your introduction and for sharing your knowledge with the
railML community.
matteoanelli(at)nttdatacom (Matteo Anelli) writes:
> Since the project want to integrate the FICHE UIC 450-2 delay causes
> (a two-digit number) I'd like to see some extended attributes on the
> Delay Entity.
I don't really like the idea of the two-digit code for several reasons.
* The code in the UIC document may change (even with a very low
likelihood).
* In order to fill out or understand the attribute one has to purchase
the UIC document for currently 178 EUR.
> I think a generic attributes field should be sufficient,
That only helps out for the moment where the information should be
transferred between two systems that explained their special additions
each other.
> if not a string field for "causes".
That would enable the semantically fixed right position in the railML
tree for data exchange. But "open string fields" entail the risk that
two systems define the same meaning with different words or only
different syntax.
> It's that possible?
The string field and the generic extension would be possible as quick
fix. Nevertheless I would prefer an approach to define the delay causes
as extensible enumeration lists.
I would presume there could be multiple causes to be defined for a
single delay. Am I right?
Could you provide a suggestion very soon? (We currently feature freeze
the new 2.2 release)
Thanks again and kind regards...
Susanne
--
Susanne Wunsch
Schema Coordinator: railML.common
|
|
|
|
Members
Search
Help
Login
Home
