Home » railML newsgroups » railML.infrastructure » Steckenunterbruch/line blocking
Steckenunterbruch/line blocking [message #483] Mon, 03 December 2012 17:25 Go to next message
renato.kluser is currently offline  renato.kluser
Messages: 1
Registered: December 2012
Junior Member
ENGLISH SUMMARY: The MGB railway uses railML 2.0
for data exchange from our timetabling system to
our disposition system. Currently we need an
extension of the standard to transfer line
blockings from one system to another.

Hallo railML-Partner,

wir, die Matterhorn Gotthard Bahn (MGB),
betreiben ein 144 km langes Meterspurnetz im
Süden der Schweiz. Zum Datenaustausch zwischen
unserem Fahrplansystem FBS und dem
Kundeninformations- und Dispositionssystem KIS nutzen wir railML 2.0.

Nun möchten wir auch noch die in FBS verwalteten
Streckenunterbrüche an das Dispositionssystem
übergeben und schlagen daher eine Erweiterung des
railML-Standards vor. Die Abbildung folgende
Arten von Unterbrüchen wäre für uns unerlässlich:

- Strecke von Betriebsstelle BRMG (Brig) bis Visp
(VISP) gesperrt vom 15. Juli 2012 22.00 Uhr bis
29. Juli 2012 4.00 Uhr; Grund: Bauarbeiten am Gleis
- Strecke von Oberwald (OBW) bis Realp (REAL)
gesperrt im Zeitraum vom 3. Oktober 2012 bis 16.
Oktober 2012; jeweils zwischen 22.45 Uhr bis 3.45
Uhr am Folgetag; Grund: Fahrleitungsrevision
- Strecke 140 von km 22,790 bis 26,186 gesperrt
bis 3. Dezember 2012; 16.00 Uhr

Eine Erweiterung der Eigenschaften eines
Unterbruchs (z.B. 'nur für elektrische
Fahrzeuge', 'nur für Fahrzeuge des Typs ...'
usw.) und zusätzliche Informationen wie Busersatz
usw. wäre denkbar, ist aber für uns nicht dringlich.

Beste Grüsse,

Renato Kluser
Betrieb
Verkehrsplanung und Sicherheit

Matterhorn Gotthard Bahn
Bahnhofplatz 7
CH-3900 Brig
http://www.mgbahn.ch



--
----== posted via PHP Headliner ==----
Re: Steckenunterbruch/line blocking [message #486 is a reply to message #483] Mon, 03 December 2012 14:50 Go to previous messageGo to next message
Christian Rahmig is currently offline  Christian Rahmig
Messages: 151
Registered: January 2011
Senior Member
*** English version below ***

Hallo Renato,

vielen Dank für das Posting. Die darin angesprochene Thematik der
(zeitweisen) Sperrung von Strecken bzw. Streckenabschnitten wurde im
Trac ticket [1] bereits gedanklich festgehalten und kann in einer ersten
Version noch in railML 2.2 berücksichtigt werden. Auf Grund der Kürze
der Zeit werden wir uns dabei auf die minimalen Anforderungen beschränken.

[1] https://trac.assembla.com/railML/ticket/156

Viele Grüße


*** English version ***

Dear Renato,

thank you very much for your posting. The topic of a (temporary) closing
of a track or track part has been thought about within Trac ticket [1].
We can implement a first version within the upcoming railML 2.2. Since
time-to-release is getting short, we will focus on the main aspects only.

[1] https://trac.assembla.com/railML/ticket/156

Regards

--
Christian Rahmig
railML.infrastructure coordinator

Am 03.12.2012 17:25, schrieb Kluser Renato:
> ENGLISH SUMMARY: The MGB railway uses railML 2.0
> for data exchange from our timetabling system to
> our disposition system. Currently we need an
> extension of the standard to transfer line
> blockings from one system to another.
>
> Hallo railML-Partner,
>
> wir, die Matterhorn Gotthard Bahn (MGB),
> betreiben ein 144 km langes Meterspurnetz im
> Süden der Schweiz. Zum Datenaustausch zwischen
> unserem Fahrplansystem FBS und dem
> Kundeninformations- und Dispositionssystem KIS nutzen wir railML 2.0.
>
> Nun möchten wir auch noch die in FBS verwalteten
> Streckenunterbrüche an das Dispositionssystem
> übergeben und schlagen daher eine Erweiterung des
> railML-Standards vor. Die Abbildung folgende
> Arten von Unterbrüchen wäre für uns unerlässlich:
>
> - Strecke von Betriebsstelle BRMG (Brig) bis Visp
> (VISP) gesperrt vom 15. Juli 2012 22.00 Uhr bis
> 29. Juli 2012 4.00 Uhr; Grund: Bauarbeiten am Gleis
> - Strecke von Oberwald (OBW) bis Realp (REAL)
> gesperrt im Zeitraum vom 3. Oktober 2012 bis 16.
> Oktober 2012; jeweils zwischen 22.45 Uhr bis 3.45
> Uhr am Folgetag; Grund: Fahrleitungsrevision
> - Strecke 140 von km 22,790 bis 26,186 gesperrt
> bis 3. Dezember 2012; 16.00 Uhr
>
> Eine Erweiterung der Eigenschaften eines
> Unterbruchs (z.B. 'nur für elektrische
> Fahrzeuge', 'nur für Fahrzeuge des Typs ...'
> usw.) und zusätzliche Informationen wie Busersatz
> usw. wäre denkbar, ist aber für uns nicht dringlich.
>
> Beste Grüsse,
>
> Renato Kluser
> Betrieb
> Verkehrsplanung und Sicherheit
>
> Matterhorn Gotthard Bahn
> Bahnhofplatz 7
> CH-3900 Brig
> http://www.mgbahn.ch
>
>
>
Re: Steckenunterbruch/line blocking [message #490 is a reply to message #486] Mon, 03 December 2012 16:39 Go to previous messageGo to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 311
Registered: August 2008
Senior Member
Dear Renato,

thank you for your post, too, from my side.

I think the line blockings are a matter of <timetable> rather than
<infrastructure>. We should move there with the discussion.

I can provide a recommendation of a RailML structure for these blockings
very soon if the community is interested.

Best regards,
Dirk.
Re: Steckenunterbruch/line blocking [message #494 is a reply to message #490] Mon, 03 December 2012 20:31 Go to previous messageGo to next message
Christian Rahmig is currently offline  Christian Rahmig
Messages: 151
Registered: January 2011
Senior Member
Dear Dirk,

Am 03.12.2012 16:39, schrieb Dirk Bräuer:
> Dear Renato,
>
> thank you for your post, too, from my side.
>
> I think the line blockings are a matter of <timetable> rather than
> <infrastructure>. We should move there with the discussion.

I think, the blocking of a track or parts of lines fulfills both
aspects: it is situated somewhere between infrastructure and timetable.
In general, I want to define a certain part of the infrastructure to be
not available for any operational usage. Therefore, it is set to be
disabled. From the timetable perpective I want to tell the train an
operation schedule, which, of course, takes the closed infrastructure
into consideration.

In summary: we need both, a direct reference to the infrastructure,
which is disabled, and a reference to the timetable or the operating
period, during which the infrastructure is disabled.

Thank you for your offer anyway. Probably you can give a short sketch of
an example in order to clarify the timetable perspective towards closed
infrastructure?

Regards

--
Christian Rahmig
railML.infrastructure coordinator
Re: Steckenunterbruch/line blocking [message #496 is a reply to message #494] Mon, 03 December 2012 21:13 Go to previous messageGo to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 311
Registered: August 2008
Senior Member
please follow me to:

[1]
http://www.railml.org/forum/ro/index.php?group=2&offset= 0&thread=93&id=350

Dirk.
Re: Steckenunterbruch/line blocking [message #500 is a reply to message #496] Wed, 05 December 2012 11:24 Go to previous messageGo to next message
Christian Rahmig is currently offline  Christian Rahmig
Messages: 151
Registered: January 2011
Senior Member
Dear Dirk,

Am 03.12.2012 21:13, schrieb Dirk Bräuer:
> please follow me to:
>
> [1]
> http://www.railml.org/forum/ro/index.php?group=2&offset= 0&thread=93&id=350

for getting a connection to another forum, it is better to use the
followup-tag. However, I still think, that we are talking about an
infrastructure aspect and I hope the next lines can clarify my opinion:

> First, the easy things:
>
> <trackBlockings>
> <trackBlocking id=... name=… description=… remarks=… />
> - further properties see below -
> </trackBlocking>
> </trackBlockings>

Your idea limits the blocking to tracks, which is quite a static
approach and, furthermore, need to be extended very soon. Despite a
certain track, also a signal or a balise or a switch etc. can be
disabled in the sense of "is not available for operation". Therefore, I
suggest to define the "disabled" feature as a child elment for all the
relevant infrastructure objects, e.g. tracks, switches, signals.

> Now to the real properties. These could be simple attributes of
> <trackBlocking> from my side but could also be sub-elements.
> Sub-elements may be preferred to declare constraints but from my side,
> the constraints are not too much difficult so Wiki should be enough for
> them.
>
> <trackRefs>, trackRef=…
> - reference to one or more <track>.id
> - at least one must be given
> - more than one is typical for a blocking of all tracks of a
> multiple-track line (“line blocking” was original intended)
>
> fromOcpRef=…, toOcpRef=…
> - compulsory attributes
> - references to <ocp>.id

Again, the attributes that you propose here, are only valid for track
blockings. We may think about allowing for definition of points on
tracks, from where on the track is blocked. However, since the
"disabled" sub-element will be available for all relevant tracks, there
is no need to define a length of the blocking section in form of a
"from-to" attribute group.

> validity Period: should be a “choice” of exactly one of the following
> two options:
>
> a) <repeating operatingPeriodRef=… startTime|startAfterTrainRef =…
> endTime|untilBeforeTrainRef=… />
> - operatingPeriodRef is compulsory
> - startTime/startAfterTrainRef and endTime/ untilBeforeTrainRef are to
> be used “disjunctive”
> - startAfterTrainRef/untilBeforeTrainRef are references to <train>.id
> - The blocking is to be repeated at each of the days of the
> <operatingPeriod> from start time to end time or trains. The trains must
> operate at the given days.
>
> b) <non-stop startDate= endDate= startTime|startAfterTrainRef =…
> endTime|untilBeforeTrainRef=… />
> - startDate and endDate are compulsory
> - startTime/startAfterTrainRef and endTime/ untilBeforeTrainRef are to
> be used “disjunctive”
> - startAfterTrainRef/untilBeforeTrainRef are references to <train>.id
> - The blocking happens one time non-stop throughout from
> startDate+startTime/train until endDate+endTime/train. The trains must
> operate at the given days.

The definition of time periods during which the infrastructure is
disabled is not the task of the infrastructure schema. Here, I suggest
to just implement a reference from the <disabled> element to an
operating period.

Further comments appreciated...

Regards

--
Christian Rahmig
railML.infrastructure coordinator
Re: Steckenunterbruch/line blocking [message #501 is a reply to message #500] Wed, 05 December 2012 20:55 Go to previous messageGo to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 311
Registered: August 2008
Senior Member
> for getting a connection to another forum, it is better to use the
> followup-tag.

I don't know what a follow-up tag is.

> Your idea limits the blocking to tracks

That was my intention. The original question was on blocking of lines
only. I do not want to solve problems we don't have now.

Some days ago, somebody wrote
> we will focus on the main aspects only.

> However, since the "disabled" sub-element will be available for all
> relevant tracks, there is no need to define a length of the blocking
> section in form of a "from-to" attribute group.

But then there would be no possibility do "block a part of an <element>"
such as part of a track (sub-section of a track). In the world of
timetabling, we do normally not always know the exact elements which are
disabled or which are the reasons for a blocking.

A typical problem (to solve here) is "line/track is blocked from ... to
...." with from/to being mileages or stations. Since trains can operate
between stations only, the only relevant aspect for timetabling is between
which stations a track is closed.

Anyway, I think we have two very different views of the problem with each
one being entitled. So I do not want to say that a possibility to declare
any infrastructure element as disabled wouldn't be useful. But currently,
the problem was something else on the much less detailed level of
timetabling.

> Here, I suggest to just implement a reference from the <disabled>
> element to an operating period.

Such a reference would - as far as I know - the first time we would create
such a "forward-reference". Forward in the meaning of "from infrastructure
to timetable". We already have many references from timetable to
infrastructure which are "natural" since one _first_ needs infrastructure
_before_ one can operate a train.

To have both directions, I would think is like "circular references" which
sometimes can become problematic in informatics. In my opinion, a software
first has to import <infrastructure> before it can import <timetable>. So
it wouldn't be able to dissolve the references from infrastructure to
timetable when importing.

But this is my opinion only.

Dirk.
Re: Steckenunterbruch/line blocking [message #506 is a reply to message #483] Fri, 07 December 2012 18:01 Go to previous messageGo to next message
horst.naujoks is currently offline  horst.naujoks
Messages: 5
Registered: December 2012
Junior Member
Hi Renato

I'm a developer at Qnamic AG
( http://http://www.railml.org//index.php/entwickler.html?show =35) and we
using RailML in different contexts in
our products.

I've have some questions regarding your request:

1. Do you think the information about disabled tracks or lines is more
related to the infrastructure or the time timetable part of RailML? I
assume
that you answer depends on what exactly is transfered from FBS to your KIS
system.

2. In one of the project I'm working on, we encountered also some
limitations of RailML, but we were able to bypass them by using schema
extensions based on any attribute/element which most RailML elements
offers. Did you consider to use such a kind of extension?

Kind Regards,

Horst Naujoks

Kluser Renato wrote:
>
> ENGLISH SUMMARY: The MGB railway uses railML 2.0
> for data exchange from our timetabling system to
> our disposition system. Currently we need an
> extension of the standard to transfer line
> blockings from one system to another.
>
> Hallo railML-Partner,
>
> wir, die Matterhorn Gotthard Bahn (MGB),
> betreiben ein 144 km langes Meterspurnetz im
> Süden der Schweiz. Zum Datenaustausch zwischen
> unserem Fahrplansystem FBS und dem
> Kundeninformations- und Dispositionssystem KIS nutzen wir railML 2.0.
>
> Nun möchten wir auch noch die in FBS verwalteten
> Streckenunterbrüche an das Dispositionssystem
> übergeben und schlagen daher eine Erweiterung des
> railML-Standards vor. Die Abbildung folgende
> Arten von Unterbrüchen wäre für uns unerlässlich:
>
> - Strecke von Betriebsstelle BRMG (Brig) bis Visp
> (VISP) gesperrt vom 15. Juli 2012 22.00 Uhr bis
> 29. Juli 2012 4.00 Uhr; Grund: Bauarbeiten am Gleis
> - Strecke von Oberwald (OBW) bis Realp (REAL)
> gesperrt im Zeitraum vom 3. Oktober 2012 bis 16.
> Oktober 2012; jeweils zwischen 22.45 Uhr bis 3.45
> Uhr am Folgetag; Grund: Fahrleitungsrevision
> - Strecke 140 von km 22,790 bis 26,186 gesperrt
> bis 3. Dezember 2012; 16.00 Uhr
>
> Eine Erweiterung der Eigenschaften eines
> Unterbruchs (z.B. 'nur für elektrische
> Fahrzeuge', 'nur für Fahrzeuge des Typs ...'
> usw.) und zusätzliche Informationen wie Busersatz
> usw. wäre denkbar, ist aber für uns nicht dringlich.
>
> Beste Grüsse,
>
> Renato Kluser
> Betrieb
> Verkehrsplanung und Sicherheit
>
> Matterhorn Gotthard Bahn
> Bahnhofplatz 7
> CH-3900 Brig
> http://www.mgbahn.ch
>
>
>


--
----== posted via PHP Headliner ==----
Re: Steckenunterbruch/line blocking [message #510 is a reply to message #501] Thu, 17 January 2013 18:20 Go to previous messageGo to next message
Susanne Wunsch railML is currently offline  Susanne Wunsch railML
Messages: 0
Registered: January 2020
Dirk Bräuer <dirkbraeuer(at)irfpde> writes:

>> for getting a connection to another forum, it is better to use the
>> followup-tag.
>
> I don't know what a follow-up tag is.

Better to call it "Followup-To":

http://en.wikipedia.org/wiki/Crossposting
http://de.wikipedia.org/wiki/Crossposting

>> However, since the "disabled" sub-element will be available for all
>> relevant tracks, there is no need to define a length of the blocking
>> section in form of a "from-to" attribute group.
>
> But then there would be no possibility do "block a part of an
> <element>" such as part of a track (sub-section of a track).

I just implemented the new element <state> with an attribute 'disabled'
of type xs:boolean. It may be constrained with the attribute
'operatingPeriodRef' referring to an operatingPeriod/@id from the
timetable subschema. Furthermore it may be constrained to a part of a
<track> by relative positions.

Example (assume 'operatingPeriod' are defined in the same file):

<track id="t1">
<states>
<state disabled="true" operatingPeriodRef="op1" remarks="blah">
<from pos="250"/>
<to pos="1340"/>
</state>
<state disabled="true" operatingPeriodRef="op2">
<from pos="8900"/>
</state>
</states>
<trackTopology>
<trackBegin id="tb1" pos="0">
<macroscopicNode ocpRef="o1"/>
</trackBegin>
<trackEnd id="te1" pos="10000">
<macroscopicNode ocpRef="o2"/>
</trackEnd>
</trackTopology>
</track>

There are some assumptions, that should be documented in the wiki:

* If no "from" is defined, it begins at the "trackBegin".
* If no "to" is defined, it begins at the "trackEnd".
* If no "operatingPeriodRef" is defined, it is valid for all data of
the railML file.
* For all other times (out of the referred operating period) the
defined track (section) is enabled/disabled depending on the
"disabled" value.
* If no "state" element is defined, the "track" is usable. That means
'disabled="false".

For further constraints use the xs:any element or the anyAttribute.

Currently the <from> and <to> elements may additionally refer to an
'ocp' via an 'ocpRef' attribute. Maybe that should be dropped because of
redundancy reasons.

But otherwise that may be helpful if the exact blocking locations
(relative positions) are known but differ from the ocp locations. The
ocp references may be used as a hint, not overwriting the exact
locations.

See ticket [1] and last issue-related implementation [2].

Please test the new structure for your needs and give us a feedback.

> A typical problem (to solve here) is "line/track is blocked from
> ... to ..." with from/to being mileages or stations.

The 'line blocking' has to be defined through the 'track blocking'.

>> Here, I suggest to just implement a reference from the <disabled>
>> element to an operating period.
>
> Such a reference would - as far as I know - the first time we would
> create such a "forward-reference". Forward in the meaning of "from
> infrastructure to timetable". We already have many references from
> timetable to infrastructure which are "natural" since one _first_
> needs infrastructure _before_ one can operate a train.

We already put such a "forward-reference" into the infrastructure
subschema with the implementation of speed profiles.

The TSR (temporary speed restrictions, de:Langsamfahrstellen) also
refer to an 'operatingPeriod' from the timetable subschema.

In most use cases a software has to multiply selectively import the
railML file in order to semantically validate the data. Or the other way
around, a software imports the whole railML file at once and
cross-checks the internal data structures afterwards.

From this railML version on, the sequencial selectively import does
not work anymore, because of both reference directions (from TT to IS
and from IS to TT).

> To have both directions, I would think is like "circular references"
> which sometimes can become problematic in informatics. In my opinion,
> a software first has to import <infrastructure> before it can import
> <timetable>. So it wouldn't be able to dissolve the references from
> infrastructure to timetable when importing.

For a future version we would like to move the operating periods to the
common part of railML, in order to provide a better "straight-forward"
structure. But this is a change for the next major release. ;-(

I created a ticket for this issue. [3]

[1] http://trac.assembla.com/railML/ticket/156
[2] http://trac.assembla.com/railML/changeset/528
[3] http://trac.assembla.com/railML/ticket/215

Kind regards...
Susanne

By the way, this need was already required three years ago. ;-)
http://trac.assembla.com/railML/ticket/34

--
Susanne Wunsch
Schema Coordinator: railML.common
Re: Steckenunterbruch/line blocking [message #535 is a reply to message #510] Fri, 19 July 2013 19:10 Go to previous message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 311
Registered: August 2008
Senior Member
Dear Susanne,

> I just implemented the new element <state> with an attribute 'disabled'
> of type xs:boolean. It may be constrained with the attribute
> 'operatingPeriodRef' referring to an operatingPeriod/@id from the
> timetable subschema. Furthermore it may be constrained to a part of a
> <track> by relative positions.

Thank you, looks good.

> There are some assumptions, that should be documented in the wiki

This is very important, thank you very much.

> * If no "from" is defined, it begins at the "trackBegin".
> * If no "to" is defined, it begins at the "trackEnd".

+1

> * If no "operatingPeriodRef" is defined, it is valid for all data of
> the railML file.

+1

> * For all other times (out of the referred operating period) the
> defined track (section) is enabled/disabled depending on the
> "disabled" value.
> * If no "state" element is defined, the "track" is usable. That means
> 'disabled="false".

We both mean the same, but to avoid misunderstandings, I would prefer a
more clear wording:

If there is no <state> element saying anything else, a track can be
assumed to be enabled. Therefore, there is no need to create a <state>
element with disabled="false".

Now, either you could leave it as you have designed it, or you could
discard the attribute 'disabled' and name the element <state> to
<disabled> or such.

With the attribute disabled="false", there would be several possibilities
to express the same sequence of blockings:

<state disabled="true" operatingPeriodRef="op_May">
<state disabled="true" operatingPeriodRef="op_July">
or
<state disabled="true" operatingPeriodRef="op_May-July">
<state disabled="enabled" operatingPeriodRef="op_June">

may both be treated as the same. With the second solution, there may be
again the problem of sequence: The different order of the two rows may
result in a difference meaning. Therefore, we possibly would need a
'sequence' or 'priority' attribute or such again.

To avoid this redundancy, and to avoid the 'sequence' attribute, I would
prefer to discard the attribute 'disabled' and to rename the element
<state> into <disabled> or such.

> Currently the <from> and <to> elements may additionally refer to an
> 'ocp' via an 'ocpRef' attribute. Maybe that should be dropped because of
> redundancy reasons.
>
> But otherwise that may be helpful if the exact blocking locations
> (relative positions) are known but differ from the ocp locations. The
> ocp references may be used as a hint, not overwriting the exact
> locations.

I think this is not redundancy:

To refer to ocp's says: The writing software does not know the exact
positions. Any movement between theses ocp's is not allowed; anyway where
exactly the reason for that is situated.

To refer to exact positions says: The writing software knows the exact
positions. The track between theses positions is not available.

The difference lies in the question "how much of the stations at the
beginning/end of the blocking is usable": An <ocp> element normally is
situated at the mileage position of the _middle_ of the corresponding
station (middle of the platforms). Can you use the "half" of the station
from the middle of the platforms into the direction of the blocking?

Let's assume ocp 'ABC' lies at relative position km 15.432.

<state disabled="true">
<from pos="15432"/>
<to pos="23456"/>
</state>

means: You cannot move even one meter behind km 15.432 (the middle of the
station), so you cannot enter this station from below 15.432 at the normal
kind. (Even half of the platform seams to be closed. There is a
"Schutzhalttafel" exactly at the middle of the station.)

<state disabled="true">
<from ocpRef='ABC'/>
<to ocpRef='DEF'/>
</state>

means: The track section between ABC and DEF is blocked. There is here no
information on a blocking inside the station of ABC. You can assume it is
normally usable.

I would prefer to keep this difference in any kind: In some cases, we do
need the possibility to name the exact positions of the "Schutzhalttafeln"
either for reasons of the "building trade" (BETRA) or to allow shunting
movements. In many other cases (e. g. timetabling), we do not know the
exact positions but we have to describe that a section of track is closed.

Of course there would be other, more explicit solutions to express this
difference. May be "more explicit" would be better. Anyway, I am satisfied
if it is possible at least in any kind.

> The 'line blocking' has to be defined through the 'track blocking'.

+1

>> Such a reference would - as far as I know - the first time we would
>> create such a "forward-reference". Forward in the meaning of "from
>> infrastructure to timetable". We already have many references from
>> timetable to infrastructure which are "natural" since one _first_
>> needs infrastructure _before_ one can operate a train.
>
> We already put such a "forward-reference" into the infrastructure
> subschema with the implementation of speed profiles.
>
> The TSR (temporary speed restrictions, de:Langsamfahrstellen) also
> refer to an 'operatingPeriod' from the timetable subschema.

Ok, good to have this clarified as a general question: Forward references
are not forbidden.

> For a future version we would like to move the operating periods to the
> common part of railML, in order to provide a better "straight-forward"
> structure. But this is a change for the next major release.

But why? Some sentences before, you did clarify: Forward references are
not forbidden, sequential reading is not possible. So anybody must accept
and implement this to come from now to the next major release. Why should
we change it afterwards?

I would welcome this to avoid forward references just to make things
easier and to get a higher acceptance of RailML. But more importantly, I
would prefer consequence and not to switch between the philosophies. A
_stable_ philosophy creates much more acceptance than one which is only
theoretically better.

So if you do not want (or cannot) avoid forward references now and in
general, you do not need to avoid them later.

Best regards,
Dirk.
Previous Topic: Haltetafel / stop post
Next Topic: new attribute on the vehicle element
Goto Forum:
  


Current Time: Mon Jul 15 10:27:47 CEST 2024