| Re: Visualization: Proposal to move to a separate subschema [message #2530 is a reply to message #2527] |
Mon, 07 September 2020 10:38   |
Dirk Bräuer
Messages: 311
Registered: August 2008
|
Senior Member |
|
|
Dear Thomas,
in general, I welcome and agree to your approach. I have no objections against
- move the railML visualization to a new subschema,
- add ellipticProjection
- allow an explicit grouping of visualization objects.
However, I have some minor concerns:
> ...from a database/object-oriented standpoint (normalization), there
> should be no circular references.
This could even be a general thesis. But it is rather a theoretic, "nice to have" rule with not much practical background.
Please be aware that railML is originally designed as a file format for data-exchange, not as a structure for databases. RailML data structures normally will have to be converted into the actual database model (in any) of the certain software at import and converted from such a database model (if any) at export. With that in mind, and as a programmer for import and export of data exchanges with railML, I don't see any practical objections against "circular references" between top-level elements under <railML> as long as there are no actual semantical circular references.
We even already have such circular references and we might have them in future as well. For instance, all aspects of time are a more general phenomenon than infrastructure. Therefore, <times> would have to be excluded from <timetable> and from <infrastructure> into a more general top-level element. But this is not the case in railML and it is probably not practical. Elements such as <timetablePeriod> and <operatingPeriod>s are defined under <timetable> for traditional (and practical, not to write obvious) reasons. They might be referenced from <infrastructure> to express opening/closing times, maintenance periods or the change of infrastructure during time in general (closure of or creating new tracks, lines, changing permitted speeds, changing track layouts). Of course, <infrastructure> does also need to be referenced from <timetable>. So, we do have "circular references" between <infrastructure> and <timetable> but not in a problematic way.
I still would agree with your thesis but not as a strict rule, rather in a "recommendational", nice-to-have kind.
Best regards,
Dirk.
|
|
|
|
Members
Search
Help
Login
Home
