| Re: Timetable data elements for railVIVID [message #1576 is a reply to message #1569] |
Thu, 18 May 2017 12:59   |
Dirk Bräuer
Messages: 311
Registered: August 2008
|
Senior Member |
|
|
Dear all,
I am sceptical that this approach leads to a practical solution.
From my understanding:
- The aim is to avoid a railML file with only "any-fields" (after a
minimum of <railML>).
- The statistic approach to reach this, which is discussed here, shall
lead to a kind of "cover ratio" of railML in a railML file.
I see the following problems:
- Nobody will know which minimum "cover ratio" will be acceptable.
- It depends on the use case which elements are obligatory and which
are optional. So, this approach conflicts with the concept of use cases.
I personally don't think that this should be solved in an automatic and
statistic way but if you want to follow this approach, I would recommend
to count only this elements which are "common to all use cases". Of
course nobody knows all use cases of the future, but analogously it
means: Relatively view, basic elements only. So most acceptable railML
files will have a high "cover ratio".
The current list, from my opinion, is too much unbalanced by containing
too many special and possibly still not all basic elements.
Best regards,
Dirk.
|
|
|
|
Members
Search
Help
Login
Home
