Home » RailTopoModel newsgroup » RailTopoModel » Validity times
Validity times [message #1734] Tue, 20 March 2018 15:49 Go to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 140
Registered: January 2016
Senior Member
Dear all,

the information that a NetElement is valid (for operation) is currently
modelled with the attributes @validFrom and @validTo. A resulting small
example looks like this:

<netElement ... validFrom="2018-01-01" validTo="2018-12-31"/>

This implementation of validity times has two drawbacks:
* It is not possible to model other infrastructure states, e.g. "under
construction"
* It does not allow to model segmented validity times, e.g. before and
after a construction blocking

The second point is really essential. Therefore, I propose to change the
RTM modelling in the following way: instead of attributes @validFrom and
@validTo, use a repeatable child element <valid> with attributes @from
and @to to define the different segments of validity time. The resulting
small example may look like this:

<netElement ...>
<valid from="2018-01-01" to="2018-06-29"/>
<valid from="2018-07-02" to="2018-12-31"/>
</netElement>

Any feedback is highly appreciated...

Best regards
Christian

--
Christian Rahmig - Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Phone Coordinator: +49 173 2714509; railML.org: +49 351 47582911
Altplauen 19h; 01187 Dresden; Germany www.railml.org
Re: Validity times [message #1867 is a reply to message #1734] Wed, 04 July 2018 06:58 Go to previous message
christian.rahmig is currently offline  christian.rahmig
Messages: 140
Registered: January 2016
Senior Member
Dear all,

although there has not been an answer on that topic so far, we need to
find a solution for the problem, because it is essential for railML 3.1
and related "beta 2" version scheduled for end of August [1].

In particular, I already implemented the required RTM related change in
railML 3.1. The latest version of railML 3.1 is available in the railML3
SVN trunk [2]. An overview of all the changes is provided in [3].

In this overview, replacing validity attributes by new Base class
Validity to allow for multiple validity times is marked as issue number 3.

[1]
https://www.railml.org/en/public-relations/news/reader/33rd- railml-conference-and-version-roadmap.html
[2] https://svn.railml.org/railML3/trunk
[3]
http://forum.railML.org/userfiles/2018-07-02_railml_railml3- induced-changes-to-rtm12.pdf

Best regards
Christian

Am 20.03.2018 um 15:49 schrieb Christian Rahmig:
> Dear all,
>
> the information that a NetElement is valid (for operation) is currently
> modelled with the attributes @validFrom and @validTo. A resulting small
> example looks like this:
>
> <netElement ... validFrom="2018-01-01" validTo="2018-12-31"/>
>
> This implementation of validity times has two drawbacks:
> * It is not possible to model other infrastructure states, e.g. "under
> construction"
> * It does not allow to model segmented validity times, e.g. before and
> after a construction blocking
>
> The second point is really essential. Therefore, I propose to change the
> RTM modelling in the following way: instead of attributes @validFrom and
> @validTo, use a repeatable child element <valid> with attributes @from
> and @to to define the different segments of validity time. The resulting
> small example may look like this:
>
> <netElement ...>
> <valid from="2018-01-01" to="2018-06-29"/>
> <valid from="2018-07-02" to="2018-12-31"/>
> </netElement>
>
> Any feedback is highly appreciated...
>
> Best regards
> Christian
>


--
Christian Rahmig - Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Phone Coordinator: +49 173 2714509; railML.org: +49 351 47582911
Altplauen 19h; 01187 Dresden; Germany www.railml.org
Previous Topic: Lateral location of elements
Next Topic: Proposal for incorporating length information in RTM NetElement
Goto Forum:
  


Current Time: Thu Aug 16 07:58:14 CEST 2018