Dear all,
the wiki page on <blockPart>s is inconsistent.
- It says that for missions fullRun, emptyRun, <trainpartref> must not
be used, but a "note" on the bottom of the page says the opposite for
emptyRun
- The English text says that depotRun is "not a run", in the German
text this mission type is missing.

Is a depotRun a trip to a depot? Then I would think that it _is_ a run,
and start and end will be different.

Also, shouldn't, instead of start and end ocps, rather <ocptts> be used
for those missions that are runs? Referencing a trainPart I think is not
optimal, because so far they are always used in connection with a train,
and we don't have a train for those runs.

Finally, it would be nice if we could clarify the semantics of shunting,
emptyRun, fullRun and depotRun.

> the wiki page on <blockPart>s is inconsistent.> - It says that for missions fullRun, emptyRun, <trainpartref> must not > be used, but a "note" on the bottom of the page says the opposite for > emptyRun

I think it is not inconsistent but capable of being misunderstood: The
"note" on the bottom of the page does not say the opposition for _the
enumeration value_ “emptyRun” but for one of two possibilities to express
an empty run in general.

- There are two possibilities to express empty runs (in general) as the
note of Joachim says.
- The enumeration value “emptyRun” is to be used only if the attribute
/trainpartref/ is not existing. This is the second possibility (“loosely
planned”).
- The other way is an empty run “planned in all details in the timetable”.
This must have the /trainPartRef/ attribute and therefore the /mission/ =
“timetable”.

> Is a depotRun a trip to a depot? Then I would think that it _is_ a run, > and start and end will be different.

I think we can clarify this in the meaning of the footnote written by
Joachim: Everything (each <blockPart>) with the attribute /trainPartRef/
shall have the /mission/ = “timetable”. (This should be an easy signalling
to the parser to look for the /trainPartRef/ attribute.) So, the /mission/
= “depotRun” is away for the runs with timetable (“planned in all
details”). It is still usable for “loosely planned” runs. You can use it
for a trip to a depot (if “loosely planned”) as well as for a trip inside
the depot (something like shunting). There is so far no further definition
in RailML.

--> I suggest to extend the formulation “A duty which is not a run” by
“…or which is a run ‘loosely planned’”. If nobody contradicts I will do
this change in some weeks.

> Also, shouldn't, instead of start and end ocps, rather <ocptts> be used > for those missions that are runs? Referencing a trainPart I think is not > optimal, because so far they are always used in connection with a train, > and we don't have a train for those runs.

There should not be references to trainParts in <blockPart>s which have
/start/endOcpRef/.

There cannot be references to <ocpTT>s because <ocpTT>s are sub-structures
of <trainPart>, and since we have no <trainPart>s for such <blockPart>s,
we also have no <ocpTT>.

The <ocpTT>s of the "surrounding" trains cannot be references because
depending on the operation day, these could be different "surrounding"
trains around a duty such as "refuel". Additionally, two or more such
duties without <trainPart>s could follow: A "refuel" can be followed by
"shunting" can be followed by "pre-heating".

Please look at the examples for more information.

> Finally, it would be nice if we could clarify the semantics of shunting, > emptyRun, fullRun and depotRun.

I guess the footnote of Joachim aimed to do so. We could write more on
this but before I would like to “hear” (read) the opinion of Joachim. My
suggestion is to add two examples (directly on the Wiki page) on a
“loosely planned” and a “timetable planned” empty run, full run, and depot
run and a (of course non-timetable planned) shunting.