Home » railML newsgroups » railml.infrastructure » Proposed Semantic Constraint for <speedChange> in railML 2.x
Proposed Semantic Constraint for <speedChange> in railML 2.x [message #2207] Tue, 18 June 2019 15:22 Go to next message
Christian Rößiger is currently offline  Christian Rößiger
Messages: 35
Registered: March 2015
Member
[english version below]

Hallo zusammen

Für das Element <speedChange> wird im railML Wiki eine semantic constraint vorgeschlagen, mit der das Attribut trainOrder zum Pflichtfeld werden soll. Gegen diesen Vorschlag habe ich zwei Einwände, einen formalen(1) und einen fachlichen(2):

1. Die Eigenschaft obligatorisch / optional einer Attribut-Definition kann und sollte in XML über das Schema als syntactic constraint abgebildet werden. Auf die Einführung von zusätzlichen syntaktischen constraints innerhalb von Minor-Versionen wurde bisher jedoch verzichtet, um die Abwärtskompatibilität zu erhalten. Dieses Argument sollte auch bezüglich semantic constraints gelten. Ich halte nichts davon, eine syntactic constraint als semantic constraint einzuführen, um die Probleme mit der Abwärtskompatibilität bei syntaktic constraints zu umgehen.

2. Es ist nicht immer möglich, für das Attribut trainRelation einen statischen Wert zu definieren. Wie im Wiki dokumentiert, gibt es 2 Grundregeln: Geschwindigkeitsreduktionen gegenüber dem vorherigen <speedChange> beziehen sich auf die Zugspitze, Geschwindigkeitserhöhungen auf den Zugschluss. Bei Einmündungen von Strecken kann daher ein <speedChange> je nach Fahrweg zugleich erhöhend und reduzierend wirken (siehe Anhang). Aus diesem Grund wird das Attribut von uns nur explizit angegeben, wenn von obiger Grundregel abgewichen werden soll.


Hello everybody,

For the element <speedChange> a semantic constraint is proposed in the railML Wiki, that makes the attribute trainOrder a mandatory field. I have two objections against this suggestion, one formal(1) and one technical(2):

1. The property mandatory / optional of an attribute definition can and should be mapped in XML via the schema as syntactic constraint. However, the introduction of additional syntactic constraints within minor versions has so far been omitted in order to maintain downward compatibility. This argument should also apply to semantic constraints. I disagree with the idea of introducing a syntactic constraint as semantic constraint in order to avoid the problems with downward compatibility of syntactic constraints.

2. It is not always possible to define a static value for the trainRelation attribute. As documented in the Wiki, there are 2 basic rules: Speed reductions in relation to the previous <speedChange> refer to the head of the train, speed increases to the tail of the train. At junctions of routes, a <speedChange> can have an increasing and reducing effect at the same time, depending on the route (see appendix). For this reason, the attribute is only explicitly specified by us if the above basic rule is to be deviated from.

Best regards,
Christian
Re: Proposed Semantic Constraint for <speedChange> in railML 2.x [message #2235 is a reply to message #2207] Mon, 26 August 2019 15:24 Go to previous message
christian.rahmig is currently offline  christian.rahmig
Messages: 235
Registered: January 2016
Senior Member
[English version below]

Hallo Christian,

in der Tat haben wir für Semantic Constraints noch nicht ausreichend
Randbedingungen definiert, welche ihren Einsatz und ihre Bedeutung für
die Versionskompatibilität von railML klar strukturieren. Hier müssen
wir (in Zusammenarbeit mit euch Nutzern) noch nacharbeiten.

Damit die Problemstellung (und daraus zu entwickelnde Lösungsansätze)
nicht in Vergessenheit geraten, habe ich ein Ticket aufgesetzt (siehe
[1]). Ich lade die ganze Community ein, zur Diskussion beizutragen...

[1] https://trac.railml.org/ticket/361

Vielen Dank und viele Grüße
Christian


[English version]

Hello, Christian,

In fact, we have not yet sufficiently defined boundary conditions for
semantic constraints that clearly structure their use and significance
for the version compatibility of railML. Here we (in cooperation with
you users) still have to work on.

So that the problem (and the solutions to be developed from it) are not
forgotten, I have created a ticket (see [1]). I invite the whole
community to contribute to the discussion...

[1] https://trac.railml.org/ticket/361

Thank you very much and 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: [railML3] Extension of OPEquipment
Next Topic: [railML2] modeling of a car ramp
Goto Forum:
  


Current Time: Wed Oct 16 11:51:36 CEST 2019