Home » railML newsgroups » railml.timetable » <trackRef>.dir
<trackRef>.dir [message #783] Tue, 22 May 2012 21:45 Go to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 313
Registered: August 2008
Senior Member
Dear Joachim,

I have one small issue for RailML 2.2:

We should clearify and ease the attribute
<trainPart>.<ocpTT>.<sectionTT>.<trackRef>.dir.

So far, it has the enumeration values up, down, unknown, none, and both.
The only two which make sense are up & down but both should be renamed to
'falling' and 'raising' as in infrastructure (see also news message from
26.03.2012 and Trac ticket #145).

The others are not applicable and should be deleted. (Instead of using
'unknown' one should skip the optional attribute.)

Thank you and best regards,
Dirk.

---
Das Attribut <trainPart>.<ocpTT>.<sectionTT>.<trackRef>.dir ist mit den
Ausprägungen up, down, unknown, none und both definiert. Die einzig
sinnvollen sind up und down, wobei diese in raising und falling
umdefiniert werden sollten. Die übrigen sind nicht zutreffend (statt
unknown kann das optionale Attribut weggelassen werden) und sollten daher
entfallen.
Re: <trackRef>.dir [message #785 is a reply to message #783] Tue, 29 May 2012 14:07 Go to previous messageGo to next message
Joachim Rubröder railML is currently offline  Joachim Rubröder railML
Messages: 0
Registered: November 2019
Hello Dirk,
I agree that the values are misleading and should be renamed, but the Trac
ticket #145 is due to version 3.0 because renaming will be a breaking
change.

I would suggest to use "tDelimitedDirection" (up, down, unknown) instead
of "tLaxDirection" (up, down, unknown, both, none) in 2.2 because "both"
and "none" make no sense. Instead of using "unknown", the optional
attribute "dir" should be skipped.

Kind regards,
Joachim

---

Ich bin völlig einverstanden, aber Umbenennungen wie im Ticket #145
vorgesehen sind als Breaking Changes erst mit Version 3.0 zulässig.

Als kleine Verbesserung bietet sich an den Typ "tDelimitedDirection" (up,
down, unknown) statt "tLaxDirection" (up, down, unknown, both, none) in
Version 2.2 zu verwenden, da die Ausprägungen "both" und "none" hier
keinen Sinn machen. Statt "unknown" zu verwenden sollte man das optionale
Attribut weglassen, was in der Dokumentation vermerkt wird.


Dirk Bräuer wrote:
>
> Dear Joachim,
>
> I have one small issue for RailML 2.2:
>
> We should clearify and ease the attribute
> <trainPart>.<ocpTT>.<sectionTT>.<trackRef>.dir.
>
> So far, it has the enumeration values up, down, unknown, none, and both.
> The only two which make sense are up & down but both should be renamed to
> 'falling' and 'raising' as in infrastructure (see also news message from
> 26.03.2012 and Trac ticket #145).
>
> The others are not applicable and should be deleted. (Instead of using
> 'unknown' one should skip the optional attribute.)
>
> Thank you and best regards,
> Dirk.
>
> ---
> Das Attribut <trainPart>.<ocpTT>.<sectionTT>.<trackRef>.dir ist mit den
> Ausprägungen up, down, unknown, none und both definiert. Die einzig
> sinnvollen sind up und down, wobei diese in raising und falling
> umdefiniert werden sollten. Die übrigen sind nicht zutreffend (statt
> unknown kann das optionale Attribut weggelassen werden) und sollten daher
> entfallen.
>
>



--
----== posted via PHP Headliner ==----
Re: <trackRef>.dir [message #786 is a reply to message #785] Tue, 29 May 2012 13:45 Go to previous messageGo to next message
Susanne Wunsch railML is currently offline  Susanne Wunsch railML
Messages: 0
Registered: January 2020
Hi Dirk and Joachim,

coord(at)timetablerailmlorg (Joachim Rubröder) writes:

> Dirk Bräuer wrote:

>> We should clearify and ease the attribute
>> <trainPart>.<ocpTT>.<sectionTT>.<trackRef>.dir.
>>
>> So far, it has the enumeration values up, down, unknown, none, and both.
>> The only two which make sense are up & down but both should be renamed to
>> 'falling' and 'raising' as in infrastructure (see also news message from
>> 26.03.2012 and Trac ticket #145).
>>
>> The others are not applicable and should be deleted. (Instead of using
>> 'unknown' one should skip the optional attribute.)

> I would suggest to use "tDelimitedDirection" (up, down, unknown) instead
> of "tLaxDirection" (up, down, unknown, both, none) in 2.2 because "both"
> and "none" make no sense. Instead of using "unknown", the optional
> attribute "dir" should be skipped.

If a type for "up" and "down" is needed, we should create it.

Currently the absence of the attribute has the same semantics as the
attribute "dir" with value "unknown". I don't know if these two
possibilities of defining the same meaning introduce any troubles in
programming.

We keep in mind that there will be a renaming of the enumeration values
in next major release (raising, falling).

>> Das Attribut <trainPart>.<ocpTT>.<sectionTT>.<trackRef>.dir ist mit den
>> Ausprägungen up, down, unknown, none und both definiert. Die einzig
>> sinnvollen sind up und down, wobei diese in raising und falling
>> umdefiniert werden sollten. Die übrigen sind nicht zutreffend (statt
>> unknown kann das optionale Attribut weggelassen werden) und sollten daher
>> entfallen.

> Als kleine Verbesserung bietet sich an den Typ "tDelimitedDirection" (up,
> down, unknown) statt "tLaxDirection" (up, down, unknown, both, none) in
> Version 2.2 zu verwenden, da die Ausprägungen "both" und "none" hier
> keinen Sinn machen. Statt "unknown" zu verwenden sollte man das optionale
> Attribut weglassen, was in der Dokumentation vermerkt wird.

Falls ein Typ für "up" und "down" gebraucht wird, sollte er geschaffen
werden.

Zur Zeit bedeuten die Abwesenheit des Attributs und das Attribut
dir="unknown" das gleiche. Ich kann nicht einschätzen, ob diese zwei
Varianten, das Gleiche auszudrücken Schwierigkeiten bei der
Programmierung bereiten.

Wir behalten im Hinterkopf, dass die Aufzählungswerte mit dem nächsten
größeren Versionsschritt in "raising" und "falling" umbenannt werden.

Kind regards... / Beste grüße...
Susanne

--
Susanne Wunsch
Schema Coordinator: railML.common
Re: <trackRef>.dir [message #795 is a reply to message #786] Wed, 30 May 2012 14:57 Go to previous messageGo to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 313
Registered: August 2008
Senior Member
Dear Susanne,

Am 29.05.2012, 13:45 Uhr, schrieb Susanne Wunsch <coord(at)commonrailmlorg>:

> Currently the absence of the attribute has the same semantics as the
> attribute "dir" with value "unknown". I don't know if these two
> possibilities of defining the same meaning introduce any troubles in
> programming.

From my experience: No problem, full redundancy. From my side we should
avoid 'unknown' and leave the possibility to skip the attribute.

> We keep in mind that there will be a renaming of the enumeration values
> in next major release (raising, falling).

Can we exchange "keep in mind" with "create a track ticket"? ;-)

Or expand the track ticket you already created for the same renamings in
IS ?

Thank you,
Dirk.
Re: <trackRef>.dir [message #798 is a reply to message #795] Wed, 30 May 2012 16:17 Go to previous message
Susanne Wunsch railML is currently offline  Susanne Wunsch railML
Messages: 0
Registered: January 2020
Hi Dirk,

Dirk Bräuer <dirkbraeuer(at)irfpde> writes:
> Am 29.05.2012, 13:45 Uhr, schrieb Susanne Wunsch <coord(at)commonrailmlorg>:
>
>> Currently the absence of the attribute has the same semantics as the
>> attribute "dir" with value "unknown". I don't know if these two
>> possibilities of defining the same meaning introduce any troubles in
>> programming.
>
> From my experience: No problem, full redundancy. From my side we
> should avoid 'unknown' and leave the possibility to skip the
> attribute.

Ok, I will define a new type for only these two enumeration
values. Something like "tStrictDirection" for "up" and "down" without
any extensibility options.

>> We keep in mind that there will be a renaming of the enumeration values
>> in next major release (raising, falling).
>
> Can we exchange "keep in mind" with "create a track ticket"? ;-)

Already done. [1]

> Or expand the track ticket you already created for the same renamings
> in IS ?

Joachim appended a comment for not forgetting this topic. :)

[1] http://trac.assembla.com/railML/ticket/145

Nice development speed. :))

Gratefully ...
Susanne

--
Susanne Wunsch
Schema Coordinator: railML.common
Previous Topic: RFE for stop description
Next Topic: missing bitMask at <trainPart><operatingPeriodRef>
Goto Forum:
  


Current Time: Mon Oct 14 14:39:05 CEST 2024