Home » railML newsgroups » railML.infrastructure » Re-factoring of <infraAttributes>
Re: Re-factoring of <infraAttributes> [message #1947 is a reply to message #1846] Mon, 03 September 2018 18:15 Go to previous messageGo to previous message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 311
Registered: August 2008
Senior Member
Dear Christian,

in general, I agree with your statement.

But concerning

> please use <infraAttributes> for global parameters and use <*change> elements for all changes (and local definitions) of parameters

I want to write: Careful please! This may create much additional effort for importing software.

Please always be aware that an importing software has to "search" and "check" all places where an attribute may be given: There may be implicit default values, global values (global for one railML file) and <*change> elements.

- An importing software may be assuming that a track is straight and level as long as there is no <gradientChange> or <radiusChange> given.

- But, in case there are global values for gradients and curves, does that mean that the global value applies at each <track> until the first <*change> applies or does it mean that the global value only applies if the <track> has no individual <*change> elements?

- Is a <track> which has no <electrificationChange> a non-electrified track or a track which is electrified with the global value? I guess the latter. So, for a network which has all-electrified tracks except one line, is it still possible to use the global value (of 'electrified') and overwrite it at the one <track> with 'non-electrified'?

I agree with you that it is "appetising" to make the gauge global for most of the tracks of a network.
But please, when allowing this

- Do not allow it in existing railML versions (like 2.0, 2.2, 2.3 etc.). Do only allow it in future versions. We should avoid that the same railML file suddenly means something different.

- Always define (in Wiki or XSD) weather and where a global value applies (before the first <*change> or in case there are no <*change>s at all).

- Always ask yourself weather it is possible to overwrite the global value with all other possible values (not to "hide" an implicit default value).

- Do not allow global values for all <*change> elements across-the-board. A global value for gauge may be nice to have but in my opinion, we do not need global values for radius or gradient (to overwrite 'level' and 'straight').

With best regards,
Dirk.
 
Read Message
Read Message
Read Message
Read Message
Previous Topic: Extension suggestion for on which (track)side of a crosSection the referenced ocp is
Next Topic: More detailed 'speed change' definitions
Goto Forum:
  


Current Time: Mon May 13 18:45:37 CEST 2024