| dayOffset vs. arrival/departureDay [message #880] |
Mon, 12 November 2012 13:04  |
Dirk Bräuer
Messages: 311
Registered: August 2008
|
Senior Member |
|
|
Dear all,
in March 2012 we have created the <operatingPeriod>.dayOffset attribute.
The original thought was to allow bitmasks with one or more digits than
the there are days in the period. This was to describe a midnight-overrun
before the station where the bitmask relates to.
Anyway, the longer bitmasks were not agreed. Instead, the new
<operatingPeriod>.dayOffset attribute was created.
Since then, I have written some strange explanations at [1] and elsewhere
but I am not satisfied with the redundancy which comes with
<operatingPeriod>.dayOffset. With implementation, it becomes once more
clear that it is always possible to avoid <operatingPeriod>.dayOffset>0 by
using the already existing arrival/departureDay even at the first <ocpTT>
of a <trainPart>. Even more worst, dayOffset leads by trend to define
every <operatingPeriod> several times, one with dayOffset=0 and one with
dayOffset=1 a.s.o.
See last sentence of my writings:
“It seams as if it is redundant whether a <trainPart> starts with
departureDay=1 or refers to an <operatingPeriod> with dayOffset=1. It is
not, since a train shall always start with departureDay=0 at its fist
<ocpTT> in its first section; departureDay>0 is intended to happen only in
first <ocpTT>s in further sections.”
I think we should throw it away before it becomes valid for the sake of
less redundancy. Instead, we should turn that sentence around and say:
“Always when we thought we have to use dayOffset=1 we should use
departureDay=1 instead.”
Therefore, I plead for deleting <operatingPeriod>.dayOffset before it ever
became valid with RailML 2.2.
If the others agree, I would simplify the Wiki in that way.
Dirk.
[1] http://wiki.railml.org/index.php?title=TT:times#notes
|
|
|
|
Members
Search
Help
Login
Home
